Det går inte att missa att vi rör oss allt närmre EN 301549/WCAG deadlinen den 28 juni. För att ha det lite kort så innebär det att alla som har användare (webb, app etc.) blir direkt påverkade och behöver göra justeringar för att möta dessa krav för att inte falla för böter. Vilka böter? Det vet vi inte och vi vet inte heller hur snabbt det kommer att gå… men det gör det inte mindre till en lag för den delen. Vi kan göra antaganden och gissa att det kan lika liknande lagar där det kommer varningar och påminnelser och när dessa inte möts så är det då böter kommer fram – men det är ingen garanti.
Vad jag vill gå igenom här är vilka delar av EN 301549/WCAG som direkt kommer att påverka både stora företag men särskilt små byråer som skapar hemsidor till flera olika klienter. Det skapar både ett problem men såklart även en stor möjlighet om det görs korrekt.
Jag tänker att jag ska gå igenom alla de olika delarna och försöka ge min tolkning och applicera den på agency världen.
Varje punkt från WCAG förklarad
Man kan lätt gå helt vilse i vad som behövs göras när man börjar läsa igenom EN 301549 eller WCAG. Är man på ett större företag där sidan/appen man har redan har en bestämd kodbas och då har man kanske flertalet utvecklare som kan göra de nödvändiga ändringarna. Men om man inte har det? Om man är ett mindre företag som kanske har flera 100 sidor under sig, i alla möjliga storlekar. Då har man genast ett problem. Alla dessa sidor måste följa de nya lagarna/reglerna för att inte få böter.
Där jag jobbar nu så har jag haft möjligheten att jobba med tillgänglighet i flera sprints och fört talan för vårt team. Men jag är väl medveten om hur agency världen kan fungera så jag tänker att jag går igenom punkt för punkt vad varje del kan innebära för den typen av företag.
Denna listan baseras helt på WCAG. Så när det kommer till EN301549 så hittar vi ett par saker till som är otroligt viktiga och det är att en hemsida behöver respektera webbläsarens inställningar… alltså hemsidan ska gå att ha igång dark mode och andra flera andra inställningar. Jag tycker att DIGG.SE artikeln förklarar det bättre än vad jag kan göra.
Här är listan över allting och en liten förklaring för att förankra den i situationer som du förhoppningsvis redan har träffat på. Tänk på att allting här är er lite av en tolkningsfråga så se över beskrivningen mer än på ”Tänk på” – då det endast är hur jag ser på regeln. Det kommer även blandas mellan nivå A och AA – men det spelar ingen roll då båda ska mötas. Du kan fälla ut de olika punkterna nedanför.
1. Preceviable
| Namn | Beskriving | Tänk på |
|---|---|---|
| 1.1.1 Non-text Content | All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below. | Detta är framförallt relaterat till alt texter på allt från bilder till ikoner etc. |
| 1.2.1 Audio-only and Video-only (Prerecorded) Level A | For prerecorded audio-only and prerecorded video-only media, the following are true, except when the audio or video is a media alternative for text and is clearly labeled as such: Prerecorded Audio-only: An alternative for time-based media is provided that presents equivalent information for prerecorded audio-only content. Prerecorded Video-only: Either an alternative for time-based media or an audio track is provided that presents equivalent information for prerecorded video-only content. | Lägger ni upp videos till era kunder så kommer nig behöva ha någon form av beskrivning på vad den innehåller. Använder ni bakgrunds videos så är det lite annorlunda då den inte följer exakt detta men faller istället under 2.2.2 Pause, Stop, Hide där en användare ska ha möjligheten att pause, stoppa eller gömma videon. |
| 1.2.2 Captions (Prerecorded) | Captions are provided for all prerecorded audio content in synchronized media, except when the media is a media alternative for text and is clearly labeled as such. | Tydligt förklarat https://www.w3.org/WAI/WCAG21/Understanding/captions-prerecorded.html |
| 1.2.3 Audio Description or Media Alternative (Prerecorded) och 1.2.5 Audio Description (Prerecorded) | An alternative for time-based media or audio description of the prerecorded video content is provided for synchronized media, except when the media is a media alternative for text and is clearly labeled as such. | Värt att tänka på här är att Captions och Audio descriptions är inte detsamma – även om det kan låta som det. Skapar ni videos åt era klienter så blir detta en del att ta med i diskussionen om pris och tidsram. Är det videos som ni beställer in så är det fortfarande ni som antingen gör det eller sätter press på leverantören. |
| 1.3.1 Info and Relationships | Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. | Använder ni WordPress med ett robust tema så är en del av detta redan inbyggt. Men handlar mycket om att ha kontroll och översikt över hur det används. Se till att använda den HTML kod som ger en tydlig struktur och lättläst för alla. |
| 1.3.2 Meaningful Sequence | When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined. | Se till så att allting följs logiskt både i kod och visuellt. Undvik att göra speciallösningar med CSS där något kan bryta det förväntade mönstret. Jag vet att en del använder WordPress teman med layout byggare (Divi, Elementor etc) där man har tillgång till koden men kanske inte har kunskapen att göra ändringarna i koden utan använder CSS för att göra vissa lösningar. |
| 1.3.3 Sensory Characteristics | Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, color, size, visual location, orientation, or sound. | Detta handlar i stor utsträckning om att när vi beskriver något på knappar eller något som ska göra att då inte göra det i relation till något specifikt som färg (eller de andra listade). Så alltså skriv inte ”klicka på den gröna knappen nere i höger för att gå vidare”. Se över hur ni skriver er UX copy så tidigt som möjligt och se till att utbilda eller utbilda varandra. |
| 1.3.4 Orientation | Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential. | Se till så att det går att använda hemsidan i alla lägen. Använder ni WordPress och någon hemsida byggare så kommer ni med stor sannolik att redan vara täckta. Se bara till att kolla av så att det kommer att fungera korrekt och inget blir låst. Vill påminna om att det inte handlar om att vara perfekt i några av dessa punkter utan bara ge en så bra upplevelse som möjligt. Så det kanske inte ser super snyggt ut men det handlar mer om att göra det tillgängligt för alla. |
| 1.3.5 Identify Input Purpose | The purpose of each input field collecting information about the user can be programmatically determined. | Mer programmerings relaterat. Där allting ska vara tydligt med inputs så att det blir tydligt genom alla möjliga tillgänglighets verktyg. Viktigt här är att det tema eller den byggaren ni använder följer dessa regler. Problemet är att existerar företaget utanför EU så behöver de inte tänka på det men helt klart något de borde göra – i slutändan är det fortfarande ni som bär ansvaret och inte tredje-part. Använder ni plugins så så ska det såklart även också ses över. |
| 1.4.4 Resize Text | Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality. | Har ni tur så kommer ni runt detta med det valda temat eller byggaren ni använder. Igen det handlar inte om att vara perfekt eller snyggt – det ska vara fungerade och användbart för alla. Har ni redan responsivt så är ni till större delen täckta men gör det till en del av er checklista. |
| 1.4.5 Images of Text | If the technologies being used can achieve the visual presentation, text is used to convey information rather than images of text. | Undvik att använda text på bilder. Det är inte mycket svårare än så. Om det är något ni gör idag så tänk om hur ni gör det och ändra det. Undantaget är logotyp, eller om det finns en tydlig alt text eller beskrivning i nära relation. |
| 1.4.10 Reflow | Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions. | Med tema eller byggare så är ni högst troligt redan täcka här – det handlar till större delen av att sidan ska vara responsiv och spelar in i tidigare punkter i samma 1.4.x. Men lägg till det i en checklista och kolla av det för varje sida. Jag har sett tillfällen där content eller CSS har gjort så att något inte fungerar korrekt. |
| 1.4.11 Non-text Contrast | The visual presentation of the following have a contrast ratio of at least 3:1 against adjacent color(s). | Tydlig regel. Allt som inte inte är text ska ha en kontrast ratio av 3:1. Har ni en knapp eller knapps outline så ska den ha korrekt ratio. Det finns flera olika verktyg till webbläsare eller plugins där det går att enkelt kolla vilken ratio som två färger har. Tänk bara på att det finns flera olika ratios att tänka på. |
| 1.4.12 Text Spacing | In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property: – Line height (line spacing) to at least 1.5 times the font size; – Spacing following paragraphs to at least 2 times the font size; – Letter spacing (tracking) to at least 0.12 times the font size; – Word spacing to at least 0.16 times the font size. | Mer tekniskt som behövas ha koll på och här specificeras det tydligt. Se bara till så att det går att ändra och att layout/hemsida fortfarande fungerar som tänkt. |
| 1.4.13 Content on Hover or Focus | Where receiving and then removing pointer hover or keyboard focus triggers additional content to become visible and then hidden. Dismissible: A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus, unless the additional content communicates an input error or does not obscure or replace other content; Hoverable: If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing; Persistent: The additional content remains visible until the hover or focus trigger is removed, the user dismisses it, or its information is no longer valid. | Ytterligare en tydlig regel denna gången i relation till hover content. Få in en rutin för det och lägg det i era checklistor när ni kollar av era hemsidor. |
2. Operable
| Namn | Beskriving | Tänk på |
|---|---|---|
| 2.4.1 Bypass Blocks | A mechanism is available to bypass blocks of content that are repeated on multiple Web pages. | Detta är en sätt för användare att t.ex skippa en lång meny och så att det kan hoppa direkt till content. https://www.starbucks.com/ gör detta bra och synligt. Trycker du på tab på ditt tangentbord så kommer det fram ett meddelande som låter dig hoppa ner till content på sidan. |
| 2.4.2 Page Titled | Web pages have titles that describe topic or purpose. | Har ni en SEO tjänst på plats så har ni redan detta iordning men jag vet också att det har sålts hemsidor med enklare SEO som kan inte direkt alltid täcker detta. Så se över eran process för hur detta ser ut för er. |
| 2.4.3 Focus Order | If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability. | När man använder t.ex tab så ska det vara tydligt hur man hoppar runt på sidan. Du ska inte helt plötsligen fastna längst ner på sidan, över till en side bar, till mitten av sidan. Utan det ska logiskt följa flödet av sidan. |
| 2.4.4 Link Purpose (In Context) | The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general. | En länk ska vara tydlig i sitt utförande. Alltså en knapp där det står ”Stäng” är otydlig för att det är inte tydligt nog vad som stängs. Stänger jag sidan? Stänger jag den sektionen? Var helt enkelt tydlig när ni skriver UX copy. |
| 2.4.5 Multiple Ways | More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process. | Har hemsidan endast en navigation för att röra sig till alla sidor? Då behöver det uppdateras. Det krävs minst två för att möta detta kravet. Alla användare ska kunna nå content på hemsidan. De vanligaste är navigations meny, sökfält, site map, footer länkar eller liknande. |
| 2.4.6 Headings and Labels | Headings and labels describe topic or purpose. | Tydligt förklarat https://www.w3.org/WAI/WCAG21/Understanding/headings-and-labels.html |
| 2.4.7 Focus Visible | Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. | Använda :focus för att skapa en korrekt indikation. Det kan vara att det tema eller byggare ni använder inte har detta. Försök hitta ett plugin eller bygg ut det själva. |
| 2.5.1 Pointer Gestures | All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential. | Ofta kan det finnas sliders som har en swipe funktion eller en zoom funktion. Dessa behöver ha enklare alternativ där det istället t.ex går att klicka till nästa bild eller zooma in/ut med en knapp. |
| 2.5.2 Pointer Cancellation | For functionality that can be operated using a single pointer | En användare ska kunna avsluta den action de är på väg att göra innan det godkänns. Ett tydligt exempel är när man klickar på en knapp så ska det inte gå igenom tills användaren släpper klicket – samtidigt som att om användaren flyttar iväg från knappen så går det inte igenom. |
| 2.5.3 Label in Name | For user interface components with labels that include text or images of text, the name contains the text that is presented visually. | Se till så att t.ex lables eller knappar har samma tillgänglighets text (det som skärmläsare och taligenkänning mjukvara använder) som den visuella. |
| 2.5.4 Motion Actuation | Functionality that can be operated by device motion or user motion can also be operated by user interface components and responding to the motion can be disabled to prevent accidental actuation | Om du väljer att lägga till en funktion som gör att om man skakar sin telefon så laddas det inte information så behöver du även ha en knapp som gör samma sak. Alternativt ett sätt att stänga av den typen av funktion i inställningar. |
| 2.5.7 Dragging Movements | All functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging, unless dragging is essential or the functionality is determined by the user agent and not modified by the author. | Om in använder funktioner som kräver att man drar något (slider, slide to unlock etc.) så ska det även finnas ett sätt att göra det på med knappar eller tangentbords genvägar. |
| 2.5.8 Target Size (Minimum) | The size of the target for pointer inputs is at least 24 by 24 CSS pixels. | Ytan där du behöver klicka på ska minst vara 24×24. För knappar är det enklast att inte ha knappar som är mindre än 24×24. För ikoner kan det kanske vara lite konstigt men tänkt in på att den klickbara ikonen ska vara 24×24 utan utan där du kan klicka på ikonen ska vara 24×24. Här hade det varit bättre att skapa en ikon knapp eller alternativt ökat den klickbara ytan. |
3. Understandable
| Namn | Beskriving | Tänk på |
|---|---|---|
| 3.1.1 Language of Page | The default human language of each Web page can be programmatically determined. | Se till att ni koden har satt in för rätt språk för hemsidan. Använder ni WordPress så är det en inställning som sker automatiskt när ni sätter upp sidan med rätt språk. Gillar ert team att arbeta med en engelsk version av en byggare så se till att göra det möjligt att ha den på engelska men sidan på svenska eller gå helt över till att använda det på svenska. |
| 3.1.2 Language of Parts | The human language of each passage or phrase in the content can be programmatically determined except for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text. | Detta är mest för hemsidor som har flera språk och att då se till så att alla lang taggar fungerar korrekt. |
| 3.2.1 On Focus | When any user interface component receives focus, it does not initiate a change of context. | När en användare använder tangentbordet för att sätta något i fokus så ska inget förändras. Ingen sida ska oväntat uppdateras eller liknande. |
| 3.2.2 On Input | Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component. | När användaren gör någon form av input att då inte oväntat uppdatera sidan eller likanande. |
| 3.2.3 Consistent Navigation | Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user. | Se till så att navigationen inte plötsligt förändras från sida till sida. |
| 3.2.4 Consistent Identification | Components that have the same functionality within a set of Web pages are identified consistently. | Se till så att liknande/samma komponenter på hemsidan inte har olika funktioner. En knapp som säger ”Lägg till” och har en specifik styling ska inte på en annan sida ha en annan stil eller funktion. |
| 3.2.6 Consistent Help | If a Web page contains any of the following help mechanisms, and those mechanisms are repeated on multiple Web pages within a set of Web pages, they occur in the same order relative to other page content, unless a change is initiated by the user. | Om du t.ex har en chattbot så ska den finnas på samma plats över de sidor den berör. |
| 3.3.1 Error Identification | If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text. | Se till så att alla felmeddelanden är tydliga, lätta att förstå och att det är tillgängligt för alla. Använd t.ex ARIA attribut för att göra det tydligt. |
| 3.3.2 Labels or Instructions | Labels or instructions are provided when content requires user input. | Se till att labels på input fält är tydliga och lätta att förstå. Det ska tydligt beskriva ändamålet för fältet och vara programmerat så. Lägg till instruktioner om det behövs som placeras nära det relaterade fältet. |
| 3.3.3 Error Suggestion | If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content. | Se till så att alla fel är tydliga och ge tydliga förslag till hur användaren ska åtgärda för att gå vidare. |
| 3.3.4 Error Prevention (Legal, Financial, Data) | For Web pages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test response | Denna regel är till för när användaren ska skicka in personlig data, laglig överenskommelser eller t.ex i checkout flödet där det är finansiell del. Det viktiga är att ge användaren en chans att se över vad de hade tänkt att skicka in så att de bekräftar. |
| 3.3.7 Redundant Entry | Information previously entered by or provided to the user that is required to be entered again in the same process | Tydligt förklarat https://www.w3.org/WAI/WCAG22/Understanding/redundant-entry.html |
| 3.3.8 Accessible Authentication (Minimum) | A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process | Se till så att användaren inte endast kan använda kognitiva tester (CAPTCHA, pussel, identifiera mönster etc.) för authentication. Det ska vara tydligt att det går att använda t.ex finger avtryck, ansiktsigenkänning, email, SMS kod eller liknande. |
4. Robust
| Namn | Beskrivning | Tänk på |
|---|---|---|
| 4.1.2 Name, Role, Value | For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies. | Alla dessa ska vara tydliga och användbara för alla oavsett vilken teknik som används. Se till att element har korrekta lables/namn, roles (button, checkbox etc.) och values (checked/unchecked etc.) |
| 4.1.3 Status Messages | In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus. | Ge status meddelanden och felmeddelanden som är tydliga i kod som gör det enkelt att förstå med assistive technology. Använd t.ex ARIA live regions som är polite eller assertive. |
Olika typer av lösningar
Låt oss säga att ni är en mindre/medel/stor agency med flertalet hemsidor, olika stilar, komponenter, antal sidor etc. då kommer varje sida behöva uppdateras och följa dessa regler. WCAG gör ingen som helst skillnad på om det är en stor hemsida eller liten hemsida – alla hemsidor ska uppfylla A och AA nivån i WCAG.
Rent lagligt så kan ni säkert komma runt det genom att det är upp till ägaren av hemsidan och att ni lägger ägandet på era kunder – kanske har ni något i era kontrakt som gör att det är upp till kunden att köpa till tjänsten och att ni endast behöver informera (även om det i senaste laget nu). Oavsett så kommer ni antingen ha problemet nu direkt eller för alla kommande sidor.
Så vad kan ni göra?
Skapa komponenter
Templates är fantastiskt när ni har en hemsida att tänka på men mindre kreativt när ni har flertalet olika hemsidor där ni vill att alla ska ha sin egna design, sin egna inställningar och ibland även sin egna kod ibland. Era klienter får snygga hemsidor och de kan stå ut från mängden (för jag antar att det är en av de sälj punkter ni trycker på – om inte priset eller eran personliga service) när de väljer just er.
Vad som kan hjälpa er här blir komponenter. Dessa komponenter kan ni konstant justera från en fundamental princip – i detta fallet tillgänglighet – men hade lika väl varit UX relaterat. Hur ni exakt löser det i den uppsättning ni använder är lite mer upp till er. Sedan kan en designer gå in och använda denna komponent med olika färger och inställningar (för att göra den mer unik) men i slut ändan lutar den alltid tillbaka till den grund komponent som styr det fundamentala.
Som ett exempel så kan ni skapa en knapp komponent som har en specifik storlek, det ger den en satt bred/höjd och hur den fungerar med :focus. Den saknar färg, border etc. men det är där ni själva kommer in med den design som hemsidan kräver. Upptäcker ni sedan att alla knappar behöver ha en inställning för ikon, då lägger ni till det i grund inställningarna i biblioteket för era komponenter.
Allt detta importeras då in i det tema ni använder eller byggare så att det går att använda dessa byggklossar i alla lägen. Ni behåller kreativiteten och övertid så kan ni bygga ut era komponenter så att det täcker mer än bara basics. Starta en mindre task force på 1-2 personer som har huvudfokus på att utveckla dessa. Ni kommer konstant upptäcka där det behövs nya i era olika projekt. Men försök undvika att göra det i det första projektet där det dyker upp. Går det att göra med en annan komponent? Går det att modifiera den med nya inställningar istället för att skapa en ny? Utvärdera och om det verkligen behövs först då skapas en komponent.
Detta leder oss till reviews.
Ha ett review system på plats
Om ni inte redan har ett system för reviews så börja med att införa det. Men första vad är ett review system? Det är vanligt när det kommer till kodning att man har någon som ser över den kod man skapar innan man mergar den in till kodbasen. Såklart kan man göra det samma med design. Efter att någon i ditt team är klara med en design så kan man ge en task till en annan designer att se över det som är gjort. Sätt upp en checklista över vad som behöver ses över innan det godkänns. Det är inte endast WCAG utan är särskilda design tekniker eller hur sidan ser ut i helhet.
Det kan känns som att någon annan ska se över vad du gör men det ger alla designers ett lyft. Det säkerställer så att alla sidor följer samma mål och designkvalité. Det är även skönt att veta att nu har varit två personer som har lagt ett öga på hemsidan. Det gör att om något missas så är det något som två personer har missat.
Nya tjänster att sälja
Detta täcker inte bara hemsidor utan allting där en användare kan komma att interagera med. Så det finns e-mails, PDF:er etc. som även de behöver ha samma robusta grund. Det kan låta som jobb men se det som en möjlighet att sälja nya tjänster. Är det värt för en restaurang att skapa en tillgänglighets anpassad PDF för deras meny? Ska de inte använda hemsida istället som är lätta att uppdatera? Alternativt så hittar ni en lösning för PDF:er och då har ni ytterligare en tjänst att sälja.
Såklart finns det hemsidor som inte alls har tänkt på tillgänglighet – de kanske inte vet om att lagen snart går igenom. Kan ni säkerställa att ni har tillgänglighet under kontroll så kan ni direkt ta en bit av marknaden.