Tillgänglighet för
utvecklare, del 1
Andreas Cederbom
[email protected]
Twitter: @cederbomarn
Agenda
•
•
•
•
Kort om tillgänglighet
Lagar och riktlinjer
Tester och verifiera tillgänglighet
Genomgång av krav
Nästa gång:
• Svar på era frågor
• Wai-aria och komplexa lösningar
Funka
•
•
•
•
Startades av handikapprörelsen
Privatägt bolag 2000
Oslo 2010
Madrid 2013
Vad vi gör
• Konsultverksamhet
•
•
•
•
•
•
•
Utveckling
Analys, stöd och test
Utbildning
Forskning
Samarbetsprojekt
Förtroendeuppdrag
Standardisering
Kognition
Höra
Läsa och skriva
Tala
Koncentration
Social interaktion
Motorik
Överkänslighet
Se
Design för alla
Vilka berörs?
Situationsbaserade problem
Arbetsskador
Svenska som andraspråk
Teknikovana
Tillfälliga besvär
Mobilanvändare
Personer med funktionsnedsättning
Tre delar
Innehåll
Teknik
Pedagogik
Teknik
Teknik
Exempel, eye-trackingtester
A/B test med 240 000 besökare
”The menu button was clicked
by 20% more unique visitors
than the hamburger button.”
Källa
Exempel: Innehåll
WCAG 2.0
Web Content Accessibility Guidelines
•
•
•
•
•
•
•
Internationell standard
Framtagen av W3C
Från 2008
ISO/IEC 40500:2012
Alla pekar på WCAG 2.0
Teknikoberoende
61 krav på 3 nivåer (A, AA och AAA)
Robust
WCAG
Uppfattningsbart
4 Principer
12 Riktlinjer
61 Framgångskriterier
- 3 nivåer: A, AA, AAA
>600 Tekniker och
vanliga fel
Begripligt
Hanterbart
Exempel ur WCAG
1.4.1 Use of Color: Color is not used as the only visual
means of conveying information, indicating an
action, prompting a response, or distinguishing a
visual element. (Level A)
Exempel: Beroende av färg
Exempel ur WCAG
1.3.1 Info and Relationships: Information, structure,
and relationships conveyed through presentation
can be programmatically determined or are
available in text. (Level A)
Exempel: Teknisk struktur
WCAG 2.0
• Komplext
• Gäller webb, oavsett teknik
• Säger inte hur
tillgänglighet ska uppnås
• Inkluderar inte mobilt
• Handlar nästan enbart om teknik
Lagar och riktlinjer
Diskrimineringslagen
Diskrimineringslag (2008:567)
EN 301 549:
Accessibility requirements for
procurement of ICT products
and services in Europe
Lag (2016:1145) om offentlig upphandling
”När det som anskaffas ska användas av fysiska
personer ska de tekniska specifikationerna
bestämmas med beaktande av samtliga
användares behov, däribland tillgängligheten för
personer med funktionsnedsättning.
…
Om Europeiska unionen i en rättsakt har antagit
obligatoriska krav på tillgänglighet, ska de tekniska
specifikationer som avses i första stycket bestämmas
med hänvisning till den rättsakten.”
LOU 9 Kap., 2 §
Funkas filmer om EN 301 549 (engelska)
Vad innebär det här?
•
•
•
•
•
IT generellt
Offentlig sektor
WCAG 2.0 nivå AA
Minimikrav
Nationell lag 1 januari 2017
Directive of the European
Parliament and of the
Council on the
accessibility of public
sector bodies' websites
Vad innebär det här?
• Offentlig sektor +
samhällstjänster
• Externwebb, intranät, appar
• WCAG 2.0 nivå AA
• Minimikrav
• Nationell uppföljning
Att testa…
Svårigheter
•
•
•
•
•
•
•
Stort område
Stor skillnad mellan olika användares behov
100 % tillgänglig finns inte
Teknikutvecklingen
Brist på konsensus
Kunskapsbrist
OS x Webbläsare x Hjälpmedel x Versioner ≈ ∞
Det krävs tid, kunskap och
erfarenhet för att förstå hur
WCAG ska implementeras
Olika typer av tester
•
•
•
•
Automatiska verktyg
Manuella tester
Användartester
Praktiska tester med hjälpmedel
Automatiska tester
Exempel
AccessMonitor by Fundação para a
Ciência e a Tecnologia, IP
•
SortSite by Powermapper Software
Tanaguru by Tanaguru
•
AChecker by Inclusive Design
Research Centre
•
•
TAW
•
A-Tester by Evaluera Ltd
•
Tenon by Tenon
•
Functional Accessibility Evaluator 2.0
/ AInspector by the Open
Accessibility Alliance and OpenAjax
Accessibility Task Force
•
Tingtun HTML / eAccessibility by European
Internet Inclusion Initiative
•
Total Validator by Total Validator
•
WAVE by WebAIM
•
Web-me
•
•
HiSoftware Compliance Sheriff Web
by HiSoftware Inc.
•
Mauve
•
Siteimprove Accessibility by
Siteimprove
Automatiska tester
All tillgänglighet = 100 %
Automatiska tester
Det ultimata
automatiska
verktyget ≈ 40 %
Automatiska tester
De bästa verktygen
idag klarar kanske
10 %
Men hur mycket testas egentligen?
Ett exempel:
Tanaguru har 277 tester
6
procent
Du måste vara expert för att
kunna tolka resultatet vid
automatisk testning
Verktyg för specifika delar
• Color Contrast Analyser:
• Web Accessibility Toolbar (IE):
www.paciellogroup.com/resources/contrasthttps://www.paciellogroup.com/resources/wat/
analyser.html
• Web Developer Toolbar (FF):
• W3C, Markup Validation Service:
https://addons.mozilla.org/enhttps://validator.w3.org/
US/firefox/addon/web-developer/
• W3C, CSS Validation Service:
• Web Developer Toolbar (Chrome):
https://jigsaw.w3.org/css-validator/
http://chrispederick.com/work/web-developer/
• Accessibility Evaluation Toolbar for Firefox
https://addons.mozilla.org/svSE/firefox/addon/5809/?collection_uuid=568ad3
12-b94f-4fe9-af36-061a602f698b
• Firebug: http://getfirebug.com/
• Yslow: http://developer.yahoo.com/yslow/
• Smush.it™:
http://developer.yahoo.com/yslow/smushit/
Manuella tester
Om manuella tester
•
•
•
•
•
•
Utbildning och erfarenhet
Dokumentation
Kvalitetssäkring
Använd verktyg som stöd
Involvera användare
Ni kommer att underskatta problemen
Verktyg för specifika delar
• Color Contrast Analyser:
• Web Accessibility Toolbar (IE):
www.paciellogroup.com/resources/contrasthttps://www.paciellogroup.com/resources/wat/
analyser.html
• Web Developer Toolbar (FF):
• W3C, Markup Validation Service:
https://addons.mozilla.org/enhttps://validator.w3.org/
US/firefox/addon/web-developer/
• W3C, CSS Validation Service:
• Web Developer Toolbar (Chrome):
https://jigsaw.w3.org/css-validator/
http://chrispederick.com/work/web-developer/
• Accessibility Evaluation Toolbar for Firefox
https://addons.mozilla.org/svSE/firefox/addon/5809/?collection_uuid=568ad3
12-b94f-4fe9-af36-061a602f698b
• Firebug: http://getfirebug.com/
• Yslow: http://developer.yahoo.com/yslow/
• Smush.it™:
http://developer.yahoo.com/yslow/smushit/
Användartester
När använder vi användare
•
•
•
•
•
Nya koncept
Nya lösningar
Specifika målgrupper
Nya tekniker
Hur funkar det i praktiken?
Hur testar vi
•
•
•
•
•
Traditionella användartester
Fokusgrupper
Enkätundersökningar
Distanstester
Eye-tracking
Att testa med hjälpmedel
Skärmläsare
• Windows
•
•
•
•
•
•
•
•
Jaws
Cobra
Narator (Microsoft)
NVDA
Supernova
Window-Eyes (gratis om du har
Word 2010 eller senare)
Zoomtext
Chromevox (fungerar bara med
Google Chrome)
• Android
• Talkback
• Brailleback
• Apple
• VoiceOver (Mac,
iPhone och iPad)
• Zoomtext för Mac
Varför kan man behöva testa?
För att kunna testa måste vi
först ställa krav
Tre delar
WCAG 2.0
Innehåll
Teknik
Pedagogik
Det krävs tydliga krav
Sikta inte bara
på WCAG, utgå
från användarna
Tillgänglighetskrav för utvecklare
Tre delar
Innehåll
Teknik
Pedagogik
T1. Kodkvalitet
•
•
•
Använd tekniker som går att göra
tillgängliga
Ange html-standard i !Doctype
Ange teckenuppsättning
!Doctype och teckenuppsättning
<!DOCTYPE html>
<html lang=”sv”>
<head>
<meta charset="UTF-8">
T1. Kodkvalitet
•
•
•
•
•
Använd tekniker som går att göra
tillgängliga
Ange html-standard i !Doctype
Ange teckenuppsättning
Använd korrekt kod
Använd effektiv kod
Validera kod
• WCAG pekar på specifika fel
• Sträva efter helt korrekt kod
• Validera html
http://validator.w3.org/
• Validera css
http://jigsaw.w3.org/css-validator/
Vad säger WCAG?
• WCAG kräver inte perfekt kod
• Fyra typer av fel får inte förekomma:
• Använd inte samma id-värde mer än en gång
på en sida
• Använd fullständiga start- och sluttaggar
• Nästla element i enlighet med standarden
• Använd inte samma attribut två gånger på
samma element
BYGGER DU NYTT?
Då ska koden
validera helt
korrekt
T2. Layout och presentation
• Använd inte tabeller i layoutsyfte
T2. Layout och presentation
• Använd inte tabeller i layoutsyfte
• Separera information (html) och
layout/presentation (css)
• Säkerställ att gränssnittet kan
användas utan css
T3. Gränssnittets flexibilitet
• Gränssnittet ska vara responsivt
• All information och funktionalitet ska vara
möjlig att nå och använda oberoende av
skärmstorlek
• Webbplatsen är fullt användbar och
läsbar vid förstoring
T3. Gränssnittets flexibilitet
• Gränssnittet ska vara responsivt
• All information och funktionalitet ska vara
möjlig att nå och använda oberoende av
skärmstorlek
• Webbplatsen är fullt användbar och
läsbar vid förstoring
• Bilder bör redan på servern anpassas efter
olika skärmbredder
Lås inte möjligheten att zooma
Exempel på hur du inte ska göra.
<meta name="viewport"
content="width=device-width, initial-scale=1.0,
maximum-scale=1.0, user-scalable=no" />
T4. Ramar
• Använd inte <frame> och <frameset>
• <iframe> kan användas om:
• Det inte går att integrera tjänsten direkt i
publiceringssystemet
• Du sätter en title-text på iframe-elementet för
att förklara vad ramen innehåller
Exempel: iframe
<iframe src=”…” title=”Video om Funkas analysarbete”>
…
</iframe>
T5. Skript och hjälpmedel
T5. Skript
•
•
•
Använd skript för att öka användarnyttan
Låt grundläggande funktioner fungera utan
skript
Ge relevant hjälp om användaren blockerat
skript
Exempel: Meddelande till användaren
T5. Skript
•
•
•
•
Använd skript för att öka användarnyttan
Låt grundläggande funktioner fungera utan
skript
Ge relevant hjälp om användaren blockerat
skript
Gränssnittet måste gå att använda med
hjälpmedel
Exempel: Sökförslag
Fungerar med tangentbord och
fungerar med skärmläsare
Fungerar med
tangentbord men inte
med skärmläsare
T5. Skript
•
•
•
•
•
Använd skript för att öka användarnyttan
Låt grundläggande funktioner fungera utan
skript
Ge relevant hjälp om användaren blockerat
skript
Gränssnittet måste gå att använda med
hjälpmedel
Använd WAI-ARIA för att underlätta för
användare med hjälpmedel
T6. Navigation
• Det ska vara möjligt att navigera i
gränssnittet med mus, tangentbord och
pekskärm (och andra styrlösningar)
• Tabbordningen är logisk
• Fokus är visuellt tydligt
Exempel: Tabbfokus
T6. Navigation
• Det ska vara möjligt att navigera i
gränssnittet med mus, tangentbord och
pekskärm (och andra styrlösningar)
• Tabbordningen är logisk
• Fokus är visuellt tydligt
• Använd stora klickytor
T6. Navigation
• Det ska vara möjligt att navigera i
gränssnittet med mus, tangentbord och
pekskärm (och andra styrlösningar)
• Tabbordningen är logisk
• Fokus är visuellt tydligt
• Använd stora klickytor
• Var restriktiv med täckande lager
Viktigt att tänka på
• Gör bakgrunden omöjlig att nå
för skärmläsare, aria-hidden
• Gör så att
tangentbordsnavigationen
behålls i lagret, kräver skript
• Wai-aria:
role=”alertdialog” / ”alert”
• Tona ner runt om
T6. Navigation
• Lägg in genvägar för att göra det snabbare
att navigera med tangentbordet
• Använd knappar när adressen inte ändras,
använd länkar när adressen ändras
T7. Automatiska händelser
•
•
•
•
•
Använd RIA om information måste uppdateras löpande
Ladda inte om sidor utan att användaren bett om det
Informera användarna om tidsgränser
Gör det möjligt för användaren att justera tidsgränser
Använd aria-live för att indikera om ett hjälpmedel ska
informera användaren när information i en yta uppdaterats
(när det sker dynamiskt)
aria-live support
IE
Firefox
Safari
Jaws 15
-
Jaws 14
-
Jaws 13
-
Window-Eyes 8.3
-
Supernova 13.51
NVDA 2014:3
VoiceOver (iOS 6)
System Access 2014
-
-
-
-
Testerna har
gjorts med den
webbläsarversion
som varit aktuell
för den aktuella
versionen av
hjälpmedlet
T8. Formulär
• Koda ledtexter med label-element
• Knyt samman ett label-element med varje
formulärsobjekt (for-attributet i labelelementet pekar på id-värdet för
formulärsobjektet)
• Om det finns en logisk grupp i formuläret,
använd fieldset och legend
• Använd formulärsobjekt för delar i formuläret
Exempel: Ledtext
För att detta ska fungera för användare som har behov av olika
hjälpmedel för att ta till sig informationen måste det finnas en tydlig
koppling i koden mellan ledtexten och formulärsobjektet. Detta
åstadkoms med elementet label. Använd label-element för att lägga in
samtliga ledtexter.
<label for="name">Name:</label>
<input type="text" id="name“>
Exempel: Gruppering
Längre formulär måste delas upp och grupperas. Detta gör
det enklare att se vilka delar som hör samman, både visuellt
och i ett hjälpmedel. Grupperingar av objekt görs med hjälp
av fieldset och legend.
<fieldset>
<legend>Utdelningsadress:</legend>
<label for="name1">Namn:</label>
<input type="text" name="name1" id="name1">
...
</fieldset>
<fieldset>
<legend>Faktureringsadress:</legend>
...
</fieldset>
Exempel: Gruppering
Grupperingar av radioknappar och kryssrutor görs också med
hjälp av fieldset och legend.
<fieldset>
<legend>Kön:</legend>
<input type="radio" value=“Man" id="gender_male">
<label for="gender_male">Man</label>
<input type="radio" value=“Kvinna" id="gender_female">
<label for="gender_female">Kvinna</label>
</fieldset>
Title-attributet
Använd inte title-attributet
Fungerar inte alls på knappar
Fungerar dåligt på länkar
Använd label-element, om
nödvändigt kan de vara dolda
• Använd bara title i abbr-elementet
för förkortningar
•
•
•
•
T9. Struktur
•
•
•
•
•
Koda rubriker med h1-h6
Html5 elementen article och section ska
undvikas då de i en del hjälpmedel ändrar
rubrikstrukturen
Använd korrekta listor (ul/ol och li)
Undvik förkortningar
…om du har förkortningar använd abbrelementet
T10. Datatabeller
•
•
•
•
Rubrikceller måste kodas med th-element
och scope-attribut
En titel ovanför tabellen ska läggas in
med elementet caption
Använd bara tabellceller för tabelldata
Komplexa tabeller behöver specifika
kopplingar mellan rubriker och dataceller
Exempel: Enkel tabell
<table>
<caption>Flygpriser Stockholm-Luleå</caption>
<tr>
<th></th>
<th scope="col">2013-12-23</th>
<th scope="col">2013-12-24</th>
<th scope="col">2013-12-25</th>
</tr>
<tr>
<th scope="row">10:47</th>
<td>1125:-</td>
<td>422:-</td>
<td>1533:-</td>
</tr>
...
Exempel: Komplex tabell
<table>
<caption>Flygpriser Stockholm-Luleå</caption>
<tr>
<th></th>
<th colspan="3" id="ffa">Norwegian</th>
<th colspan="3" id="ff">SAS</th>
</tr>
<tr>
<th></th>
<th id="d071223a" headers="ffa">2013-12-23</th>
<th
<th
<th
<th
<th
</tr>
<tr>
id="d071224a"
id="d071225a"
id="d071223b"
id="d071224b"
id="d071225b"
headers="ffa">2013-12-24</th>
headers="ffa">2013-12-25</th>
headers="ff">2013-12-23</th>
headers="ff">2013-12-24</th>
headers="ff">2013-12-25</th>
<th id="morgon">Morgonflyg</th>
<td headers="ffa d071223a morgon">1125:-</td>
<td
<td
<td
<td
<td
</tr>
…
headers="ffa d071224a morgon">422:-</td>
headers="ffa d071225a morgon">1533:-</td>
headers="ff d071223b morgon">1099:-</td>
headers="ff d071224b morgon">650:-</td>
headers="ff d071225b morgon">1701:-</td>
T11. Länkar
• Om länkarna på din webbplats behöver
vara understrukna för att synas så ska
det inte vara beroende av inställningar i
din webbläsare
T12-T13. Bilder
•
Använd inte bilder för att visa text
T12-T13. Bilder
•
•
•
Använd inte bilder för att visa text
Komplettera bilder med en alt-text
Tala om för användaren var
denne hittar motsvarande
information I text
Klicka på bilden för att komma till exemplet
Exempel där alt-texten bör vara tom
Exempel
Exempel
T14. Ljud
• Information som presenteras som
ljud är även förklarad i text
• Bakgrundsljud kan enkelt stängas
av manuellt eller avslutas
automatiskt
inom 3 sekunder
T15. Komplexa medieformat
exempelvis film och pdf
• Det finns en lämplig textbeskrivning av
material i komplexa format i anslutning till
materialet
• Material som presenteras med komplexa
medieformat har tillgänglighetssäkrats
T16. Färger och kontraster
• Webbplatsen blockerar inte
användarens möjlighet att göra
egna inställningar av färg och
teckensnitt i webbläsaren
T17. Rörelser i gränssnittet
• Undvik rörliga objekt…
• …men om du har sådana,
se till att de går att pausa
T18. Information och hjälp
• Sidorna har unika och relevanta sidtitlar
• Metadata ger information som har
betydelse för sidan och webbplatsen
• Sidans huvudsakliga språk är angivet i koden
• Språk som avviker från sidans huvudsakliga
språk är angivet i koden
• Om en förklaring finns för hur en användare
med hjälpmedel ska hantera
en viss funktion bör förklaringen och
funktionen vara sammankopplade
Tre delar
Innehåll
Teknik
Pedagogik
P3. Logik
•
Konsekvent benämning och utformning
Exempel, samma webbplats, olika objekt som fäller ut områden:
P4. Begriplighet
•
•
Förstår användarna var ändringar sker?
Ge relevant återkoppling
P4. Begriplighet
•
•
•
Förstår användarna var ändringar sker?
Ge relevant återkoppling
Undvik att länka till den aktiva sidan/vyn
P6. Sökfunktion
•
Det behövs alltid minst två sätt att hitta
en specifik sida
P9. Utformning av formulär
•
•
Konsekvent
Låt användaren kunna ångra sig
P10. Utformning av knappar
•
•
Konsekvent placering, utformning och
benämning
Var tydliga med funktionen
P11. Felhantering
•
Informera om vad som är fel och hur
det ska åtgärdas
P12. Länkar
•
•
Varje länk och knapp ska tydligt
redogöra för syftet
Undvik title-texter
P15. Färger och kontraster
•
Använd färger men förlita dig inte på
dem
Exempel: Beroende av färg
Exempel: Beroende av färg
P15. Färger och kontraster
•
•
•
•
Använd färger men förlita dig inte på
dem
Använd goda kontraster
Undvik röriga bakgrunder
Undvik rörliga objekt, men om du har
sådana, se till att de går att pausa
P19. Hjälp
•
•
•
Erbjud hjälp där det behövs
Informera om alternativ
Specifik information till
hjälpmedelsanvändare?
Sikta inte bara
på WCAG, utgå
från användarna
Det finns inga
normalanvändare
