E-legitimationsnämnden – Prototyp av
anvisningstjänst
Kontakt:
Carl Törnquist, [email protected], 073-640 43 30
Max Walter, [email protected], 073-047 61 16
Hornsbruksgatan 19
SE-117 34 Stockholm
T: +46 (8) 506 533 00
www.metamatrix.se
Innehållsförteckning
Innehållsförteckning ....................................................................................................... 2
1
Introduktion ............................................................................................................. 4
2
Metod och genomförande ....................................................................................... 4
3
Prototyp av anvisningstjänst ................................................................................... 5
3.1
Övergripande design ....................................................................................... 6
3.2
Sidhuvud.......................................................................................................... 7
3.3
Funktionsmeny ................................................................................................ 8
3.4
Välj e-legitimation .......................................................................................... 10
3.4.1
Snabbval av e-legitimation ..................................................................... 12
3.4.2
Visa alla e-legitimationer ........................................................................ 13
3.4.3
Sökfunktion (filtrering) ............................................................................ 13
3.4.4
Tillbaka till............................................................................................... 14
3.5
Hjälpavsnitt .................................................................................................... 15
3.6
Sidfot ............................................................................................................. 15
4
Rekommendationer .............................................................................................. 16
5
Bilaga A: Hur WCAG 2.0 har följts........................................................................ 17
5.1
Möjlig att uppfatta (WCAG 2.0 princip 1) ....................................................... 17
5.1.1
Tillhandahåll alternativ i form av text till all icke-textbaserad information
så att det kan konverteras till format som användarna behöver, till exempel stor
stil, punktskrift, tal, symboler eller enklare språk. (WCAG Riktlinje 1.1) .............. 17
5.1.2
Tillhandahåll alternativ till tidsberoende media. (WCAG Riktlinje 1.2) ... 18
5.1.3
Skapa innehåll som kan presenteras på olika sätt (exempelvis med
enklare layout) utan att information eller struktur går förlorad. (WCAG Riktlinje
1.3)
18
5.1.4
Gör det enklare för användare att se och höra innehåll, bland annat
genom att skilja förgrund från bakgrund. (WCAG Riktlinje 1.4) ........................... 20
5.2
Hanterbar (WCAG 2.0 princip 2) .................................................................. 22
5.2.1
2.1)
All funktionalitet ska vara åtkomlig med ett tangentbord (WCAG Riktlinje
22
5.2.2
Ge användaren tillräckligt med tid för att läsa och använda innehållet
(WCAG Riktlinje 2.2) ............................................................................................ 22
2 (26)
5.2.3
Designa inte innehåll på ett sätt som kan orsaka krampanfall (WCAG
Riktlinje 2.3) .......................................................................................................... 23
5.2.4
Tillhandahåll sätt att hjälpa användarna att navigera, hitta innehåll och
avgöra var de är (WCAG Riktlinje 2.4) ................................................................. 23
5.3
Begriplig (WCAG princip 3) ........................................................................... 24
5.3.1
Gör textinnehåll läsbart och begripligt (WCAG Riktlinje 3.1) ................. 24
5.3.2
Säkerställ att webbsidor presenteras och fungerar på ett förutsägbart
sätt (WCAG Riktlinje 3.2) ...................................................................................... 25
5.3.3
Hjälp användare att undvika misstag och rätta till misstag (WCAG
Riktlinje 3.3) .......................................................................................................... 25
5.4
Robust(WCAG princip 4) ............................................................................... 26
5.4.1
Maximera kompatibiliteten med nuvarande och framtida
användarprogram, inklusive hjälpmedel (WCAG Riktlinje 4.1) ............................ 26
3 (26)
1 Introduktion
Denna rapport är en bilaga till slutrapporten för utveckling av en prototyp för Svensk
E-legitimations anvisningstjänst. Det är en tjänst där användaren väljer e-legitimation
när de ska logga in på en myndighets e-tjänst. Prototypen för anvisningstjänsten har
utvecklats parallellt med att användningstester har gjorts på den.
Beställare av projektet är E-legitimationsnämnden i samarbete med
Användningsforum och Post- och telestyrelsen. Användningstester har gjorts av
Stelacon.
För att testa prototypen för anvisningstjänsten i ett realistiskt flöde anpassades
webbplatser för tre olika myndigheter för att fungera tillsammans med prototypen.
I dokumentet beskrivs metod, de designbeslut som tagits under projektet och en
rekommendation för hur projektet kan gå vidare. I en bilaga finns detaljerat vilka
tekniker som har använts för att uppnå WCAG 2.0 AAA-status.
2 Metod och genomförande
Prototyperna utvecklades i HTML, CSS, WAI-ARIA och Javascript för
användningstesterna och pappersskisser användes för att testa olika upplägg internt. I
användningstesterna deltog användare med olika funktionsnedsättningar, vilket gjorde
att prototypen behövde vara utvecklad i HTML, CSS och Javascript för att kunna
testas med hjälp av olika hjälpmedel.
Utveckling av prototyperna och användningstesterna skedde parallellt. Arbetet
skedde:
behovsstyrt enligt designprinciperna för offentliga digitala tjänster 1
iterativt (enligt designprincipen 5. Gör om. Gör sen om igen och 3. Låt
användningsdata styra designvalen) och
responsivt och ”mobile first” för att i första hand designa för mobila enheter
och sekundärt göra anpassningar för att förbättra upplevelsen på större
skärmar.
Att arbeta iterativt med användningstester skedde praktiskt genom att företaget
Stelacon utförde användningstesterna och kontinuerligt rapporterade om
användbarhetsproblem och andra problem med prototypen och de åtgärdades direkt i
prototypen.
1
https://www.anvandningsforum.se/designprinciper/
4 (26)
Skälet till att i första hand designa ”mobile first” är för att begränsa det designval som
kan göras. En design för mindre skärmar fungerar oftast bra även på en större skärm.
Däremot fungerar sällan en design för en större skärm på en mindre skärm. Att
designa i första hand för mindre skärmar gör det också lättare att underhålla en
responsiv webbplats. Referensgruppen informerade oss också om att användare med
funktionsnedsättningar i många fall endast har råd att ha en mobiltelefon och inte en
dator.
I ett tidigare projekt hade en prototyp för anvisningstjänsten utvecklats och i det här
projektet användes den som inspiration2. Det fanns inga krav på att den nya
prototypen skulle utgå från den gamla prototypen. För att i användningstesterna
kunna bekräfta vilka funktioner som det fanns behov av var den första versionen av
prototypen utformad enligt designprinciperna 4. Kämpa för att göra det enkelt och 5.
Gör om. Gör sen om igen. När det uppkom behov i användningstesterna eller från en
intressent (referensgrupp eller styrgrupp) lades komponenter och funktioner in i
prototypen och testades.
Under projektet togs komponenter och funktioner bort som inte användes eller inte
längre behövdes utifrån nya behov som kommit upp från användningstesterna eller
intressenterna.
Kravet på den slutliga lösningen var att den skulle följa WCAG 2.0 AAA3. Prototypen
följer WCAG 2.0 AAA i stort sett, med undantag för vad som nämns i bilaga A.
Prototypen har inte heller stöd för att användas utan Javascript, vilket den slutliga
produkten ska göra.
Prototypen skapades i en ny version för varje en större ändring som gjordes, antigen i
design eller kod (version 1, version 2 och så vidare), men även mindre uppdateringar
gjordes kontinuerligt på en version, till exempel ”version 1”. En del versioner testades
inte i användningstester. Prototypen versionshanterades i Git, vilket gör det möjligt att
se alla ändringar som har gjorts från att utvecklingen av prototypen började.
3 Prototyp av anvisningstjänst
I det här avsnittet förklaras de olika designbeslut som tagits under utvecklingen av
prototypen för anvisningstjänsten utifrån de olika versioner som har testats.
De versioner som gås igenom i det här avsnittet är:
Version 1 (http://www.mmx99.se/eleg/version1)
Version 4 (http://www.mmx99.se/eleg/version4)
Version 5 (http://www.mmx99.se/eleg/version5)
2
http://bit.ly/1O4A8ch
3
http://www.w3.org/TR/WCAG20/
5 (26)
Version 7 (http://www.mmx99.se/eleg/version7/sv/start.html)
Version 8 (http://www.mmx99.se/eleg/version8/sv/start.html)
Version 9 (http://www.mmx99.se/eleg/version9/sv/start.html)
Version 10 (http://www.mmx99.se/eleg/version10/sv/start.html)
Version 2 och Version 6 var versioner som aldrig visades utanför projektgruppen.
Version 9 skapades efter det sista användningstestet och Version 10 skapades efter
det sista mötet med referensgruppen. Version 10 har endast mindre grafiska
ändringar (för att rätta till kontraster) och skärmdumpar visas endast i de avsnitt där
det är aktuellt.
En del funktioner lades till i senare versioner, till exempel översättning till engelska
som lades till från version 8 och taluppläsning med Readspeaker från version 7.
Bilderna i avsnittet är tänkta för orientering och det rekommenderas att titta på de
olika versionerna av prototyperna i en webbläsare i samband med att det här avsnittet
läses igenom.
3.1 Övergripande design
Anvisningstjänsten är ett steg i ett flöde med fyra stycken steg:
1. Organisations webbplats
2. Anvisningstjänst
3. Legitimationstjänst (till exempel BankID eller Mobilt BankID)
4. Inloggad på e-tjänst på organisations webbplats
Den grafiska formen i steg 1, 3 och 4 är inte möjlig att påverka och kan vara olika
beroende på vem som ansvarar för de olika stegen. Anvisningstjänsten har därför
under utvecklingen haft en nedtonad grafisk form (se Figur 1) som inte ska
uppmärksammas av användarna.
Från den första versionen till den sista versionen av prototypen har den grafiska
formen gått från grå till vit för att bättre kunna hantera olika logotyper. De logotyper
som visas bestäms dels av den organisation som använder anvisningstjänsten (till
exempel Försäkringskassan, Skatteverket eller Stockholms stad) och dels av de som
utfärdar e-legitimationer (till exempel Mobilt BankID eller Telia). För att kunna hantera
att logotyper läggs in med vit bakgrundsfärg är alla logotyper placerade mot en vit
bakgrund. Rekommendationen är att det ska vara krav på att alla logotyper ska ha en
transparant bakgrundsfärg.
Den grafiska formen följer de riktlinjer som finns för kontrast mellan förgrunds- och
bakgrundsfärg i WCAG 2.0 AAA med undantag för ta bort-knapparna på grund av de
är en sekundär interaktion.
6 (26)
Figur 1 Från vänster till höger: Version 1, Version 4, Version 5, Version 7, Version 8, Version 9 och Version 10.
Alla delar i prototypen har designats för mindre skärmar i första hand och
komponenter eller funktioner har lagts för större skärmar endast om det inte påverkar
användarupplevelsen till det sämre på mindre skärmar. I alla versioner av prototypen
har upplägget på designen varit en kolumn och endast i undantagsfall har flera
kolumner används. Från version 7 är det två kolumner i sidhuvudet för att visa två
logotyper på samma rad.
3.2 Sidhuvud
I den första versionen av prototypen (se figur 1) hade alla logotyper tagits bort i
sidhuvudet för:
Att förenkla och testa hur användarna reagerade i användningstesterna.
Att minska höjden på sidhuvudet för att listan med e-legitimationer ska ta upp
den största delen av skärmytan på mindre skärmar.
Att göra anvisningstjänsten ”osynlig” för att minska den support som
myndigheten behöver hantera.
Logotyper för organisationen som användarna kommer ifrån till anvisningstjänsten och
Svensk e-legitimation lades till på grund av att det fanns ett behov från användarna att
kunna lita på anvisningstjänsten och att det finns ett krav från E-legitimationsnämnden
att det ska framgå tydligt att Svensk e-legitimation är en kvalitetsstämpel. För att
kunna skapa trovärdighet för anvisningstjänsten krävs också:
Att marknadsföra varumärket och kvalitetsstämpeln Svensk e-legitimation för
att den ska få samma igenkänningsfaktor som ”Svanen”- eller ”Krav”-märka
produkter.
Att webbadressen och SSL-certifikatet för anvisningstjänsten tydligt indikerar
avsändaren av anvisningstjänsten. Rekommendationen är att använda
adressen svenskelegitimation.se än www.sveleg.se eftersom det första är
tydligare. Jämför med när Sveriges radio gick från webbadressen www.sr.se
till www.sverigesradio.se eller Skatteverket gick från webbadressen
www.skv.se till www.skatteverket.se.
I den första versionen med logotyper var de inte klickbara på grund av att fokus skulle
vara att gå vidare i flödet för användarna. Från och med version 8 lades det till och när
användarna klickar på organisationens logotyp går de tillbaka till inloggningssidan på
organisations webbplats och genom att klicka på logotypen för Svensk e-legitimation
går de till en sida på E-legitimationsnämndens webbplats om Svensk e-legitimation4
Hur logotyperna ska användas finns det fortfarande olika åsikter om som inte är
testade:
4
Ska organisationens logotyp finnas med eller inte i sidhuvudet eller räcker det
med att namnet på myndigheten anges innan listningen av e-legitimationer.
Eventuellt kan logotypen placeras innan listningen istället för i sidhuvudet.
http://www.elegnamnden.se/privat
7 (26)
Istället för att ha Svensk e-legitimations logotyp i sidhuvudet ska den placeras
i listan i jämnhöjd med de e-legitimationer som är godkända som svenska elegitimationer. Till en början kommer alla e-legitimationer i listan vara
godkända som svenska e-legitimationer, vilket tillsammans med att det finns
logotyper för respektive e-legitimationer skulle innebära att det blir trångt i
listan med e-legitimationer på enheter med mindre skärmar. Det skulle
innebära att de olika logotyperna blir för små för att de ska kunna identifieras
av användarna på ett effektivt och enkelt sätt.
Att använda märkningen Svensk e-legitimation på varje rad blir mer aktuellt i
samband med att anvisningstjänsten ”bäddas in” (integreras) på
organisationernas webbplatser. Det är viktigt att anpassa designen för att det
ska fungera på mindre skärmar utan att logotyperna blir för små. Det har inte
ingått i projektet att ta fram riktlinjer eller en prototyp för att bädda in
anvisningstjänsten på en organisations webbplats.
Läs mer om diskussionen kring logotyper i listning av e-legitimationer under rubriken
Välj e-legitimation.
3.3 Funktionsmeny
Menyn som visas högst upp i de första versionerna av prototypen och under
sidhuvudet i de senare prototyperna kallas för funktionsmeny (se figur 1). I det tidigare
projektet där en prototyp tagits fram för anvisningstjänsten användes en så kallad
”hamburgermeny” för att få hjälp och ändra språk. Användningen av en
”hamburgermeny” medför ett extra steg för användarna för att kunna se vilka val de
har och ur ett tillgänglighetsperspektiv är det extra viktigt att det är tydligt vad
användarna kan göra.
I den de första versionerna av prototypen visades endast rubrikerna Choose language
och Lyssna och rubriken Hjälp var fast placerad i nederkant av skärmen. Det senare
var på grund av den hela tiden skulle vara synlig för användarna. I
användningstesterna märkte inte användarna den och den lades därför till i
funktionsmenyn.
På mindre skärmar får inte alla tre rubriker plats om de även ska ha ikoner och
ikonerna togs därför bort. I diskussionerna kring funktionsmenyn har ett alternativ varit
att lägga till en till rubrik: ”Om tjänsten” eller liknande. Det har inte lagts med på grund
av att funktionsmenyn då inte skulle få plats på en rad på mindre enheter.
Figur 2 Välj språk i funktionsmenyn. Från vänster till höger: version 8 och version 9
8 (26)
Det är viktigt att anvisningstjänsten ser bra ut för alla, även de som använder mindre
skärmar på grund av till exempel socioekonomiska aspekter.
När användarna klickar på någon av länkarna i funktionsmenyn blir resultatet olika
beroende på vilken länk som användarna klickar på:
Choose language – En meny öppnas där det är möjligt att välja språk. Den
första versionen av menyn (se figur 2) visades ovanför toppmenyn för att inte
dölja valet av e-legitimation om användaren tryckt fel. Nackdelen är att den
inte hamnar i rätt logisk ordning, vilket åtgärdades i en nästa version av
menyn.
Lyssna – Standardutformningen av Readspeaker användes i prototypen (se
figur 3) eftersom det inte prioriterades i prototypen att ta fram ett anpassat
gränssnitt av funktionen. Det är möjligt för användarna att markera en text i
prototypen och få den uppläst. När en anpassad version tas fram
rekommenderas att det även läggs till en länk för uppläsning i samband med
varje del av hjälpavsnittet.
Hjälp – Scrollar ned till slutet av sidan där mer information om hjälp finns.
Normalt ska samma utseende på länken innebära att resultatet blir det samma. I det
här fallet har bedömningen gjorts att det är godtagbart eftersom det i alla fall innebär
att användarna stannar kvar på sidan och lätt kan ångra det val de har gjort i
funktionsmenyn.
I de fall där användarna surfar till prototyp med en skärmläsare finns det dolda
ankarlänkar för att ”Gå till innehåll” och navigera snabbare i listan med många elegitimationer (se figur 4).
Figur 3 Taluppläsning (från version 7)
9 (26)
Figur 4 Dolda länkar för att underlätta navigering för användare med skärmläsare eller andra hjälpmedel.
3.4 Välj e-legitimation
Till en början kommer anvisningstjänsten endast att visa ett fåtal e-legitimationer, men
på längre sikt kommer flera svenska och även europeiska e-legitimationer att visas.
Under projektet har det förändrats i vilken utsträckning som prototypen behöver ha
stöd för att hantera många e-legitimationer. I den första delen av det här avsnittet
beskrivs översiktligt hur valet av e-legitimation kommer att fungera för att sedan i
underrubriker beskriva i detalj de olika komponenter och funktioner som funnits i olika
versioner av prototypen.
Utgångspunkten i projektet blev att prototypen ska vara hållbar för att både hantera ett
fåtal e-legitimationer eller flera e-legitimationer utan att försämra användarupplevelsen
i de olika fallen. I den sista versionen är det möjligt att ta bort olika komponenter för att
skapa en version som fungerar när det endast finns ett fåtal e-legitimationer och
många e-legitimationer (se figur 5).
Ett krav från E-legitimationsnämnden som kom sent i projektet var att inga elegitimationer får ”favoriseras”, till exempel genom att de listas först. När ett fåtal elegitimationer finns är det inte ett problem, men när de e-legitimationer som används
mest ligger i en lista med många e-legitimationer blir det ett problem (se figur 5 – Bild
2).
Följande två varianter finns utifrån den sista prototypen (se figur 5):
1. Figur 5 – Bild 1: Första gången som användarna besöker anvisningstjänsten i
webbläsaren finns ett fåtal e-legitimationer. Det är inte möjligt att ta bort någon
av e-legitimationerna i det här läget. Nästa gång användarna besöker
anvisningstjänsten visas endast den som användarna valde förut (Figur 5 –
Bild 3). För att visa alla behöver de klicka på ”Visa alla e-legitimationer”, men
det är inte möjligt att söka. Det är möjligt att ta bort den e-legitimation som
tidigare valts.
2. Figur 5 – Bild 2: När det finns fler än vad som får plats på en mindre skärm
och som användaren kan scrolla till med en swipe (ca 5-8 stycken) visas alla
e-legitimationer och en sökfunktion visas. Inte heller i den här listan är det
10 (26)
möjligt att ta bort en e-legitimation. När användarna surfar till
anvisningstjänsten nästa gång kommer endast den e-legitimation som valdes
vid föregående besök att visas. För att visa alla behöver de klicka på ”Visa
alla e-legitimationer”. Det är också möjligt att ta bort den e-legitimation som
tidigare valdes.
Figur 5 Till vänster (Bild 1): Ett fåtal e-legitimationer utan lista med alla. Mitten (Bild 2): Många elegitimationer, men ingen e-legitimation har tidigare valts. Till höger (Bild 3): Mobilt BankID har tidigare
valts och alla e-legitimationer är ihopfälld.
11 (26)
3.4.1 Snabbval av e-legitimation
I den första versionen av prototypen (se figur 6) hade anvisningstjänsten inte något
”minne” av vad användare valt för e-legitimation vid tidigare besök i anvisningstjänsten
i samma webbläsare. Hypotesen var att det räcker med att visa de mest populära elegitimationerna visas först eftersom det kommer göra det enkelt för de allra flesta
användare.
I version 5 lades funktionen att användare tidigare val i anvisningstjänsten visas i en
separat lista för att testa om det gjorde någon skillnad. Det var två listor: en med
tidigare valda e-legitimationer och en med de mest populära e-legitimationerna. Listan
med mest populära var ihopfälld vid andra besöket av en användare. Komponenten
tog mer skärmyta och det var otydligt för användarna vad skillnaden var mellan
listorna.
Från version 7 kombinerades listorna ihop och när användarna valde en e-legitimation
som inte ingick bland de mest populära e-legitimationerna lades den till i listan. Det
var också möjligt att ta bort de e-legitimationer som användarna antingen har lagt till
eller ta bort någon av de förvalda populära e-legitimationerna.
I version 10 beror upplägget på snabbvalet av e-legitimation på hur många elegitimationer som ska finnas i anvisningstjänsten och beskrivs i föregående avsnitt.
I den första versionen av prototypen användes inte logotyper för varje e-legitimation
för att minska höjden på varje rad. Logotyper kan inte vara för små i gränssnittet
eftersom det då blir svårt att identifiera dem för användarna. Det finns inte heller något
krav på leverantörerna av e-legitimationerna att de ska vara tillgängliga. Från och med
version 4 lades logotyper in för en del av e-legitimationerna, vilket gjorde att varje rad
blev högre i listan. Rekommendationen är att det i kraven för de som har elegitimationer ska ha logotyper som är tydliga för alla.
I snabbvalet har det funnits tre till fyra e-legitimationer med ikoner och det har inte
testats att ha ikoner i den längre listan som beskrivs under nästa rubrik.
Figur 6 Från vänster till höger: Version 1, Version 4, Version 5, Version 7, Version 8, Version 9
12 (26)
Figur 7 Från vänster till höger: Version 1, Version 4, Version 5, Version 7, Version 8, Version 9
3.4.2 Visa alla e-legitimationer
Listan med alla e-legitimationer har ungefär sett likadan ut i alla versioner och det har
gjorts förändringar i den grafiska formen och att listan är ihopfälld som standard från
version 5 (se figur 7).
Listan sorteras i bokstavsordning eftersom det är lätt för användare när det är en
längre lista att identifiera hur de ska navigera i listan. Det har fungerat i
användningstesterna både när listan varit utfälld och ihopfälld.
Om användarnas e-legitimation inte finns i listan finns det en länk längst ner i listan
som när användarna klickar på den scrollar och öppnar hjälpavsnittet om varför inte
en e-legitimation finns i listan.
Mer om sökfunktionen under nästa rubrik.
3.4.3 Sökfunktion (filtrering)
Sökfunktionen har varit en del av prototypen sedan den första versionen (se figur 7),
men har används av få användare under användningstesterna. De användare som
använde sökfunktionen mest var de som använde en skärmläsare i
användningstesterna.
Sökfunktionen filtrerar listan på de ord som användarna anger enligt följande kriterier:
Filtreringen av listan sker i hela namnet för varje e-legitimation, till exempel en
sökning på ”bankid” ger resultat ”BankID” men också ”Mobilt BankID”.
Sökningen görs inte från början av namnet på grund av att det finns elegitimationer där hypotesen är att de kan söka på något annat, som
exemplet i föregående mening.
Filtreringen påbörjas direkt efter att användarna har skrivit in tre stycken
bokstäver, eftersom sökning fungerar som beskrivet i föregående punkt.
Om användarna skriver in ett ord där de placerar ett tecken fel, till exempel
”bankdi” visas fortfarande de e-legitimationer som heter något med ”BankID”.
13 (26)
Det är möjligt i den tekniska lösning som används5 att finjustera hur känslig
en filtrering ska vara för felstavningar.
På grund av den begränsade användningen av sökfunktionen i användningstesterna
har inga justeringar gjorts av hur filtreringen sker.
I de första versionerna av prototypen fanns det inte tillräckligt bra stöd för användare
med skärmläsare att göra en sökning, men från och med version 9 finns det stöd för
att kontinuerligt läsa upp hur många e-legitimationer som finns efter att en filtrering har
gjorts.
I de första versionerna hade sökfunktionen en knapp för att göra sökningen om inte
Javascript var aktiverat. Det orsakade problem på grund av det inte fanns någon
teknisk lösning för det och knappen inaktiverades på grund av det. Från och med
version 8 togs knappen bort och i version 10 lades den till, men doldes för användare
som har Javascript aktiverat.
Om användarna anger ett ord i sökfunktionen visas ett meddelande om att matchande
e-legitimation inte finns, och en länk som när användarna klickar på den scrollar ner
till hjälpavsnitt om varför en e-legitimation inte finns i listan.
3.4.4 Tillbaka till
Efter listan med alla e-legitimationer finns en länk för att gå tillbaka till organisationen
som använder anvisningstjänsten för inloggning (se figur 8). I de första versionerna
var länken inte tillräckligt tydlig och i version 7 och version 8 ”glömdes” länken bort för
att i version 9 läggas in med en tydligare design.
Figur 8 Från vänster till höger: Version 1, Version 4, Version 5, Version 7, Version 8, Version 9
5
http://kiro.me/projects/fuse.htmliro.me/projects/fuse.html
14 (26)
3.5 Hjälpavsnitt
Syftet med hjälpavsnittet är att kortfattat beskriva hur de vanligaste problemen med
inloggning på en e-legitimation ska lösas och beskriva anvisningstjänsten (se figur 9).
I den första versionen av prototypen visades alla de frågor som funnits i förra projektet
där en prototyp för anvisningstjänsten togs fram. I kommande versioner kunde flera
frågor tas bort för att de inte längre var aktuella och frågorna skrevs om.
Projektgruppen och språkkonsulter skrev om alla rubriker och texter när det framkom i
användningstesterna att texterna var svåra att ta till sig.
Figur 9 Från vänster till höger: Version 1, Version 4, Version 5, Version 7, Version 8, Version 9
3.6 Sidfot
Syftet med sidfoten är att det ska framgå vem som är avsändare av
anvisningstjänsten. Till en början i projektet antogs det vara Svensk e-legitimation och
det var först i version 9 som den ändrades till E-legitimationsnämnden.
På grund av att inte användarna ska vända sig till Svensk e-legitimation eller Elegitimationsnämnden för support har inte webbriktlinjen för hur kontaktuppgifter ska
anges6 följts. Inga kontaktuppgifter är utskrivna i sidfoten och i första versionerna var
inte logotypen länkad heller. Från och med version 8 länkar logotypen i sidfoten till en
sida om Svensk e-legitimation på E-legitimationsnämndens webbplats.
6
http://webbriktlinjer.se/r/4-informera-om-myndighetens-kontaktvagar/
15 (26)
4 Rekommendationer
Att arbeta i många iterationer och göra användningstester kontinuerligt har gjort det
möjligt att snabbt avfärda hypoteser som inte fungerar. Alla komponenter och
funktioner har lagts till i prototypen utifrån ett specifikt behov som antingen funnits
med utifrån tidigare erfarenheter, användarnas behov som kommit upp på
användningstesterna eller krav som kommit från intressenter i projektet. Komponenter
och funktioner som inte har fungerat har tagits bort och det som inte har använts har
också tagits bort för att se om det saknats.
Nya versioner av prototypen har tagits fram kontinuerligt ända fram till slutet av
projektet och nya behov och krav har tillkommit. Det gör att det finns följande
utestående frågor som behöver testas framöver:
Ta bort logotyper i sidhuvudet och/eller ta bort organisationens namn ovanför
listan med e-legitimationer.
Placera av logotypen för Svensk e-legitimation (”nyckelhålet”) och EUförtroendemärket för kvalificerade betrodda tjänster (”portföljen”).
Finjustera sökfunktionen för att hantera alla typer av felstavningar.
Testa de olika varianterna i version 10 av prototypen (se figur 5).
Förbättring av sökfunktion för användare med skärmläsare.
Testa med riktig webbadress (svenskelegitimation.se) för att se om det
påverkar förtroendet för tjänsten.
Testa hela flödet från organisation, via anvisningstjänst och legitimationstjänst
tillbaka till myndigheten med riktiga e-legitimationer, till exempel BankID och
Mobilt BankID.
Testa med flera språk, till exempel med minoritetsspråken i Sverige.
Eventuellt behöver en högerställd version testas om till exempel arabiska ska
läggas in som språk.
Testa Readspeaker med riktig design och eventuellt lägga till läsupp-knapp i
anknytning till hjälpavsnittet.
Åtgärda vad som är kvar för att uppnå WCAG 2.0 AAA (se mer detaljerat i
bilaga A):
o
Kontrollera att alla kombinationer av skärmläsare och webbläsare
fungerar.
o
Hur ska användarna i anvisningstjänsten informeras om att
sessionstiden som organisation som använder anvisningstjänsten har
satt håller på att ta slut. (Hanterbar)
o
Lättläst sammanfattning. (Begriplig)
o
Teckenspråksversion. (Begriplig)
16 (26)
5 Bilaga A: Hur WCAG 2.0 har följts
I det här avsnittet listas de tekniker som har använts för att uppnå nivå AAA för WCAG
2.0 i prototypen och de fall där nivån inte har kunnat uppnås i prototypen. I de senare
fallen beskrivs vilka åtgärder som behöver göras för att uppnå den när lösning
utvecklas för produktion.
För att göra realistiska användningstester har Javascript använts för att avgöra vilket
anpassat innehåll som ska visas i prototypen, till logotyp för Försäkringskassan eller
Skatteverket. Det har i en del fall orsakat problem med att följa WCAG 2.0 och i de fall
det har varit problem kommenteras det i avsnitten nedan.
Tekniker bygger på information från How to Meet WCAG 2.0.7 Under varje rubrik listas
de situationer som ska stödjas i prototypen. I de fall där prototypen saknas innehåll
som berörs av situationen anges det.
I de fall där inte en officiell svensk översättning har funnits har de engelska
beskrivningarna använts för att minska risken för missförstånd.
I prototypen används Readspeaker för uppläsning och upplägget på den är som den
har levererats till projektet och därför har inte den delen av prototypen granskats i
följande kapitel.
5.1 Möjlig att uppfatta (WCAG 2.0 princip 1)
5.1.1 Tillhandahåll alternativ i form av text till all icke-textbaserad
information så att det kan konverteras till format som användarna
behöver, till exempel stor stil, punktskrift, tal, symboler eller
enklare språk. (WCAG Riktlinje 1.1)
Situation A: If a short description can serve the same purpose and present the
same information as the non-text content
o
Situation B: If a short description can not serve the same purpose and present
the same information as the non-text content (e.g., a chart or diagram)
o
Inget innehåll i prototypen som inte kan förklaras med en kort
beskrivning.
Situation C: If non-text content is a control or accepts user input
o
7
Alt-texter används för logotyper i sidhuvud och sidfot (H37)
Ankarlänkar (interna länkar) på sidan beskriver den information som
de går till. (H30)
https://www.w3.org/WAI/WCAG20/quickref/
17 (26)
o
Länktext: Hjälp
Tabellindex för alla e-legitimationer beskrivs med attributet
aria-label.
Länktext: Jag hittar inte min e-legitimation i slutet av listan
med alla e-legitimationer.
Länktext: Läs mer om vilka e-legitimationer som finns.
Sökrutan beskrivs med en label som är dold visuellt. (H44)
Inget innehåll av den här typen finns i prototypen.
Situation E: If non-text content is a CAPTCHA
o
Länktext: Gå till innehåll
Situation D: If non-text content is time-based media (including live video-only
and live audio-only); a test or exercise that would be invalid if presented in
text; or primarily intended to create a specific sensory experience
o
Ingen CAPTCHA används i prototypen.
Situation F: If the non-text content should be ignored by assistive technology
o
Logotyper i listorna har tomt alt-attribut.
o
Ikonen för Ta bort knapp är en button-tag med texten ”Ta bort Mobilt
BankID” som är visuellt dolt.
o
Med vissa webbläsare fungerar det inte att läsa upp texten för elegitimationen om den har en logotyp. En visuellt dold text har lagts
till. Det löser problemet, men gör att i Internet Explorer med
skärmläsare läses den upp dubbelt.
Kommentar: Under utvecklingen av prototypen var ett problem att när logotyper
ändrades mellan användningstesterna med Javascript ändrades inte alt-texterna. Det
åtgärdades och ska inte vara ett problem när metadatatjänsten sköter vad som ska
visas i anvisningstjänsten.
5.1.2 Tillhandahåll alternativ till tidsberoende media. (WCAG Riktlinje
1.2)
Ingen tidsberoende media har använts i prototypen.
5.1.3 Skapa innehåll som kan presenteras på olika sätt (exempelvis
med enklare layout) utan att information eller struktur går
förlorad. (WCAG Riktlinje 1.3)
5.1.3.1 Info and Relationships (1.3.1)
Situation A: The technology provides semantic structure to make information
and relationships conveyed through presentation programmatically
determinable
18 (26)
o
HTML5 element används för att beskriva upplägget i prototypen.
(G115)
o
I hjälpavsnittet används em-taggen för att förstärka vissa delar. (H49)
o
Ingen visuell presentation används för att ge information till
användarna (G117)
o
Innehåll och presentation är separerad och det är möjligt att lägga på
en annan CSS. En del div-taggar har används för presentation, vilket
påverkar vilka CSS-selcetors som kan användas. (G140)
o
De övriga tekniker som har använts och är relevanta i prototypen är:
Meddelanden när en e-legitimation tas bort eller när en
sökning inte leder till något resultat beskrivs semantiskt med
aria-attribut. (G138)
Tabeller har inte använts i prototypen. (H51, H39, H73, H63,
H43)
Sökrutan beskrivs med en label som är dold visuellt. (H44)
Inga grupper av formulär används (H65, H71, H85)
Grupper av länkar ligger i ul- och dl-taggar och beskrivs med
hjälp av attributet aria-described by (H48)
Rubrik-taggar (H) används i prototypen. (H42)
När en sökning görs och innehållet uppdateras meddelas hur
många e-legitimationer som finns kvar i listan. (SCR21)
Fungerar inte i Internet Explorer.
När en e-legitimation tas bort läses meddelandet som visas
upp i skärmläsaren. (SCR21)
När en sökning inte ger några sökträffar läses
felinformationen upp. (SCR21)
Situation B: The technology in use does NOT provide the semantic structure
to make the information and relationships conveyed through presentation
programmatically determinable
o
Ingen visuell presentation används för att ge information till
användarna (G117)
o
Standard-taggar används för stycken, listor och rubriker (T1, T2 och
T3)
5.1.3.2 Meaningful Sequence (1.3.2)
Allt innehåll ligger semantiskt i den ordning som de presenteras visuellt. (G57
och C27)
I den nuvarande versionen av prototypen finns inte stöd för höger-tillvänsterspråk (H34 och H56)
Semantisk markup används för att ordningen ska vara användbar även utan
visuell presentation. (C6)
19 (26)
Blanksteg används inte för visuell presentation (C8)
5.1.3.3 Sensory Characteristics (1.3.3)
Inga hänvisningar till visuell presentation av komponenter används i
prototypen. (G96)
5.1.4 Gör det enklare för användare att se och höra innehåll, bland
annat genom att skilja förgrund från bakgrund. (WCAG Riktlinje
1.4)
5.1.4.1 Use of Color (1.4.1)
Situation A: If the color of particular words, backgrounds, or other content is
used to indicate information.
o
Färger används inte i prototypen för att kommunicera information utan
att det även finns text och symboler – meddelanden när användarna
tar bort en legitimation eller när sökfunktionen inte hittar någon elegitimation. (G14)
o
Färger används inte för att beskriva hur ett formulär ska användas i
prototypen. (G205)
o
Länkar som ingår i navigering har annan färg och deras position i
gränssnittet visar att de är länkar. I brödtext är länkar understrukna.
(G182)
o
Kontrasten mellan förgrund och bakgrund är tillräckligt hög (3:1).
(G183)
Situation B: If color is used within an image to convey information.
o
I prototypen finns inga bilder, diagram eller annat innehåll som
använder färger för att förmedla innehållet. (G111, G14)
5.1.4.2 Audio Control (1.4.2)
Ljud används inte i prototypen.
5.1.4.3 Contrast (Minimum) (1.4.3)
Situation A: text is less than 18 point if not bold and less than 14 point if bold
o
Alla texter är antingen svarta eller en mörk nyans av blå, vilket gör att
kontrasten är minst 4.5:1. (G18)
Situation B: text is at least 18 point if not bold and at least 14 point if bold
o
Alla större texter är antingen svarta eller en mörk nyans av blå, vilket
gör att kontrasten är minst 3:1. (G145)
5.1.4.4 Resize text
Det går att förstora texten till 200 procent i prototypen. (G142)
5.1.4.5 Images of Text
CSS används för att hantera hur innehållet på webbplatsen ska presenteras.
(C22)
20 (26)
Logotyper i sidhuvud och sidfot använder en alt-text för att beskriva dess
innehåll. Övriga logotyper saknas alt-text, men i närheten av bilden skrivs
logotypernas rubrik ut i text. (C30)
Innehåll och presentation är separerad och det är möjligt att lägga på en
annan CSS. En del div-taggar har används för presentation, vilket påverkar
vilka CSS-selectors som kan användas. (G140)
5.1.4.6 Contrast (Enhanced)
Kontrasterna mellan förgrunds- och bakgrundsfärg är minst 7:1 eller 4:5
beroende på storlek på texten för allt förutom ”Ta bort”-knapparna som har
sämre kontrast. Det är en avvägning för att den knappen ska indikera att det
är en sekundär interaktion och att den inte är absolut nödvändig för att utföra
den primära uppgiften i prototypen. (G17 och G18).
5.1.4.7 Low or No Background Audio
Ljud används inte i prototypen.
5.1.4.8 Visual Presentation
First Requirement: Techniques to ensure foreground and background colors
can be selected by the user
o
Second Requirement: Techniques to ensure width is no more than 80
characters or glyphs (40 if CJK)
o
I hjälpavsnittet är linjehöjden satt till 150%. (C21)
Fifth Requirement: Techniques to ensure text can be resized without assistive
technology up to 200 percent in a way that does not require the user to scroll
horizontally to read a line of text on a full-screen window
o
5.1.4.9
Allt text är vänsterställd och i prototypen finns inget stöd för
högerställda språk. (G169)
Fourth Requirement: Techniques to ensure line spacing (leading) is at least
space-and-a-half within paragraphs, and paragraph spacing is at least 1.5
times larger than the line spacing
o
När webbplatsen görs smalare i en webbläsare eller presenteras på
en mindre skärm anpassas texten till storleken och användarna
behöver aldrig scrolla i sidled. I hjälpavsnittet blir en rad aldrig längre
än ca 75 tecken. (G204)
Third Requirement: Techniques to ensure text is not justified (aligned to both
the left and the right margins)
o
Det är inte möjligt att ändra förgrunds- och bakgrundsfärg i prototypen
direkt i gränssnittet, utan behöver göras med en alternativ CSS-fil.
När webbläsarens fönster eller skärmens storlek görs smalare
anpassas textflödet och ingen horisontell scrollning behövs. (saknas
referens)
Images of Text (No Exception)
21 (26)
Samma som för Images of Text.
5.2 Hanterbar (WCAG 2.0 princip 2)
5.2.1 All funktionalitet ska vara åtkomlig med ett tangentbord (WCAG
Riktlinje 2.1)
5.2.1.1 Keyboard (2.1.1)
Alla delar av webbplatsen är möjligt att komma åt med hjälp av tangentbordet.
(G202)
Standardkomponenter i HTML används för formulär och länkar i prototypen.
Språkmenyn har en aria-role för att förmedla hur den ska användas. (H91)
Det är möjligt att använda både mus och tangentbord med funktioner som är
beroende av javascript, till exempel språkmeny och sökfunktionen. (G90)
5.2.1.2
No Keyboard Trap (2.1.2)
Alla komponenter som finns i prototypen är det alltid möjlig att ta sig ur, till
exempel språkmenyn. (G21)
5.2.1.3 Keyboard (No Exception) (2.1.3)
Utöver det som beskrivs under rubriken Keyboard är inga funktioner på sidan
beroende av att användarna ska kunna trycka på tangentbordet vid en viss
tidpunkt.
5.2.2 Ge användaren tillräckligt med tid för att läsa och använda
innehållet (WCAG Riktlinje 2.2)
5.2.2.1 Timing Adjustable (2.2.1)
Situation A: If there are session time limits
o
Situation B: If a time limit is controlled by a script on the page
o
I prototypen finns ingen sessionshanteringen, men i den slutliga
produkten kommer det finnas en begränsning. Det är oklart när det
här skrivs om det är möjligt att förlänga sessionstiden.
I prototypen finns inga script som sätter en gräns för hur länge
Situation C: If there are time limits on reading
o
I prototypen finns inget innehåll som uppdateras efter att sidan har
laddats.
5.2.2.2 Pause, Stop, Hide (2.2.2)
I prototypen finns det inget innehåll som behöver pausas, stoppas eller gömmas.
5.2.2.3 No Timing (2.2.3)
I prototypen finns ingen tidsbegränsningen, men i den slutliga produkten
kommer det eventuellt finnas en begränsning som den organisation/tjänst som
använder anvisningstjänsten kommer att sätta.
22 (26)
5.2.2.4 Interruptions (2.2.4)
I prototypen finns inget innehåll som uppdateras.
5.2.2.5 Re-authenticating (2.2.5)
I prototypen för anvisningstjänsten görs ingen validering av
användningsuppgifter, men i den slutliga produkten finns en session kopplad
till anvisningstjänsten.
5.2.3 Designa inte innehåll på ett sätt som kan orsaka krampanfall
(WCAG Riktlinje 2.3)
5.2.3.1 Three Flashes or Below Threshold
I prototypen finns inget som blixtrar eller blinkar. I samband med att en
sökning görs uppdateras sökresultatet först efter tre tecken för att undvika för
många uppdateringar under gränsvärdena. Därefter är uppdateringen fördröjd
och en animation används för att göra uppdatering mer följsam.
5.2.3.2 Three Flashes
I prototypen finns inget som blixtrar eller blinkar.
5.2.4 Tillhandahåll sätt att hjälpa användarna att navigera, hitta
innehåll och avgöra var de är (WCAG Riktlinje 2.4)
5.2.4.1 Bypass Blocks (2.4.1)
En ”Gå till innehåll” finns som första länk i prototypen. (G1)
För de två listor med e-legitimationer som finns i prototypen finns det dolda
länkar för att hoppa till första elementet efter listorna. (G123)
”Gå till innehåll” och länken ”Hjälp” i funktionsmeny går till de två delar av
webbplatsen som finns. (G124)
Aria-landmarks används som komplement till HTML5-taggar. (ARIA11)
Rubriker (H-taggar) används för varje del av sidan. (H69)
Listan ”Alla e-legitimationer” och frågor i Hjälp-avsnittet är ihopfällda för att
underlätta navigering. (SCR28)
5.2.4.2 Page Titled (2.4.2)
Titeln beskriver vad användarna ska utföra i anvisningstjänsten. (G88 och
H25)
5.2.4.3 Focus Order (2.4.3)
Tabordning och innehållet i DOM är i en logisk ordning för användarna. (G59,
H4, C27)
Ändringar i prototypen med hjälp av script har kvar en logisk ordning för att
tabba respektive innehållet i DOM. (SCR26 och SCR27)
5.2.4.4 Link Purpose (In Context) (2.4.4)
Länkar och ankarlänkar har texter som beskriver var någonstans användarna
kommer att hamna. (G91 och H30)
23 (26)
Alla logotyper i sidhuvud och sidfot som är länkar har en alt-text. Övriga
logotyper saknar alt-text, men har en beskrivande text i anslutning till bilden.
(H24)
I prototypen har endast en sida tagits fram som ska vara tillgänglig. Inga
alternativa versioner har tagits fram för att möta tekniker som G189 och
SCR30.
Alla länk-texter i prototypen går att förstå utan att läsa dem i sitt sammanhang
(se Link Purpose (Link Only).
5.2.4.5 Multiple Ways (2.4.5)
Anvisningstjänsten består av endast en sida.
5.2.4.6 Headings and Labels (2.4.6)
Beskrivande rubriker används i prototypen. (G130)
Labeln för sökrutan är beskrivande. (G131)
5.2.4.7 Focus Visible (2.4.7)
En blå ruta används för att visa vilket element i prototypen som har fokus.
(G149,C15)
5.2.4.8 Location (2.4.8)
Den organisation/tjänst som användarna kommer ifrån till anvisningstjänsten
anges i text och logotyp. Det finns också en knapp för att gå tillbaka till
organisationen/tjänsten.
Anvisningstjänsten består endast av en sida.
5.2.4.9 Link Purpose (Link Only) (2.4.9)
Alla länk-texter i prototypen går att förstå utan att läsa dem i sitt sammanhang
(se Link Purpose (Link Only).
5.2.4.10 Section Headings (2.4.10)
Sidan organiseras med hjälp av rubriker (H-taggar). (G141 och H69)
5.3 Begriplig (WCAG princip 3)
5.3.1 Gör textinnehåll läsbart och begripligt (WCAG Riktlinje 3.1)
5.3.1.1 Language of Page (3.1.1)
Det är möjligt att programmatiskt bestämma vilket språk som används i
prototypen med hjälp av lang-attributet på html-taggen. (H57)
5.3.1.2 Language of Parts (3.1.2)
I anvisningstjänsten visas huvuddelen av sidan på ett språk. Valet av språk
skrivs ut med begreppet för språket på språket som ska väljas, till exempel för
engelska ”English”, för svenska ”Svenska”. I de fallen används ett lang-attribut
lokalt. (H58)
5.3.1.3 Unusual Words (3.1.3)
Inga avancerade ord i Anvisningstjänsten och det har kontrollerats av externa
språkkonsulter och i användningstester.
24 (26)
5.3.1.4 Abbreviations (3.1.4)
Inga förkortningar används i prototypen.
5.3.1.5 Reading Level (3.1.5)
Innehållet på sidorna är skrivna med klarspråk. (G153)
Ingen lättläst sammanfattning av sidan finns. (G86)
Readspeaker används på webbplatsen för att läsa upp innehållet. (G79)
Ingen teckenspråksversion av innehållet på webbplatsen finns. (G160)
5.3.1.6 Pronunciation (3.1.6)
Inga ord på svenska och engelska i prototypen finns som är svåra att uttala.
5.3.2 Säkerställ att webbsidor presenteras och fungerar på ett
förutsägbart sätt (WCAG Riktlinje 3.2)
5.3.2.1 On Focus (3.2.1)
Inga förändringar av sammanhang görs på webbplatsen i samband med att
en komponent får fokus.
5.3.2.2 On Input (3.2.2)
När användarna byter språk har menyn namnet ”Choose language”. (G13)
I den dolda labeln för sökfältet nämns att sökningen påbörjas efter att tre
tecken har angetts. Varje gång sökresultatet uppdateras ges en beskrivning
av hur många resultat som finns i listan och vad användarna ska göra för att
gå igenom resultaten. (G13)
För användare utan Javascript aktiveras visas en Submit-knapp för
sökfunktionen. (G80 och H32)
5.3.2.3 Consistent Navigation (3.2.3)
Anvisningstjänsten består endast av en sida och alla komponenter visas i
samma ordning oavsett från vilken organisation/tjänst som användarna
kommer ifrån. (G61)
5.3.2.4 Consistent Identification (3.2.4)
Samma resonemang som föregående rubrik. (G197)
5.3.2.5 Change on Request (3.2.5)
Alla ändringar av sammanhang i prototypen initieras av användarna.
5.3.3 Hjälp användare att undvika misstag och rätta till misstag
(WCAG Riktlinje 3.3)
5.3.3.1 Error Identification (3.3.1)
Inga fält är obligatoriska eller har krav på typ av input i prototypen.
5.3.3.2 Labels or Instructions (3.3.2)
Sökfältet har en label som är dold. (G131, G162)
För val av listorna med e-legitimationerna används attributet aria-describedby.
(ARIA1)
25 (26)
5.3.3.3 Error Suggestion (3.3.3)
Inga fält är obligatoriska eller har krav på typ av input i prototypen.
5.3.3.4 Error Prevention (Legal, Financial, Data) (3.3.4)
Anvisningstjänsten hanterar inte juridisk information, finansiell information
eller data.
När användarna tar bort en e-legitimation är det möjligt att ångra att elegitimationen tagits bort. (G99)
5.3.3.5 Help (3.3.5)
I funktionsmenyn finns en hjälp-länk. (G71)
Om användarna söker på ett namn i sökfältet finns det en länk till mer
information om varför e-legitimationen inte finns i listan.
5.3.3.6 Error Prevention (All) (3.3.6)
Se rubriken Error Prevention (Legal, Financial, Data).
5.4 Robust(WCAG princip 4)
5.4.1 Maximera kompatibiliteten med nuvarande och framtida
användarprogram, inklusive hjälpmedel (WCAG Riktlinje 4.1)
5.4.1.1 Parsing (4.1.1)
HTML-koden validerar enligt HTML5. (G134 och H88)
CSS-kod validerar inte på grund av att regler för specifika webbläsare
används. Det är en avvägning som har gjorts för att kunna använda CSS3regler på ett kompatibelt i det största antalet möjliga webbläsare.
5.4.1.2 Name, Role, Value (4.1.2)
Funktionsmenyn använder roller. (ARIA4)
För de komponenter som ”fäller ut” information: ”Alla e-legitimationer” och
hjälp-avsnittet används aria-expanded, aria-controlls och för hjälp-avsnittet att
de ligger i en definitionslista. (ARIA5)
26 (26)
