Vad som leder till stämningar: En praktisk guide till de gränssnittsmönster som ligger bakom 6 666 klagomål om tillgänglighet

Sidhuvudet är den första interaktiva ytan på varje sida, och hamburgerknappen är ofta det första som en tangentbordsanvändare kommer åt. När den knappen visas som en <div> om den har en bakgrundsbild i CSS, saknar ett tillgänglighetsnamn eller öppnar en meny som låser fokus eller inte visar om den är öppen eller stängd, blir hela webbplatsen i praktiken omöjlig att använda med tangentbordet redan innan användaren har kommit åt något egentligt innehåll.

Hoppa över-länken är det som inte fungerar. En fungerande "Skip to main content" Länken är en åtgärd som bara tar fem rader, men den är också det absolut mest effektiva sättet att avgöra om ett utvecklingsteam överhuvudtaget har tillgänglighet med på sin checklista. I klagomål nämns ofta båda dessa saker i samma stycke, eftersom en saknad eller trasig hoppa-över-länk fungerar som en varningssignal – om teamet inte har implementerat en hoppa-över-länk har de med största sannolikhet inte heller implementerat aria-expanded-tillstånd.

Rendera menyutlösaren som en riktig <button> med en textetikett som är synlig eller endast läsbar med skärmläsare och en hanterad aria-expanded attribut. Ange ett "Skip to main content" en länk som blir synlig när man för muspekaren över den och som hamnar inuti <main> markör. Se till att markören hamnar i menyn när den öppnas, återgår till utlösaren när den stängs och att Esc stänger menyn.

Sökfunktionen byggs om som en anpassad komponent på de flesta stora webbplatser – ett textinmatningsfält med avbounce-funktion som skickar en förfrågan vid varje tangenttryckning och visar en flytande lista med förslag inuti ett absolutpositionerat <div>. Själva textinmatningen fungerar oftast bra. Förslagslistan gör det nästan aldrig. Den renderas utanför inmatningsfältets DOM-kontext och har ingen role="listbox", nej aria-activedescendant, och det visas inget meddelande i live-regionen när resultaten visas. En användare av skärmläsare skriver, hör ingenting, trycker på Enter och får upp en resultatsida som hen inte visste väntade.

Samma arkitekturmönster återkommer i filterpanelerna för facetterad sökning och i själva resultatlistan: element som kan få tangentbordsfokus och som syns men aldrig läses upp. Klagomål på sökfunktionen handlar sällan om själva sökrutan; de gäller allt som visas efter att användaren har skrivit in något.

Använd det etablerade WAI-ARIA-mönstret för kombinationsrutor: role="combobox" på ingången med aria-expanded, aria-controls, och aria-activedescendant ansluten till en role="listbox" förslag. Lägg till ett interaktivt område som visar antalet träffar. Se till att man kan nå förslagslistan med nedpilen, inte bara med musen.

PLP-rutnätet samlar flera anti-mönster på en och samma skärm. Varje ruta är vanligtvis ett klickbart kort med tre eller fyra interaktiva underelement – bildlänk, titellänk, färgprover, snabbtilläggsknapp – som alla är inbäddade i en ytterligare länk till produktsidan. Resultatet blir inbäddade interaktiva element (ett HTML-fel), överflödig länktext (”Hero Dash Three Graphic Image Link” som upprepas fyra gånger) och färgprover som är uppbyggda av <div> element med klickhändelser men utan roll och utan namn.

Filterpanelen lägger till en ytterligare felkategori. Filterfacetter är oftast listor med kryssrutor, men byggs med anpassade div- och span-element som är formaterade för att se ut som kryssrutor, där själva <input> dold utanför skärmen. När den dolda inmatningen förlorar sin koppling – genom en CSS-regel, en JavaScript-händelsehanterare som avbryter tryckningar på mellanslagstangenten eller en saknad for attributet på den synliga etiketten – filtret kan då endast användas med musen.

Använd ett länk per produkt med beskrivande text, inte tre länkar per produkt. Visa färgproverna som de ser ut i verkligheten <button> element inuti en role="radiogroup". Skapa filterfacetter baserade på faktiska <input type="checkbox"> element med tillhörande <label> taggar; formatera inmatningsfälten så att de syns istället för att dölja dem. Meddela filterändringar med en tydlig live-region.

På produktinformationssidan måste en användare av en skärmläsare göra flera specifika val i rätt ordning: välja färg, välja storlek, ange antal och sedan lägga till i varukorgen. Var och ett av dessa val implementeras i modern e-handel som en anpassad widget – vanligtvis en horisontell rad med <button>-formad <div>När det gäller storlekar, färgade rutor skapade av div-element med CSS-stil och en numerisk reglage som består av två ikonknappar på vardera sidan om ett inmatningsfält. Knapparna för att öka och minska levereras ofta utan tillgänglighetsnamn; klagomålen beskriver dem som presenterad som ”button, button” utan någon uppgift om vad de sysslar med.

Storleksguider och storlekstabeller utgör ett separat problem: de finns nästan alltid bakom en länk med texten ”Storlekstabell” som öppnar ett popup-fönster, och själva länken saknar ofta text, popup-fönstret har ofta ingen angiven titel och tabellen inuti saknar ofta rad- eller kolumnrubriker.

Använd riktiga formulärkontroller. Färgprover och storleksväljare bör vara en role="radiogroup" av role="radio" knappar (eller vanliga radioknappar som är utformade så att de inte syns), var och en med ett tillgänglighetsnamn som ”Storlek: Medium”. Reglaget för antal ska vara ett numrerat inmatningsfält med tillhörande knappar för att öka respektive minska, där tillgänglighetsnamnen anger åtgärden och det aktuella antalet. Omge hela urvalsblocket med ett fieldset med en förklarande text.

”Lägg i varukorgen” är det mest testade steget i alla e-handelsprocesser och ett av de som oftast inte fungerar för användare av hjälpmedel. Förloppet är mekaniskt: en besökare trycker på knappen, ett litet bekräftelsemeddelande eller en liten varukorgsmeny visas i två eller tre sekunder, och varukorgsikonen uppdaterar antalstecknet i sidhuvudet. Seende användare ser alla tre signalerna. Användare av skärmläsare får vanligtvis ingen. Meddelandet visas utanför det aktiva området, facket visas utan fokushantering och ändringen av varukorgens antal levereras som en vanlig DOM-mutation som ingen skärmläsare kommer att läsa upp.

Resultatet blir en knapp som, ur användarens perspektiv, inte gör någonting. De trycker på den, hör ingenting, antar att den inte fungerade och trycker på den igen. I vissa klagomål beskrivs hur man tryckt på knappen fem eller sex gånger innan man insåg att varukorgen i tysthet hade fyllts med fem eller sex varor.

Omge området för vagnens status med aria-live="polite" och uppdatera texten varje gång en artikel läggs till. Om designen använder en bekräftelsepanel ska fokus flyttas till panelen när den öppnas och återgå till den ursprungliga knappen när den stängs. Uppdatera antal-i-varukorgen med ett meddelande som endast läses upp av skärmläsare, till exempel ”1 artikel tillagd. Totalt i varukorgen: 3 artiklar.”

Kontroller som endast består av ikoner uppvisar förutsägbara brister: det synliga innehållet är en SVG-bild eller en teckenuppsättning från ett ikonfont, det tillgängliga innehållet är tomt och skärmläsarens uppläsning reduceras till elementets strukturella roll utan namn. Vagnsikonen läser upp som ”länk” eller ”minimerad”; chattbubblan som ”knapp”; raden med sociala ikoner i sidfoten som ”länk, länk, länk, länk, länk”. Användaren har ingen möjlighet att veta vad någon av dem gör.

Ikoner för varukorgar misslyckas oftare än andra ikoner av en arkitektonisk anledning: i många implementeringar återges antalet varor i varukorgen i ikonens tillgängliga namn (t.ex. visar ikonen ”0” inuti SVG-koden), och skärmläsaren läser endast upp siffran. I klagomål beskrivs att ikonen för varukorgen läses upp som ”3, länk” eller ”0, länk”, utan någon indikation på att ”3” avser antalet varor i en varukorg.

Varje kontroll som endast består av en ikon måste ha ett tillgänglighetsnamn. Lägg till ett aria-label på knappen eller placera en textetikett som inte syns inuti den: "Shopping cart, 3 items". Undvik att placera siffror i ikonens tillgängliga namn utan sammanhang. För dekorativa ikoner som placeras bredvid synlig text, använd aria-hidden="true" klicka på ikonen och låt texten fungera som etikett.

Kassan innebär en större efterlevnadsrisk per pixel än någon annan sida på en e-handelswebbplats, och det förekommer många fel. Adressrullgardinsmenyer som visas som anpassade <div> komponenter som ignorerar mellanslagstangenten. Markeringar för obligatoriska fält visas endast som en röd asterisk, utan aria-required och ingen programmatisk koppling. Inbyggda felmeddelanden visas i röd text under fältet, utan aria-describedby fältet kopplas till felet och det visas inget meddelande i det aktiva området när valideringen misslyckas. Användaren fyller i formuläret, klickar på ”Fortsätt”, skickas tillbaka utan någon förvarning och har ingen möjlighet att veta vilka fält som inte godkändes eller varför.

Samma klagomål återkommer i hundratals fall: felmeddelanden läses inte upp, felmeddelanden är otydliga, det går inte att ange betalningsuppgifter. Det här är inte enstaka buggar. Det är standardbeteendet hos de flesta betalningskomponenter som levereras utan att man uttryckligen har arbetat med tillgänglighet.

Använd äkta <label> element som är kopplade till ingångar genom for/id. Markera obligatoriska fält med aria-required="true" och ange kravet med synlig text, inte bara med färg. Om valideringen misslyckas ska felmeddelandet visas inuti inmatningsfältets aria-describedby mål, ange det felaktiga fältet aria-invalid="true", och flytta tangentbordsfokus till det första fältet med fel. Skapa ett sammanfattande felområde högst upp i formuläret med länkar till varje fält som inte uppfyller kraven.

Betalningsblocket är ovanligt eftersom det ofta levereras via en inbäddad iframe från en tredjepartsleverantör – Stripe Elements, Braintree Hosted Fields eller en Adyen-drop-in. Inuti iframen är betalningsleverantörens eget formulär vanligtvis tydligt märkt. Men så fort en webbplats skapar sin egen kortinmatning, eller omsluter de inbäddade fälten i en anpassad layout som ersätter etiketterna med visuella platshållare, blir de fyra fälten – nummer, giltighetstid, CVV, postnummer – en rad tomma inmatningsfält för en skärmläsare.

Fältet för CVV-kod är det som oftast felmärks, eftersom utvecklare ofta ersätter dess etikett med en frågeteckensymbol som öppnar ett verktygstips som förklarar vad en CVV-kod är. Verktygstipset är inte etiketten; fältet behöver fortfarande ett programmatiskt namn. Om det saknar ett sådant läser skärmläsaren upp hela betalningsblocket som ”redigera, redigera, redigera, redigera” och transaktionen avbryts.

Om du använder en integration med fält som tillhandahålls av en tredje part ska du följa leverantörens riktlinjer för tillgänglighet – de flesta erbjuder en dokumenterad metod för att märka upp fält utanför iframe-rutan. Om du skapar en anpassad kortinläsningsfunktion måste varje inmatningsfält ha en riktig <label> element med en synlig textetikett, samt autocomplete="cc-number" / cc-exp" / cc-csc" attribut så att lösenordshanterare och hjälpmedel kan identifiera fälten utifrån deras syfte.

På varukorgssidan upprepas samma problem med stegraren för antal på produktsidan, men med ännu större konsekvenser: en användare av skärmläsare som inte kan använda stegraren kan inte slutföra beställningen. Knappen ”Ta bort” är i sig ett exempel på ett anti-mönster – den är oftast en liten ×-ikon bredvid varje artikelrad, ofta utan synlig text, utan aria-label, och ingen återkoppling när raden tas bort. Användaren trycker på vad hen hoppas är borttagningsknappen, raden försvinner och skärmläsaren säger ingenting. Det finns inget sätt att bekräfta att åtgärden lyckades.

I flera klagomål beskrivs ett liknande fel: varukorgens löpande summa uppdateras dynamiskt när antalet ändras eller varor tas bort, men den nya summan visas som vanlig DOM-text utanför alla realtidsområden, vilket gör att användaren inte har en aning om vad hen kommer att debiteras.

Varje rad bör ha en märkt borttagningsknapp (t.ex. "Remove Blue T-Shirt, size M, from cart"). Stegrare för antal bör ange sitt aktuella värde som en del av det tillgängliga namnet eller genom uppdateringar i en kopplad live-region. Varukorgens delsumma bör placeras inuti en aria-live="polite" i regionen så att ändringarna meddelas. Bekräfta borttagningar med en ångra-funktion.

Detta är den enskilt största kategorin i datauppsättningen, eftersom det är det billigaste problemet att upptäcka och det dyraste att ignorera. En skärmläsare går igenom DOM-trädet och stöter på en <input>, och läser dess tillgängliga namn — som den beräknar utifrån följande, i ordning: aria-labelledby, aria-label, ett närstående <label for>, den title attributet eller platshållaren. Om inget av dessa finns läser skärmläsaren endast upp rollen: ”redigeringsfält” eller ”redigering, tomt”. Denna formulering återkommer, nästan ordagrant, i hundratals klagomål.

Anledningen till att detta är så vanligt är strukturell. Moderna designsystem visar ofta platshållartext inuti inmatningsfältet som en ersättning för den synliga etiketten, och utvecklare antar att platshållaren fyller funktionen som etikett. Så är det inte. Platshållaren försvinner när användaren skriver, lämnar inget programmatiskt namn efter sig och gör fältet oanvändbart för alla som kommer till det senare i flödet eller återvänder till det efter ett fel.

Varje interaktiv kontroll får en synlig etikett som kopplas till den programmatiskt. <label for="email">Email</label><input id="email" type="email"> är det standardmässiga mönstret. Platshållare är kompletterande tips, inte ersättare. För kontroller där en synlig etikett verkligen inte är önskvärd (sökrutor, ikonknappar), använd aria-label med beskrivande text — aldrig med platshållaren duplicerad.

Frasen ”inte meddelat eller fått fokus” förekommer ordagrant i över 400 klagomål och är en av de mest återkommande meningarna i hela datasetet. Den beskriver ett specifikt fel: ett modalfönster eller en dialogruta visas på sidan (ofta automatiskt – nyhetsbrevsregistrering, ålderskontroll, platsbekräftelse), det synliga innehållet förändras, men skärmläsaren får ingen signal om att något har ändrats. Fokuset förblir på den underliggande sidan. Användaren fortsätter att tabba sig igenom det som fanns under modalfönstret, helt ovetande om att en blockerande dialogruta har dykt upp.

Detta är ett typiskt exempel på en modalitet som misslyckas på alla plan samtidigt: nej role="dialog", nej aria-modal="true", ingen programmatisk fokusförskjutning vid öppet läge, ingen fokusfälla när fönstret är öppet, inget beteende där man stänger med Esc, ingen visad titel. Eftersom alla dessa brister förekommer samtidigt, gör det ingen skillnad att åtgärda en av dem isolerat.

Använd ett etablerat dialogmönster (specifikationen WAI-ARIA Authoring Practices utgör referens). Vid öppning: flytta fokus till det första elementet som kan få fokus inuti dialogrutan, ställ in aria-modal="true" och role="dialog", ge dialogrutan namnet aria-labelledby peka på dess rubrik. När fönstret är öppet: behåll fokus inom dialogrutan. Vid stängning: återför fokus till det element som utlöste fönstret. Stöd Esc-tangenten. Om det modala fönstret avbryter ett flöde (t.ex. automatisk uppspelning när sidan laddas), ge användaren en enda funktion för att stänga det permanent.

Fokusindikatorer tas oftast bort medvetet av en utvecklare eller designer som betraktade webbläsarens standardmarkering som visuellt störande och skrev *:focus { outline: none; } i ett globalt formatmall. Sidan ser nu renare ut för en seende musanvändare. För en seende tangentbordsanvändare – inklusive de flesta användare med nedsatt syn, motoriska funktionsnedsättningar eller som navigerar utan mus – blir sidan oanvändbar. Användaren kan trycka på Tab-tangenten, men kan inte se var hen befinner sig.

Detta är ett av få fel som går att upptäcka utan hjälpmedel. En kvalitetsgranskare som bläddrar igenom startsidan en gång med tabbtangenten, utan några andra verktyg, kommer att upptäcka det på mindre än en minut. Att tillgänglighetsteam konsekvent hittar detta på webbplatser som är föremål för rättstvist, medan interna granskningar har missat det, är ett av de tydligaste tecknen i datauppsättningen på att webbplatsen inte klarar något tangentbordstest alls.

Inaktivera aldrig generellt :focus konturer utan ersättning. Skapa en tydlig markering – vanligtvis en kontur på 2–3 pixlar med tillräcklig kontrast mot både elementet och dess bakgrund – genom att använda :focus-visible så att markören visas vid tangentbordsnavigering men inte vid musklick. Kontrollera detta för alla interaktiva komponenter, inklusive anpassade widgetar, länkar inuti kort och element med tabindex.

Logotypen är den bild som besöks oftast på en webbplats och en av de som oftast är trasig. Den ingår vanligtvis i en länk som leder tillbaka till startsidan, men bilden levereras utan alt, nej aria-label på länken, utan någon omgivande text. Skärmläsaren läser endast upp ”länk”, utan någon information om vart den leder. Multiplicera detta med varje sida på webbplatsen.

Den bredare kategorin – bilder utan alt-text – omfattar bannergrafik, produktbilder, huvudillustrationer, symboler för sociala medier samt det omfattande utbudet av marknadsföringsbilder som en typisk e-handelssajt använder. I klagomål inom denna kategori nämns ofta specifika bildfilnamn, vilket tyder på att kärandens expert har genomfört en automatisk kontroll som listat alla bilder vars alt attributet saknades eller var tomt när det borde ha varit beskrivande.

Logotyper bör ha en alt-text som beskriver företagsnamnet och, om logotypen länkar någonstans, vart den leder — alt="Acme Co. — homepage". Dekorativa bilder får ett tomt alt-attribut (alt=""), vilket medvetet döljer dem för hjälpmedel. Informativa bilder ska förses med beskrivande alt-text. Undvik att automatiskt generera alt-text utifrån filnamn eller AI-textning utan mänsklig granskning; i klagomålsregister nämns upprepade gånger fall där överläggningsverktyg har beskrivit ett företagslogotyp som ”en blå och gul skylt”.

Skärmläsare visar en vy med en ”lista över länkar”, som erfarna användare ofta använder för att snabbt överblicka en sida. Denna vy visar endast länktexten, utan det omgivande stycket. En sida där varje bloggtextsnutt slutar med ”Läs mer” visas i den vyn som femton identiska poster. En sida med fem tomma länkar — <a href="..."></a>, vilket ofta förekommer när ikoner placeras i länkkapslar utan någon reservtext — ger fem tomma tecken.

Lösningen är välkänd och felet är välkänt, vilket är anledningen till att detta mönster återkommer i klagomålen – att det fortsätter att förekomma tyder på en utvecklingsprocess utan automatiserad linter för länktexter och utan manuell kontroll med skärmläsare.

Varje länk måste ha ett beskrivande namn som anger vart den leder eller vilken åtgärd den utför. Ersätt allmänna uttryck med beskrivande sådana — ”Läs mer” blir ”Läs mer om resultatet för tredje kvartalet”. För länkar som endast består av ikoner, lägg till dold text eller en aria-label. Kör en automatisk kontroll (axe, Lighthouse osv.) för tomma <a> element under CI.

Video förekommer i klagomål på två olika sätt. Det första är uppenbart: en marknadsföringsvideo, produktdemo eller informationsvideo publiceras utan undertexter, transkription eller något textalternativ – vilket gör att en döv eller hörselskadad besökare inte kan ta del av innehållet. Det andra är mer subtilt: en huvudvideo som spelas upp automatiskt när sidan laddas, vilket stör skärmläsarens utmatning och bryter mot de paus-/stoppkontroller som förväntas enligt WCAG 2.2 AA-nivå (enligt SC 2.2.2 Pausa, stoppa, dölja för rörligt innehåll och SC 1.4.2 för allt ljud).

I vissa klagomål i denna datauppsättning hävdas det att ”avsaknaden av undertexter i webbplatsens videoklipp utgör ett brott mot ADA”, vilket framställs som en rättslig slutsats. Huruvida denna tolkning håller varierar beroende på jurisdiktion och omständigheter; det som är mer bestående är att dessa videoklipp genomgående inte uppfyller WCAG 2.2 AA, den standard som de flesta domstolar och förlikningsavtal betraktar som den avgörande referensramen för efterlevnad.

Se till att alla förinspelade videoklipp med ljud har synkroniserade undertexter. Tillhandahåll även en textutskrift; utskrifter är användbara för användare med ljudet avstängt, i miljöer med låg bandbredd samt för indexering. Undvik automatisk uppspelning; om automatisk uppspelning krävs av designskäl ska det finnas en paus-/stoppknapp som är direkt tillgänglig via tangentbordet. För innehåll som endast består av video (utan ljud) ska en ljudbeskrivning eller ett textalternativ tillhandahållas.

Inloggningen fungerar som portvakt för hela den autentiserade upplevelsen. När formuläret inte fungerar blir alla sidor bakom det otillgängliga, och i klagomål betraktas ofta denna kedjereaktion som ett enda hinder. Mönstret är samma fel i formulärmärkningen som E·01, ofta i kombination med tre specifika delfel: en växlingsknapp för ”Visa lösenord” som är implementerad som en knapp med endast en ikon utan namn och utan meddelande om statusändring, en CAPTCHA som helt omöjliggör användning av skärmläsare, samt inbyggda felmeddelanden (”ogiltiga inloggningsuppgifter”) som visas på skärmen men inte läses upp.

Kryssrutan ”Kom ihåg mig” är ett ytterligare återkommande delfel: den visas som en formaterad <div>, med den faktiska <input> Eftersom den är dold utanför skärmen går det att markera kryssrutan med musen, men inte med tangentbordet eller en skärmläsare. Användaren har ingen möjlighet att välja att använda en permanent session.

Använd äkta <input>, <label>, och <button> element. Gör knappen för att visa/dölja lösenordet till en riktig knapp med ett tillgängligt namn som uppdateras efter status ("Show password" / "Hide password") och meddela ändringen genom att aria-pressed. Tillhandahåll ett tillgängligt alternativ till bildbaserade CAPTCHA-tester (ljudbaserade CAPTCHA-tester, eller – helst – ersätt CAPTCHA med riskbaserad autentisering eller hCaptchas tillgängliga varianter).

Skärmläsare presenterar sidan i tre olika navigeringslägen: efter rubrik, efter landmärke och efter länk. En sida som levereras utan en <h1>, utan <main>, <nav>, och <footer> sevärdheter, och utan en lang="en" attribut på <html> elementet har tagit bort alla dessa tre navigeringslägen samtidigt. Användarna har ingen möjlighet att bläddra, ingen möjlighet att hoppa till innehållet och ingen möjlighet för skärmläsaren att ladda rätt uttalsmotor.

Detta är ett ovanligt omfattande fel: ett enda saknat orienteringspunkt leder till en kedjereaktion av klagomål längre ner i webbplatsen, eftersom alla navigeringsstrategier för skärmläsare som är beroende av den nu slutar fungera. Klagomål i denna kategori tar vanligtvis upp fyra eller fem specifika strukturella problem samtidigt, vilket framhålls som bevis på att webbplatsen saknar en semantisk grundstruktur.

Varje sida får en och endast en <h1>, med underrubriker (<h2>, <h3>) logiskt grupperade. Omge regionerna med HTML5-landmärkeselement: <header>, <nav>, <main>, <aside>, <footer>. Ställ in lang vid roten <html> element. Kontrollera med ett verktyg för att granska konturerna eller kör document.querySelectorAll('h1').length === 1 som ett rökprov i CI.

Det mesta av kvalitetskontrollen av tillgängligheten utförs i webbläsare på stationära datorer med NVDA eller JAWS. Hjälpmedel för mobila enheter – VoiceOver på iOS och TalkBack på Android – visar en annan rendering av samma DOM, ofta med andra buggar. I klagomål används ofta förkortningen ”mobile SRU” (mobile screen-reader user) för att markera fel som är unika för mobilvyn: en hamburgermeny som fungerar med NVDA på datorn men inte med VoiceOver, en Apple Pay-knapp som går att nå på en bärbar dator men inte på sidans motsvarighet på iPhone, felmeddelanden som visas på datorn men inte på mobilen.

Data tyder på att företag som i övrigt har en god tillgänglighet på stationära enheter ändå stäms på grund av problem specifika för mobila enheter. Att uppnå samma nivå på mobila enheter är ett krav i sig vid granskningar.

Testa åtminstone med VoiceOver i Safari på iOS och TalkBack i Chrome på Android, med samma flöden som ingår i kvalitetsgranskningen för datorer. Lägg särskilt fokus på gestbaserade interaktioner, inbyggda betalningsknappar och uppläsning av formulärfält när de får fokus. Om det finns en inbyggd app ska den genomgå samma granskning – klagomål gäller ofta både webbversionen och appen i samma ärende.

Tillgänglighetsöverlägget är det enda exemplet i denna katalog där felet inte alls ligger i den underliggande webbplatsen – det finns i det så kallade korrigeringslagret som lades till för att åtgärda det. Klagomål i denna kategori beskriver två olika problem. Det första är att överlägg inte faktiskt åtgärdar de underliggande hindren, vilket innebär att användaren stöter på samma felaktiga modalfönster, felmärkta formulär och oväntade felmeddelanden oavsett om widgeten är aktiv eller inte. Den andra är mer konkret: överlägg introducerar ibland nya fel genom att infoga felaktiga etiketter, tillämpa ARIA-roller på fel sätt eller störa användarens egen konfiguration av hjälpmedel.

En detalj som är värd att notera: i klagomål från 2024 och 2025 nämns leverantören av överläggsprogrammet allt oftare vid namn. I två specifika avsnitt i klagomålen nämns UserWay och AccessiBe i tydliga ordalag, och FTC:s senaste åtgärder har skapat en påtaglig risk för att införandet av ett överläggsprogram i sig kan ses som ett tecken på att man inte har genomfört några verkliga åtgärder – snarare än som ett försvar mot rättsliga åtgärder.

Betrakta överlägg som en varningssignal, inte som en lösning. Om ett sådant överlägg redan används bör du utarbeta en plan för en verklig åtgärd som tar itu med den underliggande koden istället för att dölja problemen. Den beprövade metoden består av en kombination av följande: en automatiserad skanner integrerad i kontinuerlig integration (CI), en manuell granskning mot WCAG 2.2 AA, manuella tester med minst en skärmläsare och navigering enbart med tangentbordet, samt löpande kvalitetssäkring av tillgängligheten under design- och utvecklingsprocessen.