Modul 6, Tillgänglighetsauditering och upprättande av tillgänglighetsutlåtande

Modul 6

  • I tillgänglighetsauditeringen utvärderas hur tillgängliga tjänsterna är som helhet, mer omfattande än enskilda komponenter eller användningsstigar.
  • Auditeringen baserar sig på de krav som lagstiftningen ställer. Som verktyg används bland annat WCAG-riktlinjerna (Web Content Accessibility Guidelines).
  • Auditering i enlighet med tillgänglighetsmodellen ger ett uppdaterat tillgänglighetsutlåtande som uppfyller kraven i lagen.

Mall för tillgänglighetsutlåtande


Lagen förpliktigar Helsingfors stad att producera tillgängliga digitala tjänster

I Finland gäller Lagen om tillhandahållande av digitala tjänster (Finansministeriet, 1.4.2019), som baseras på EU:s tillgänglighetsdirektiv. Den förpliktigar myndigheter, såsom Helsingfors stad, att genomföra alla offentliga digitala tjänster (webbsidor, mobilapplikationer) på ett tillgängligt sätt. Lagen fastställer tillgänglighetens tekniska och visuella genomförande som kriterier, som tjänsten ska uppfylla. Dessa kriterier baseras på den internationella tillgänglighetsstandarden (WCAG, Web Content Accessibility Guidelines).

Web Content Accessibility Guidelines

WCAG-standarden sätter upp en grupp kriterier som används för att utvärdera tjänstens tillgänglighet. Kriterierna är konkreta krav huvudsakligen avseende det tekniska och visuella genomförandet, som ligger på nivån A, AA eller AAA i standarden. Lagen förutsätter att den offentliga sektorns tjänster ska uppfylla WCAG:s nivå AA, emellertid på så sätt att AA-kriteriet 1.2.4, ”Textbeskrivningar (direktsända)”, inte behöver uppfyllas.

I lagen finns även några krav som inte ingår i WCAG, såsom kravet på att tjänsten ska vara informationssäker och prestationsduglig. I praktiken testas tillgängligheten i tjänster som producerats av Helsingfors stad dock utifrån WCAG-standarden, eftersom tillgänglighetsutlåtandet som förutsätts i lagen baseras även på uppfyllandet av WCAG-kriterierna.

Tillgänglighetsauditering och upprättande av tillgänglighetsutlåtande

Varje tjänst som Helsingfors stad publicerar ska innehålla ett tillgänglighetsutlåtande som förutsätts enligt lagen (länk ovan). Utlåtandet är offentligt och det ges för kännedom till tjänstens användare. I utlåtandet beskriver man bland annat status för tjänstens tillgänglighet – eventuella brister och avvikelser i den samt information om åtgärdsplaner – samt erbjuder en kanal som användarna kan använda för att ge respons om tjänstens tillgänglighet. Närmare uppgifter om utlåtandets lagstadgade innehåll finns på webbplatsen för den ansvariga myndigheten, Regionförvaltningsverket (RFV) (www.tillganglighetskrav.fi).

I Helsingfors tillgänglighetsmodell innebär tillgänglighetsauditering en testning där man konstaterar och rapporterar hur tjänsten uppfyller kraven i WCAG-standarden. Utifrån auditeringen ska man kunna producera ett tillgänglighetsutlåtande för tjänsten. Auditeringsrapportens innehåll tas upp mer ingående senare i detta dokument.

Om auditeringen beställs från en extern leverantör, ska man i avtalet komma överens om vem som upprättar tillgänglighetsutlåtandet. Modellen rekommenderar att auditören producerar utlåtandet i samarbete med tjänstens ägare, vars sakkunskap om tjänstens bakgrund, begränsningar och vidareutvecklingsplaner är till hjälp när man utformar utlåtandet.

Länkar till Papunets kontrollista
https://papunet.net/saavutettavuus/pa-svenska/

Leverantören ska känna till metoderna. Det kan göras som ett eget arbete, om man har tillgång till personer som har bra kunskaper inom WCAG och hjälpmedel.

Beställning av tillgänglighetsauditering

Tillgänglighetsauditeringens leverantör ansvarar för valet av vilka verktyg och metoder som används vid testningen samt deras lämplighet för testning av överensstämmelse med WCAG. Beställaren behöver inte kunna specificera testningsprocessens expertarbetsdelar, om hen inte uttryckligen vill göra det.

Leverantören har således även ansvar för att skaffa nödvändiga uppgifter för att säkerställa omfattningen av tjänstens testning. Sådana uppgifter är till exempel vilka delar i tjänsten som kräver inloggning men som är öppna för offentligheten och om eventuella dokument, såsom PDF-dokument, på webbsidorna också ingår i auditeringen eller om de till exempel ingår i någon annan testningsprocess.

Närmare uppgifter om vilka dokument- och medieinnehåll samt organisationens internetsystem omfattas av tillgänglighetslagstiftningen finns på RFV:s webbsida (www.tillganglighetskrav.fi). Närmare uppgifter läggs också till i tillgänglighetsmodellens anvisningar under mars 2021.

Rapportering av tillgänglighetstestningens resultat

Som ett resultat av tillgänglighetsauditeringen levererar man en rapport till beställaren, där man berättar vilka delar av tjänsten som inte uppfyller WCAG-kriterierna.

Man behöver inte specificera varje enskild WCAG-överträdelse, om överträdelsen upprepar en redan rapporterad förekomst. Å andra sidan räcker det att rapporten innehåller information om i vilka delar av tjänsten WCAG-överträdelsen upprepas. En observerad brist kan till exempel gälla ett element som alltid upprepas på en viss sidbas, varvid man inte behöver räkna upp varje enskild sida där elementet förekommer, utan det räcker med informationen om att problemet upprepas överallt där elementet används i tjänsten.

Åtminstone följande WCAG-överträdelser som markerats som krav ska rapporteras: De uppgifter som markerats som rekommenderade behöver inte rapporteras.

  • Krav: Var överträdelsen förekommer i tjänsten. Rekommendation: Skärmdump som visar företeelsen i tjänsten bifogas till rapporten.
  • Krav: Vilken eller vilka WCAG-kriterier den observerade bristen är kopplad till.
  • Krav: WCAG-kriteriet klassificeras enligt inverkan. Parametern är hur betydande tillgänglighetsproblemets inverkan är på tjänstens användare. Syftet med kategoriseringen är att hjälpa tjänstens ägare att prioritera eventuella åtgärds- och vidareutvecklingsarbeten enligt hur tjänstens faktiska tillgänglighet förbättras effektivast. Kategorierna är: Kritisk, betydande och ringa.
    • Kritisk tillgänglighetsbrist: Problemet kan helt och hållet hindra en del av tjänstens användare att genomföra tjänstens funktioner. Till exempel om man inte kan öppna språkmenyn i sidans bannerdel med tangentbordsläsning, är bristen (WCAG 2.1.1) kritisk.
    • Betydande tillgänglighetsbrist: Problemet försämrar tjänstens användbarhet särskilt för grupper med särskilda behov, men hindrar den inte nödvändigtvis. Om tjänsten till exempel producerar ett tillkännagivande på sidan, som berättar att användaren har fått ett oläst meddelande och tillkännagivandet inte förmedlas till det tekniska hjälpmedlet som ett live-, status- eller alert-meddelande, men tillkännagivandet kan ändå hittas på sidan (WCAG 4.1.3), är det fråga om en betydande, men inte kritisk brist.
    • Ringa tillgänglighetsbrist: Problemet uppfyller inte WCAG-kriterierna och omfattas således av tillgänglighetslagen, men det har en mild inverkan på användbarheten. Om man till exempel behöver precisera eller förtydliga rubriker som används på webbplatsen, kan det vara en överträdelse mot kriteriet WCAG 2.4.6, vars inverkan är rätt så liten.
  • Krav: I rapporten ska man verbalt beskriva på vilka grunder den rapporterade bristen bryter mot WCAG-kriterierna. I praktiken ska läsaren av beskrivningen kunna förstå hur problemet förekommer och varför förekomsten inte uppfyller det anvisade kriteriet. Således räcker det inte enbart med en lista eller tabell (kriteriet uppfylls inte/uppfylls) över WCAG-överträdelserna.
  • Rekommendation: Rapporten bör även ge ett åtgärdsförslag för varje rapporterade tillgänglighetsbrist. För beställarens del kan åtgärdsförslag och -anvisningar vara ytterst användbara, i synnerhet om beställaren ännu inte har tillgång till en tillräcklig tillgänglighetskännedom som erbjuds utvecklarna.
  • Rekommendation: I uppdraget inkluderar man en genomgång av rapporten tillsammans med testningens beställare och leverantör. Under rapportverkstaden har beställaren möjlighet att fråga om och diskutera registrerade observationer och bland annat vilka åtgärdssätt som bäst passar för respektive situation.

Exempel: Rapportering av WCAG-överträdelser

I slutet av anvisningarna finns ett exempel på hur en enskild WCAG-brist kan rapporteras i enlighet med de uppsatta kraven ovan. Metoden som presenteras här är ett exempel och förbinder inte leverantören avseende strukturen eller mängden innehåll, men den kan fungera som ett rättesnöre för beställaren om vilken slags rapporteringsmetod man rimligen kan kräva.

Innan rapporteringen

Tillgänglighetsexperten testar webbtjänsten i skrivbordsvyn. Hen upptäcker att sidans navigeringsmeny inte alls kan inriktas med tabbtangenten i tangentbordsläsningen. När hen baserat på detta testar menyn med en skärmläsare, märker hen att man kan öppna menyn med hjälp av den, men att ingen information om menyns status förmedlas till hjälpmedlet och att innehållet i menyn följer knappen i läsordningen. Dessutom avviker menyknappens tillgängliga namn (”Valikko”) från knappens visuella text (”Menu”).

Testaren konstaterar att genomförandet av menyn vid första undersökningen bryter mot åtminstone följande WCAG-kriterier:

  • 2.1.1 Tangentbord
  • 2.4.3 Fokusordning
  • 2.5.3 Etikett i namnet
  • 4.1.2 Namn, roll, värde

Följande observationer görs direkt i testningsrapporten.

Skrivbordsvy/Webbplatsens huvudnavigeringsmeny: Menyknappen kan inte inriktas med tangentbordet (kritisk)

Objekt

Sidans upprepade bannerdel > knappen med texten ”Menu” som öppnar huvudnavigeringsmenyn.

Beskrivning

När användaren använder tjänsten med enbart ett tangentbord utan mus eller skärmläsare och förflyttar sig med tabbtangenten, kan navigeringsmenyknappen inte inriktas.

Effekt

Problemet är kritiskt, eftersom det hindrar personer som förlitar sig på tangentbordet eller hjälpmedel som använder sig av tangentbordsgränssnittet att öppna webbsidans navigeringsmeny, vilket i sin tur hindrar dem att använda tjänstens sökfunktion samt eventuellt även åtkomst till en del av sidans ämnessidor. Problemet gäller inte skärmläsare, eftersom de, liksom musen, producerar en onclick-händelse för knappen.

WCAG

2.1.1 Tangentbord (A)

Åtgärdsförslag

  • Ställ in ett tabindex=”0”-attribut för menyknappen, vilket gör att <span>-elementet kan inriktas med tangentbordet.
  • Samtidigt säkerställer man (eftersom detta inte kunde konstateras under testningen) att knappen har en behandlare för tangentbordshändelser, som utför öppnandet av menyn när användaren trycker på Enter (keyCode 13) eller mellanslag (keyCode 32). Man säkerställer även att ett tryck på mellanslaget vid knappen inte aktiverar läsarens standardfunktion, som rullar sidan nedåt (event.preventDefault()).
  • Man kontrollerar att menyknappen anvisar tangentbordsinriktningen antingen med systemets standardindikator eller, om indikatorn är skräddarsydd i sidans format, på ett sätt som syns i CSS :focus-status (t.ex. outline –property). Den skräddarsydda ramindikatorn ska producera färgkontrasten 3:1 med webbsidans bakgrund. Om indikatorn endast är en ändring av knappens bakgrundsfärg, ska färgskillnaden ha en kontrast på 3:1.

Skrivbordsvy/Webbplatsens huvudnavigeringsmeny: Den öppnade menyn har en ologisk placering i sidans läsordning (betydande)

Objekt

Sidans upprepade bannerdel > huvudnavigeringsmenyn, som är öppen > menypanelen.

Beskrivning

Innehållet i den öppnade menyn (menypanelen) är placerad i sidans läsordning först efter bannerdelen och följer inte direkt efter menyknappen när användaren går framåt på sidan. Istället efterföljs knappen omedelbart av språkmenyn (som är på höger sida om knappen i bannern). I DOM placeras navigeringsmenyn först efter språkmenyn, utanför bannerdelen. Orsaken till problemet är att tekniska hjälpmedel och tangentbordsläsningen följer sidans DOM-ordning och inte dess visuella layout (CSS-inställningar), och detta har man kanske inte kunnat beakta i genomförandet av menyn.

Effekt

Problemet försvårar märkbart användningen av tjänsten för personer som förlitar sig på en styranordning som fungerar med tangentbordet eller en skärmläsare. Utan en kontext baserad på synen kan användaren till och med tro att menyn inte kan öppnas alls eller att språkmenyn ligger inuti den, vilket avviker från sidans verkliga struktur. Å andra sidan kan man hitta menyn på sidan direkt efter bannern, så användningen av den hindras inte helt och hållet.

WCAG

  • 2.4.3 Fokusordning (A)

Åtgärdsförslag

Menypanelen ska placeras i DOM-ordningen direkt efter knappen, när menyn är öppnad. Exempelvis följande strukturella ändring borde åtgärda problemet:

Menyknappen stängd:

<nav class=”navigation-region”>
<span id=”navigation-menu-button” …>Manu<img ..></span>
</nav> 

Menyknappen öppnad:

<nav class=”navigation-region”>
<span id=”navigation-menu-button” …>Manu<img ..></span>
<div class=”navigation-menu-panel”>
<ul><li><a …>… <li>…</ul>
</div>
</nav>

Med andra ord skapar man en gemensam förälder för menyknappen och -panelen i vars DOM båda placeras, emellertid på så sätt att menypanelen inte är knappens barntagg utan är på samma DOM-nivå som knappen (element sibling). Så blir läsordningen automatiskt rätt och inget innehåll utanför menyn kan kila in mellan dem och på så sätt röra om i ordningen. Samtidigt får navigeringsområdet också ett eget landmärke (nav-tagg, som motsvarar rollen role=”navigation”) och ingen av elementen läcker av misstag ut utanför landmärket.

Resten av de ovan beskrivna bristerna (avsaknad av attributet aria-expanded samt etikett i namnet) rapporteras på motsvarande sätt.


Ursprunglig version: Tero Pesonen
Skapad: 4.3.2021