Hvad der fører til sagsanlæg: En praktisk guide til de brugergrænseflademønstre, der ligger bag 6.666 klager over manglende tilgængelighed

Hovedet er det første interaktive område på hver side, og hamburger-knappen er ofte det første, en tastaturbruger kommer til. Når den knap vises som en <div> hvis et element har et CSS-baggrundsbillede, mangler et tilgængeligt navn eller udvider et menu, der låser fokus eller ikke angiver, om det er åbent eller lukket, bliver hele webstedet strukturelt umuligt at betjene med tastaturet, før brugeren overhovedet har nået at komme i kontakt med det egentlige indhold.

Spring-linket er den tilhørende fejl. Et fungerende "Skip to main content" Linket er en løsning på blot fem linjer, men det er også den absolut mest effektive måde at afgøre, om et udviklerteam overhovedet har tilgængelighed på sin tjekliste. I klager nævnes de to ting ofte i samme afsnit, fordi et manglende eller defekt springlink fungerer som en slags varselslampe – hvis teamet ikke har implementeret et springlink, har de næsten helt sikkert heller ikke implementeret »aria-expanded«-tilstande.

Gengiv menutriggeren som en reel <button> med en tekstetiket, der er synlig eller kun kan læses af en skærmlæser, og en administreret aria-expanded attribut. Angiv et "Skip to main content" et link, der bliver synligt, når der fokuseres på det, og som fører til <main> markør. Sørg for, at fokus flyttes til menuen, når den åbnes, og tilbage til udløseren, når den lukkes, og at Esc lukker menuen.

Søgefunktionen er på de fleste store hjemmesider implementeret som en brugerdefineret komponent — et tekstfelt med debounce, der sender en forespørgsel ved hvert tastetryk og viser en flydende liste med forslag inden for et absolut-positioneret <div>. Selve tekstindtastningen fungerer som regel fint. Forslagslisten gør det næsten aldrig. Den vises uden for indtastningsfeltets DOM-kontekst og har ingen role="listbox", nej aria-activedescendant, og der vises ingen meddelelse i live-området, når resultaterne vises. En bruger af en skærmlæser skriver, hører intet, trykker på Enter og får en resultatside frem, som vedkommende ikke vidste ventede.

Det samme arkitekturmønster går igen i filterpanelerne til facetteret søgning og i selve resultatlisten: elementer, der kan få tastaturfokus, og som er synlige, men aldrig oplæses. Klager over søgefunktionen handler sjældent om selve søgefeltet; de handler om alt det, der vises, efter at brugeren har indtastet noget.

Brug det etablerede WAI-ARIA-mønster for kombinationsfelter: role="combobox" på indgangen med aria-expanded, aria-controls, og aria-activedescendant forbundet til en role="listbox" forslag. Tilføj et interaktivt område, der viser antallet af resultater. Sørg for, at man kan navigere til listen med forslag ved hjælp af pil-ned-tasten, ikke kun med musen.

PLP-gitteret samler flere anti-mønstre på én skærm. Hver flise er typisk et klikbart kort med tre eller fire interaktive underelementer – billedlink, titellink, farveprøver, knap til hurtig tilføjelse – indrammet af endnu et link til produktsiden. Resultatet er indlejrede interaktive elementer (en HTML-fejl), overflødig linktekst („Hero Dash Three Graphic Image Link“, der gentages fire gange) og farveprøver opbygget af <div> elementer med klikhåndteringer, men uden rolle og uden navn.

Filtersiden i sidepanelet introducerer en ny fejltype. Filterfacetter er normalt lister med afkrydsningsfelter, men er opbygget af brugerdefinerede div- og span-elementer, der er formateret, så de ligner afkrydsningsfelter, hvor det egentlige <input> skjult uden for skærmen. Når denne skjulte indtastning mister sin tilknytning — enten via en CSS-regel, en JavaScript-hændelseshandler, der opfanger tryk på mellemrumstasten, eller en manglende for attribut på den synlige etiket — filteret kan nu kun betjenes med musen.

Brug ét anker pr. flise med beskrivende tekst, ikke tre links pr. produkt. Vis farveprøverne, som de ser ud i virkeligheden <button> elementer inden for en role="radiogroup". Opret filterfacetter på basis af faktiske <input type="checkbox"> elementer med tilknyttede <label> tags; Formater indtastningsfelterne visuelt i stedet for at skjule dem. Vis ændringer i filteret med en diskret live-markering.

På produktdetaljesiden skal en bruger af en skærmlæser træffe flere specifikke valg i den rigtige rækkefølge: vælge en farve, vælge en størrelse, angive antal og derefter lægge varen i kurven. Hvert af disse valg er i moderne e-handel implementeret som en brugerdefineret widget – typisk en vandret række af <button>-formet <div>Hvad angår størrelser, farvefelter opbygget af div-elementer med CSS-formatering og en numerisk skyder bestående af to ikonknapper, der flankerer et indtastningsfelt. Knapperne til at øge og mindske leveres som regel uden et tilgængeligt navn; i klagerne beskrives de som annonceret som »knap, knap« uden nogen angivelse af, hvad de laver.

Størrelsesvejledninger og størrelsestabeller udgør et særskilt problem: De findes næsten altid bag et link med teksten »Størrelsestabel«, der åbner et pop op-vindue, og selve linket har ofte ingen tekst, pop op-vinduet har ofte ingen angivet titel, og tabellen indeni har ofte ingen række- eller kolonneoverskrifter.

Brug rigtige formularfelter. Farveprøver og størrelsesvælgere bør være en role="radiogroup" af role="radio" knapper (eller egentlige radioknapper, der er udformet usynligt), hver med et tilgængeligt navn som f.eks. »Størrelse: Medium«. Antalsregulatoren skal være et nummerfelt med etiketter samt tilhørende knapper til at øge og mindske, hvis tilgængelige navne indeholder handlingen og det aktuelle antal. Indsæt hele det valgte område i et fieldset med en billedtekst.

»Læg i kurv« er det mest gennemtestede trin i enhver e-handels-konverteringsproces og et af de trin, der oftest ikke fungerer for brugere af hjælpemidler. Forløbet er mekanisk: En besøgende trykker på knappen, en lille bekræftelsesboble eller en mini-kurv-skuffe vises i to eller tre sekunder, og kurvikonet opdaterer et tal i overskriften. Seende brugere ser alle tre signaler. Brugere af skærmlæsere modtager typisk ingen. Meddelelsen vises uden for det aktive område, skuffen vises uden fokusstyring, og ændringen i indkøbskurvens antal leveres som en almindelig DOM-ændring, som ingen skærmlæser vil annoncere.

Resultatet er en knap, der set fra brugerens synspunkt ikke gør noget. De trykker på den, hører intet, antager, at den ikke virkede, og trykker på den igen. I nogle klager beskrives det, at man trykkede på knappen fem eller seks gange, før man opdagede, at indkøbskurven i al stilhed havde samlet fem eller seks varer.

Indsæt følgende kode omkring området med vognstatus aria-live="polite" og opdatere teksten ved hver vellykket tilføjelse. Hvis designet bruger en bekræftelsesmenu, skal fokus flyttes til menuen, når den åbnes, og tilbage til den oprindelige knap, når den lukkes. Opdater antallet i indkøbskurven med en meddelelse, der kun er beregnet til skærmlæsere, f.eks. »1 vare tilføjet. I alt i indkøbskurven: 3 varer.«

Kontrolelementer, der udelukkende består af ikoner, fejler på en forudsigelig måde: det synlige indhold er en SVG-fil eller en tegn fra en ikonfont, det tilgængelige indhold er tomt, og skærmlæserens oplæsning reduceres til elementets strukturelle rolle uden navn. Indkøbskurv-ikonet ender med at blive annonceret som "link" eller "sammenklappet"; chatboblen som "knap"; rækken af sociale ikoner i sidefoden som "link, link, link, link, link". Brugeren har ingen mulighed for at vide, hvad nogen af dem gør.

Indkøbskurv-ikoner fejler oftere end andre ikoner af en arkitektonisk årsag: I mange implementeringer vises antallet i indkøbskurven inde i ikonets tilgængelige navn (f.eks. viser ikonet »0« inde i SVG-filen), og skærmlæserprogrammet opfanger kun tallet. Der er klager over, at indkøbskurv-ikonet oplæses som »3, link« eller »0, link«, uden at det fremgår, at »3« henviser til antallet af varer i indkøbskurven.

Hvert kontrolelement, der kun består af et ikon, skal have et tilgængeligt navn. Tilføj et aria-label på knappen eller indsæt en tekstetiket, der ikke kan ses, indeni den: "Shopping cart, 3 items". Undgå at indsætte talsifre i ikonets tilgængelige navn uden sammenhæng. Ved dekorative ikoner, der vises ved siden af synlig tekst, skal du bruge aria-hidden="true" tryk på ikonet, og lad teksten fungere som etiketten.

Kassen indebærer en større risiko for manglende overholdelse pr. pixel end nogen anden side på en e-handelsside, og der er mange fejl. Adresselister, der vises som brugerdefinerede <div> komponenter, der ignorerer mellemrumstasten. Markeringer for obligatoriske felter vises kun som en rød stjerne, uden aria-required og ingen programmatisk sammenhæng. Indbyggede fejlmeddelelser vises med rød tekst under feltet, uden aria-describedby Der er ingen sammenkædning mellem feltet og fejlmeddelelsen, og der vises ingen meddelelse i det aktive område, når valideringen mislykkes. Brugeren udfylder formularen, trykker på »Fortsæt«, bliver uden varsel sendt tilbage og har ingen mulighed for at vide, hvilke felter der gav fejl, eller hvorfor.

De samme klager går igen i hundredvis af sager: fejlmeddelelser vises ikke, fejlmeddelelser er vage, det er ikke muligt at indtaste betalingsoplysninger. Dette er ikke enkeltstående fejl. Det er standardadfærden hos de fleste betalingsmoduler, der leveres uden eksplicit tilgængelighedsoptimering.

Brug ægte <label> elementer, der er knyttet til indtastninger via for/id. Markér de obligatoriske felter med aria-required="true" og angiv kravet med synlig tekst, ikke kun med farve. Hvis valideringen mislykkes, skal fejlmeddelelsen vises inden for indtastningsfeltets aria-describedby mål, angiv det felt, der ikke opfylder kravene aria-invalid="true", og flyt tastaturfokus til det første felt med fejl. Vis et oversigtsområde øverst i formularen med ankerlinks til hvert felt med fejl.

Betalingsblokken er usædvanlig, fordi den ofte leveres via en indlejret iframe fra en tredjepart – Stripe Elements, Braintree Hosted Fields eller en Adyen-drop-in. Inde i iframen er betalingsudbyderens egen formular som regel tydeligt mærket. Men i det øjeblik et websted opretter sin egen kortindlæsning eller indkapsler de indlejrede felter i et brugerdefineret layout, der overskriver etiketterne med visuelle pladsholdere, bliver de fire felter – nummer, udløbsdato, CVV, postnummer – til en række tomme indtastningsfelter for en skærmlæser.

Feltet til CVV-koden er det felt, der oftest er forkert mærket, fordi designere ofte erstatter feltets etiket med et spørgsmålstegn, der åbner en værktøjstip, der forklarer, hvad en CVV-kode er. Værktøjstipet er ikke selve etiketten; feltet skal stadig have et programmatisk navn. Hvis det ikke har et, læser skærmlæserprogrammet hele betalingsblokken op som »rediger, rediger, rediger, rediger«, og transaktionen afbrydes.

Hvis du bruger en integration med tredjeparts-hostede felter, skal du følge leverandørens retningslinjer for tilgængelighed — de fleste tilbyder en dokumenteret metode til at mærke felter uden for iframe'en. Hvis du udvikler en brugerdefineret kortindlæsning, skal hvert indtastningsfelt have et reelt <label> element med en synlig tekstetiket samt autocomplete="cc-number" / cc-exp" / cc-csc" attributter, så adgangskodemanagere og hjælpemidler kan identificere felterne efter deres formål.

Indkøbskurvsiden gentager fejlen med mængdeindstilleren på produktdetaljesiden, men med større konsekvenser: En bruger af en skærmlæser, der ikke kan betjene indstilleren, kan ikke gennemføre bestillingen. Knappen »Fjern« er i sig selv et anti-mønster — den er som regel et lille ×-ikon ved siden af hver varelinje, ofte uden synlig tekst, ingen aria-label, og der kommer ingen meddelelse, når rækken fjernes. Brugeren trykker på det, man håber er sletteknappen, rækken forsvinder, og skærmlæseren siger intet. Der er ingen måde at bekræfte, at handlingen lykkedes.

Flere klager beskriver et lignende problem: Indkøbskurvens løbende total opdateres dynamisk, når mængderne ændres, eller varer fjernes, men den nye total vises som almindelig DOM-tekst uden for et live-område, så brugeren ikke har nogen anelse om, hvad vedkommende kommer til at betale.

Hver linjepost skal indeholde en mærket sletteknap (f.eks. "Remove Blue T-Shirt, size M, from cart"). Mængdeindstillingsknapper bør angive deres aktuelle værdi som en del af det tilgængelige navn eller via tilhørende opdateringer af live-regioner. Indkøbskurvens delbeløb bør placeres inden for en aria-live="polite" området, så ændringerne bliver annonceret. Bekræft sletninger med en fortryd-funktion.

Dette er den største kategori i datasættet, fordi det er det billigste problem at opdage og det dyreste at ignorere. En skærmlæser gennemgår DOM-strukturen og støder på en <input>, og læser dets tilgængelige navn — som den beregner ud fra følgende i rækkefølge: aria-labelledby, aria-label, en tilknyttet <label for>, den title attribut eller pladsholderen. Hvis ingen af disse findes, læser skærmlæseren kun rollen op: »redigeringsfelt« eller »redigering, tomt«. Denne sætning går næsten ordret tilbage i hundredvis af klagesager.

Årsagen til, at det er så udbredt, er af strukturel karakter. Moderne designsystemer viser ofte en pladsholdertekst i indtastningsfeltet som erstatning for den synlige etiket, og udviklere antager, at pladsholderen fungerer som etiket. Det gør den ikke. Pladsholderen forsvinder, når brugeren begynder at skrive, efterlader ingen programmatisk betegnelse og gør feltet ubrugeligt for alle, der kommer til det senere i forløbet eller vender tilbage til det efter en fejl.

Hvert interaktivt kontrolelement får en synlig etiket, der tilknyttes programmatisk. <label for="email">Email</label><input id="email" type="email"> er det standardmønster. Pladsholdere er blot supplerende vejledning, ikke erstatninger. Ved kontrolelementer, hvor en synlig etiket reelt er uønsket (søgefelt, ikonknapper), skal du bruge aria-label med beskrivende tekst — aldrig med pladsholderen gentaget.

Udtrykket »ikke annonceret eller sat i fokus« forekommer ordret i over 400 klageindlæg og er en af de mest gentagne sætninger i hele datasættet. Det beskriver en specifik fejl: Et modalvindue eller en dialogboks vises på siden (ofte automatisk – tilmelding til nyhedsbrev, alderskontrol, bekræftelse af placering), det synlige indhold skifter, men skærmlæserens får intet signal om, at noget har ændret sig. Fokus forbliver på den underliggende side. Brugeren fortsætter med at bladre gennem det, der lå under modalvinduet, fuldstændig uvidende om, at der er dukket en blokerende dialogboks op.

Dette er et skoleeksempel på en modal, der fejler på alle fronter på én gang: nej role="dialog", nej aria-modal="true", ingen programmatisk fokusforskydning ved åbning, ingen fokusfælde, mens vinduet er åbent, ingen lukning ved tryk på Esc, ingen titelvisning. Da alle disse fejl optræder sammen, vil det ikke gøre nogen forskel at løse en enkelt af dem isoleret.

Brug et etableret dialogmønster (WAI-ARIA Authoring Practices-specifikationen er referencen). Ved åbning: Flyt fokus til det første element i dialogen, der kan få fokus, og indstil aria-modal="true" og role="dialog", navngiv dialogboksen aria-labelledby peger på overskriften. Mens vinduet er åbent: Hold fokus inden for dialogboksen. Ved lukning: Flyt fokus tilbage til det element, der udløste det. Respekter Esc-tasten. Hvis det modale vindue afbryder et forløb (f.eks. automatisk afspilning ved sideindlæsning), skal brugeren have en enkelt mulighed for at lukke det permanent.

Fokusindikatorer fjernes som regel bevidst af en udvikler eller designer, der betragtede browserens standardramme som visuelt støj og skrev *:focus { outline: none; } i et globalt stilark. Siden fremstår nu mere overskuelig for en seende musebruger. For en seende tastaturbruger – herunder de fleste svagtseende, bevægelseshæmmede og brugere, der navigerer uden mus – bliver siden ubrugelig. Brugeren kan trykke på Tab-tasten, men kan ikke se, hvor vedkommende befinder sig.

Dette er en af de få fejltyper, der kan ses uden brug af hjælpemidler. En kvalitetskontrolmedarbejder, der blot tabber sig igennem startsiden én gang uden andre værktøjer, vil opdage fejlen på under et minut. At tilgængelighedsteams konsekvent finder fejlen på websteder, der er genstand for retssager, mens den interne kontrol har overset den, er et af de mest pålidelige tegn i datasættet på, at webstedet slet ikke har bestået tastaturtesten.

De bør aldrig deaktiveres generelt :focus konturlinjer uden erstatning. Anvend en tydelig markering — typisk en konturlinje på 2–3 px med tilstrækkelig kontrast i forhold til både elementet og dets baggrund — ved hjælp af :focus-visible så indikatoren vises ved tastaturnavigation, men ikke ved museklik. Kontroller dette på alle interaktive komponenter, herunder brugerdefinerede widgets, links i kort og elementer med tabindex.

Logoet er det mest besøgte billede på en hjemmeside og et af dem, der oftest er ødelagt. Det indgår typisk i et link, der fører tilbage til forsiden, men billedet leveres uden alt, nej aria-label på linket og ingen omgivende tekst. Skærmlæserprogrammet læser kun op ”link”, uden nogen oplysninger om, hvor den fører hen. Gang det med hver eneste side på hjemmesiden.

Den bredere kategori – billeder uden alternativ tekst – omfatter bannerbilleder, produktfotos, hero-illustrationer, ikoner til sociale medier samt det omfattende udvalg af marketingbilleder, som en typisk e-handelsside indeholder. Klager i denne kategori henviser ofte til specifikke billedfilnavne, hvilket tyder på, at sagsøgerens ekspert har foretaget en automatisk kontrol, der har identificeret alle billeder, hvis alt attributten manglede eller var tom, selvom den burde have været beskrivende.

Logoer bør indeholde en alternativ tekst, der beskriver virksomhedens navn, og hvis logoet linker til en side, skal den også angive, hvor den fører hen — alt="Acme Co. — homepage". Dekorative billeder får et tomt alt-attribut (alt=""), som bevidst skjuler dem for hjælpemidler. Informative billeder skal have beskrivende alternativ tekst. Undgå automatisk generering af alternativ tekst ud fra filnavne eller AI-tekstning uden menneskelig gennemgang; klageregistrene nævner gentagne gange tilfælde, hvor overlay-værktøjer har beskrevet et firmalogo som »et blåt og gult skilt«.

Skærmlæsere viser en visning med en »liste over links«, som erfarne brugere flittigt benytter til at gennemgå en side på få sekunder. Denne visning viser kun linkteksten, adskilt fra det omgivende afsnit. En side, hvor hver blog-teaser slutter med »Læs mere« vises i den pågældende visning som femten identiske poster. En side med fem tomme links — <a href="..."></a>, hvilket ofte forekommer, når ikoner er placeret i link-tags uden nogen tekst som alternativ — vises som fem mellemrum.

Løsningen er velkendt, og fejlen er velkendt, og det er netop derfor, dette mønster gang på gang dukker op i klagerne — dets vedvarende forekomst tyder på en udviklingsproces uden automatisk linter til linktekster og uden manuel gennemgang med skærmlæser.

Hvert link skal have et beskrivende navn, der angiver, hvor det fører hen, eller hvilken handling det udfører. Erstat generiske udtryk med beskrivende udtryk — »Læs mere« bliver »Læs mere om resultatet for 3. kvartal«. For links, der kun består af ikoner, skal du tilføje en skjult tekst eller en aria-label. Kør en automatisk kontrol (Axe, Lighthouse osv.) for tomme <a> elementer under CI.

Videoer indgår i klagerne på to måder. Den første er den åbenlyse: En markedsføringsvideo, produktdemo eller forklaringsvideo offentliggøres uden undertekster, transskription eller nogen form for tekstalternativ – og en døv eller hørehæmmet besøgende kan derfor ikke få adgang til indholdet. Det andet er mere subtilt: en hero-video, der afspilles automatisk, når siden indlæses, hvilket forstyrrer skærmlæserens output og overtræder de pause-/stop-kontroller, der forventes på WCAG 2.2 AA-niveau (i henhold til SC 2.2.2 Pause, Stop, Skjul for bevægeligt indhold og SC 1.4.2 for al lyd).

I nogle af klagerne i dette datasæt hævdes det, at »manglen på undertekster på hjemmesidens videoer udgør en overtrædelse af ADA«, hvilket fremstilles som en juridisk konklusion. Om denne fremstilling holder, afhænger af den enkelte jurisdiktion og de konkrete omstændigheder; hvad der derimod står mere fast, er, at disse videoer konsekvent ikke opfylder WCAG 2.2 AA, den standard, som de fleste domstole og forligsaftaler betragter som den gældende målestok for overholdelse.

Sørg for synkroniserede undertekster til alle forudindspillede videoer med lyd. Tilbyd også en teksttransskription; transskriptioner er nyttige for brugere med lyd fra på enheder, i miljøer med lav båndbredde og til indeksering. Undgå automatisk afspilning; hvis automatisk afspilning er nødvendig af designmæssige årsager, skal der være en pause-/stop-knap, der kan betjenes direkte via tastaturet. For indhold, der kun består af video (uden lyd), skal der være en lydbeskrivelse eller et tekstalternativ.

Login fungerer som portvagt for hele den godkendte brugeroplevelse. Når formularen svigter, bliver alle sider bagved utilgængelige, og brugerne opfatter ofte denne kæde af problemer som én samlet hindring. Mønsteret er den samme fejl i formularmærkningen som E·01, ofte kombineret med tre specifikke underfejl: en "Vis adgangskode"-knap, der er implementeret som en knap med kun et ikon uden navn og uden meddelelse om statusændring, en CAPTCHA, der fuldstændigt forhindrer brug af skærmlæser, og indbyggede fejl ("ugyldige legitimationsoplysninger"), der vises på skærmen, men ikke meddeles.

Afkrydsningsfeltet »Husk mig« er en yderligere tilbagevendende delfejl: det vises som et formateret <div>, med den faktiske <input> Da afkrydsningsfeltet er skjult uden for skærmbilledet, kan det kun betjenes med musen, men ikke med tastaturet eller en skærmlæser. Brugeren har ingen mulighed for at vælge en vedvarende session.

Brug ægte <input>, <label>, og <button> elementer. Gør knappen til at vise/skjule adgangskoden til en rigtig knap med et beskrivende navn, der opdateres i henhold til tilstanden ("Show password" / "Hide password") og meddele ændringen med aria-pressed. Tilbyd et tilgængeligt alternativ til billedbaserede CAPTCHA'er (lyd-CAPTCHA eller – helst – udskift CAPTCHA med risikobaseret autentificering eller hCaptchas tilgængelige varianter).

Skærmlæsere præsenterer siden via tre navigationsmetoder: efter overskrift, efter markør og efter link. En side, der leveres uden en <h1>, uden <main>, <nav>, og <footer> vartegn, og uden en lang="en" attribut på <html> elementet har fjernet alle tre navigationsfunktioner på én gang. Brugerne kan hverken skimme teksten, springe direkte til indholdet eller få skærmlæserprogrammet til at indlæse den rigtige udtalemotor.

Dette er en usædvanlig alvorlig fejl: Et enkelt manglende orienteringspunkt udløser en lang række klager, fordi alle skærmlæseres navigationsstrategier, der er afhængige af det, nu slår fejl. Klager i denne kategori nævner typisk fire eller fem specifikke strukturelle problemer på én gang, hvilket fremhæves som bevis på, at webstedet mangler en semantisk grundstruktur.

Hver side får én og kun én <h1>, med underoverskrifter (<h2>, <h3>) indlejret logisk. Indsæt regioner i HTML5-landmark-elementer: <header>, <nav>, <main>, <aside>, <footer>. Indstil lang ved roden <html> element. Kontroller med en konturchecker eller kør document.querySelectorAll('h1').length === 1 som en røgtest i CI.

Det meste af kvalitetssikringen af tilgængelighed foregår i desktop-browsere med NVDA eller JAWS. Hjælpemidler til mobilenheder – VoiceOver på iOS, TalkBack på Android – viser en anderledes gengivelse af det samme DOM, ofte med andre fejl. I klagerne bruges gentagne gange forkortelsen "mobile SRU" (mobile screen-reader user) til at markere fejl, der er unikke for mobilvisningen: et hamburger-menu, der fungerer med NVDA på desktop, men er lydløs under VoiceOver, en Apple Pay-knap, der kan nås på en bærbar computer, men ikke på sidens iPhone-ækvivalent, fejlmeddelelser, der annonceres på desktop, men ikke på mobil.

Dataene tyder på, at sagsøgte, hvis tilgængelighed på desktop-enheder ellers er i orden, stadig bliver sagsøgt på grund af problemer, der specifikt vedrører mobilenheder. Mobil tilgængelighed er en forudsætning for at bestå en tilgængelighedskontrol.

Test som minimum med VoiceOver i Safari på iOS og TalkBack i Chrome på Android på de samme brugerforløb, som QA på desktop dækker. Vær særlig opmærksom på gestusbaserede interaktioner, indbyggede betalingsknapper og oplæsning af formularfelter, når der sættes fokus på dem. Hvis der findes en native app, skal den gennemgå den samme kontrol – klager omfatter ofte både web og app i samme sag.

Tilgængelighedsoverlayet er det eneste eksempel i dette katalog, hvor fejlen slet ikke ligger i det underliggende websted — den findes i det såkaldte afhjælpningslag, der blev tilføjet for at løse problemet. Klager i denne kategori beskriver to forskellige problemer. Det første er, at overlayene ikke reelt fjerner de underliggende barrierer, så brugeren støder på de samme defekte modalvinduer, forkert mærkede formularer og uanmeldte fejl, uanset om widgeten er til stede. Den anden er mere præcis: Overlays introducerer undertiden nye fejl ved at indsætte forkerte etiketter, anvende ARIA-roller forkert eller forstyrre brugerens egen konfiguration af hjælpemidler.

En detalje, der er værd at bemærke: I klager fra 2024 og 2025 nævnes leverandøren af overlay-løsninger i stigende grad ved navn. To konkrete passager i klagerne nævner UserWay og AccessiBe i utvetydige vendinger, og de seneste tiltag fra FTC har skabt en klar risiko for, at brugen af et overlay i sig selv kan betragtes som bevis på manglende gennemførelse af reelle tilpasninger – snarere end som et forsvar mod retssager.

Betragt overlay-løsninger som en advarsel, ikke som en løsning. Hvis der i øjeblikket er implementeret en sådan løsning, bør du udarbejde en plan for en reel afhjælpning, der tager fat på den underliggende kode i stedet for blot at skjule problemet. Den gennemprøvede fremgangsmåde består af en kombination af følgende: en automatiseret scanner integreret i CI, en manuel gennemgang i henhold til WCAG 2.2 AA, manuel testning med mindst én skærmlæser og navigation udelukkende via tastaturet samt løbende kvalitetssikring af tilgængeligheden i design- og udviklingsprocessen.