Què es denuncia: una guia de camp sobre els patrons d'IU darrere de 6.666 queixes d'accessibilitat

La capçalera és la primera superfície interactiva de cada pàgina, i el botó d'hamburguesa sovint és el primer que arriba a l'usuari del teclat. Quan aquest botó es representa com a <div> amb una imatge de fons CSS, no té un nom accessible o expandeix un menú que atrapa el focus o no comunica el seu estat obert/tancat, tot el lloc web esdevé estructuralment inoperable des del teclat abans que l'usuari hagi tocat cap contingut real.

L'enllaç de salt és l'error complementari. Un error que funciona "Skip to main content" L'enllaç és una solució de cinc línies, però també és la pantalla més eficient per saber si un equip de desenvolupament té l'accessibilitat a la seva llista de comprovació. Les queixes sovint citen tots dos al mateix paràgraf, perquè un enllaç de salt que falta o està trencat és el problema: si l'equip no va enviar un enllaç de salt, gairebé segur que tampoc va enviar estats expandits per ària.

Renderitza el disparador del menú com a real <button> amb una etiqueta de text visible o només per a lectors de pantalla i una opció gestionada aria-expanded atribut. Proporcioneu un "Skip to main content" enllaç que es fa visible en el focus i aterra dins del <main> punt de referència. Assegureu-vos que el focus entra al menú quan s'obre, torna al disparador quan es tanca i que Esc descarta el menú.

La cerca es reconstrueix com un component personalitzat a la majoria de llocs web grans: una entrada de text amb rebot que activa una sol·licitud amb cada pulsació de tecla i representa una llista flotant de suggeriments dins d'un espai de treball posicionat absolutament. <div>. L'entrada de text en si sol estar bé. La llista de suggeriments gairebé mai ho està. Es renderitza fora del context DOM de l'entrada, no té cap role="listbox", no aria-activedescendant, i no hi ha cap anunci de regió en directe quan apareixen els resultats. Un usuari de lector de pantalla escriu, no sent res, prem Intro i obté una pàgina de resultats que no sabia que esperava.

El mateix patró d'arquitectura es repeteix en els panells de filtre de cerca per facetes i en la mateixa llista de resultats: elements enfocables al teclat que són visualment presents però mai s'anuncien. Les queixes sobre la cerca rarament són sobre el quadre de cerca; són sobre tot el que apareix després que l'usuari escrigui.

Utilitzeu el patró de quadre combinat WAI-ARIA establert: role="combobox" a l'entrada amb aria-expanded, aria-controls, i aria-activedescendant connectat a un role="listbox" de suggeriments. Afegiu una regió activa i educada que anunciï el recompte de resultats. Assegureu-vos que es pugui accedir a la llista de suggeriments amb la tecla de fletxa avall, no només amb el ratolí.

La quadrícula PLP concentra diversos antipatrons en una pantalla. Cada mosaic és normalment una targeta clicable amb tres o quatre fills interactius (enllaç d'imatge, enllaç de títol, mostres de color, botó d'afegir ràpidament) embolicats en un altre enllaç a la pàgina del producte. El resultat són elements interactius imbricats (un error HTML), text d'enllaç redundant ("Enllaç d'imatge gràfica de tres enllaços de Hero Dash" repetint-se quatre vegades) i mostres de color creades a partir de <div> elements amb controladors de clics però sense rol ni nom.

La barra lateral del filtre afegeix una segona categoria d'error. Les facetes del filtre solen ser llistes de caselles de selecció, però creades amb elements div-and-span personalitzats amb un estil que sembla caselles de selecció, amb el <input> ocult fora de la pantalla. Quan aquesta entrada oculta perd la seva associació, a través d'una regla CSS, un controlador d'esdeveniments JavaScript que s'empassa les pulsacions de la tecla espai o una manca for l'atribut de l'etiqueta visible: el filtre només es pot utilitzar amb el ratolí.

Utilitzeu una àncora per tessel·la amb text descriptiu, no tres enllaços per producte. Renderitzeu les mostres com a reals. <button> elements dins d'un role="radiogroup". Crea facetes de filtre sobre dades reals <input type="checkbox"> elements associats <label> etiquetes; apliqueu estil a les entrades de manera visible en lloc d'amagar-les. Anuncia els canvis de filtre amb una regió activa educada.

La pàgina de detalls del producte és on un usuari de lector de pantalla ha de fer diverses opcions específiques en l'ordre correcte: triar un color, triar una mida, definir una quantitat i afegir a la cistella. Cadascuna d'aquestes opcions s'implementa en el comerç electrònic modern com un widget personalitzat, normalment una fila horitzontal de <button>en forma <div>s per a mides, mosaics de colors creats a partir de divs d'estil CSS i un programa numèric fet amb dos botons d'icona que flanquegen una entrada. Els botons d'augment i disminució s'envien habitualment sense un nom accessible; les queixes els descriuen com a anunciat com a «botó, botó» sense cap indicació del que fan.

Les guies de talles i les taules de talles són un suberror a part: gairebé sempre es troben darrere d'un enllaç "Taula de talles" que obre un modal, i l'enllaç en si sovint no té etiqueta, el modal sovint no té un títol anunciat i la taula que hi ha a dins sovint no té capçaleres de fila o columna.

Utilitzeu controls de forma real. Les mostres de color i els selectors de mida haurien de ser role="radiogroup" de role="radio" botons (o entrades de ràdio reals amb un estil invisible), cadascuna amb un nom accessible com ara "Mida: Mitjana". El programador de quantitats ha de ser una entrada numèrica etiquetada amb botons d'increment/decrement aparellats, els noms accessibles dels quals incloguin l'acció i la quantitat actual. Embolica tot el bloc de selecció en un conjunt de camps amb una llegenda.

L'afegir a la cistella és el moment més provat en qualsevol embut de comerç electrònic i un dels que falla més constantment per als usuaris de tecnologia assistiva. El patró és mecànic: un visitant prem el botó, apareix un petit missatge de confirmació o un calaix de mini-cistella durant dos o tres segons, i la icona de la cistella actualitza una insígnia de recompte a la capçalera. Els usuaris vidents veuen els tres senyals. Els usuaris de lectors de pantalla normalment reben zero. El missatge de confirmació es renderitza fora de qualsevol regió activa, el calaix apareix sense gestió del focus i el canvi de recompte de la cistella es lliura com una mutació DOM simple que cap lector de pantalla anunciarà.

El resultat és un botó que, des de la perspectiva de l'usuari, no fa res. El prem, no sent res, assumeix que ha fallat, el torna a prémer. Algunes queixes descriuen haver premut el botó cinc o sis vegades abans d'adonar-se que el carretó havia acumulat silenciosament cinc o sis articles.

Envolta la regió d'estat del carretó a aria-live="polite" i actualitza el seu text cada vegada que s'afegeix correctament. Si el disseny utilitza un calaix de confirmació, mou el focus al calaix quan s'obri i torna el focus al botó original quan es tanqui. Actualitza la insígnia del recompte de cistelles amb un anunci només per a lectors de pantalla com ara "1 article afegit. Total de la cistella: 3 articles".

Els controls només d'icones fallen d'una manera predictible: el contingut visible és un glif SVG o d'icona de font, el contingut accessible és buit i la sortida del lector de pantalla es redueix al rol estructural de l'element sense nom. La icona del carretó acaba anunciant-se com a "enllaç" o "reduïda" ; la bombolla de xat com a "botó" ; la fila d'icones socials al peu de pàgina com a "enllaç, enllaç, enllaç, enllaç, enllaç" . L'usuari no té manera de saber què fa cap d'ells.

Les icones del carretó de la compra fallen més sovint que altres icones per una raó arquitectònica: moltes implementacions representen el recompte del carretó dins del nom accessible de la icona (per exemple, la icona mostra "0" dins de l'SVG) i el lector de pantalla només detecta el dígit. Les queixes descriuen la icona del carretó que s'anuncia com a "3, enllaç" o "0, enllaç" , sense cap indicació que "3" es refereix a una quantitat en un carretó de la compra.

Cada control només d'icona necessita un nom accessible. Afegeix un aria-label al botó o embolicar-hi una etiqueta de text visualment oculta: "Shopping cart, 3 items"Eviteu posar dígits de recompte dins del nom accessible de la icona sense context. Per a icones decoratives que es troben al costat de text visible, utilitzeu aria-hidden="true" a la icona i deixa que el text porti l'etiqueta.

El procés de compra concentra més risc de compliment per píxel quadrat que qualsevol altra pàgina d'un lloc web comercial, i el patró d'errors és dens. Els menús desplegables d'adreces es mostren com a personalitzats. <div> components que ignoren la tecla d'espai. Els marcadors de camp obligatori es mostren només amb un asterisc vermell, sense aria-required i sense associació programàtica. Missatges d'error en línia pintats en text vermell sota el camp, sense aria-describedby enllaçant el camp a l'error i sense anunci de regió en directe quan la validació falla. L'usuari omple el formulari, prem "Continua", és retornat silenciosament i no té manera de saber quins camps han fallat o per què.

El mateix llenguatge de queixa es repeteix en centenars de casos: no s'anuncia el missatge d'error , els missatges d'error són vagues , no es pot introduir la informació de facturació . Aquests no són errors aïllats. Són el comportament per defecte de la majoria dels components de pagament de comerç electrònic que s'envien sense un treball d'accessibilitat explícit.

Utilitza real <label> elements associats a les entrades per for/idMarqueu els camps obligatoris amb aria-required="true" i indica el requisit en text visible, no només en color. En cas d'error de validació, mostra el missatge d'error dins de l'entrada. aria-describedby objectiu, doneu el camp fallant aria-invalid="true"i mou el focus del teclat al primer camp no vàlid. Proporciona una regió d'errors resumits a la part superior del formulari amb enllaços d'àncora a cada camp amb error.

El bloqueig de pagaments és inusual perquè sovint es lliura mitjançant un iframe de tercers incrustat: Stripe Elements, Braintree Hosted Fields, un complement d'Adyen. Dins de l'iframe, el formulari del proveïdor de pagaments sol estar ben etiquetat. Però en el moment en què un lloc web crea la seva pròpia captura de targeta o envolta els camps incrustats en un disseny personalitzat que anul·la les etiquetes amb marcadors de posició visuals, els quatre camps (número, caducitat, CVV, codi postal) es converteixen en una fila d'entrades en blanc per a un lector de pantalla.

El camp CVV és el que s'etiqueta incorrectament amb més freqüència perquè els dissenyadors solen substituir-ne l'etiqueta per una icona de signe d'interrogació que obre una descripció emergent que explica què és un CVV. La descripció emergent no és l'etiqueta; el camp encara necessita un nom programàtic. Quan no en té cap, el lector de pantalla anuncia tot el bloc de pagament com a "edita, edita, edita, edita" i la transacció s'atura.

Si feu servir una integració de camps allotjats de tercers, seguiu les directrius d'accessibilitat del proveïdor: la majoria proporcionen una manera documentada d'etiquetar els camps des de fora de l'iframe. Si creeu una captura de targeta personalitzada, cada entrada necessita una informació real. <label> element amb una etiqueta de text visible, a més autocomplete="cc-number" / cc-exp" / cc-csc" atributs perquè els gestors de contrasenyes i els tècnics d'assistència puguin identificar els camps per la seva finalitat.

La pàgina del carretó repeteix l'error del control de quantitat PDP, però amb un risc més elevat: un usuari de lector de pantalla que no pot fer funcionar el control no pot completar la comanda. El control "Elimina" és el seu propi antipatró: normalment és una petita icona × al costat de cada element de línia, sovint sense text visible, sense... aria-label, i no hi ha cap avís quan s'elimina la fila. L'usuari prem el que espera que sigui el botó d'eliminar, la fila desapareix i el lector de pantalla roman en silenci. No hi ha manera de confirmar que l'acció s'ha realitzat correctament.

Diverses queixes descriuen un mode d'error relacionat: el total acumulat del carretó s'actualitza dinàmicament quan les quantitats canvien o s'eliminen articles, però el nou total es representa com a text DOM normal fora de qualsevol regió activa, de manera que l'usuari no té ni idea de quant se li cobrarà.

Cada element de línia hauria de mostrar un botó d'eliminació etiquetat (per exemple, "Remove Blue T-Shirt, size M, from cart"). Els quantifiadors graduals haurien d'anunciar el seu valor actual com a part del nom accessible o mitjançant actualitzacions de regió en directe aparellades. El subtotal del carretó hauria d'estar dins d'un aria-live="polite" regió perquè s'anunciïn els canvis. Confirma les eliminacions amb una affordance de desfer.

Aquesta és la categoria individual més gran del conjunt de dades perquè és el problema de menor cost de detectar i el de més cost d'ignorar. Un lector de pantalla recorre el DOM, arriba a un <input>, i llegeix el seu nom accessible, a partir del qual calcula, en l'ordre següent: aria-labelledby, aria-label, un associat <label for>, el title atribut o el marcador de posició. Si no n'hi ha cap, el lector de pantalla només anuncia el rol: "quadre d'edició" o "edició, en blanc". Aquesta frase, gairebé literalment, es repeteix en centenars de registres de queixes.

La raó per la qual és tan comú és estructural. Els sistemes de disseny moderns sovint representen text de marcador de posició dins de l'entrada com a substitut de l'etiqueta visible, i els desenvolupadors assumeixen que el marcador de posició fa la feina d'etiquetatge. No és així. El marcador de posició desapareix quan l'usuari escriu, no deixa cap nom programàtic i fa que el camp sigui inutilitzable per a qualsevol persona que hi arribi més tard en el flux o hi torni després d'un error.

Cada control interactiu rep una etiqueta visible, associada programàticament. <label for="email">Email</label><input id="email" type="email"> és el patró canònic. Els marcadors de posició són pistes suplementàries, no substituts. Per a controls on una etiqueta visible no és realment desitjable (quadres de cerca, botons d'icona), utilitzeu aria-label amb text descriptiu — mai amb el marcador de posició duplicat.

La frase "no anunciat ni donat focus" apareix literalment en més de 400 entrades de queixes i és una de les frases més replicades de tot el conjunt de dades. Descriu un mode d'error específic: apareix un modal o un diàleg a la pàgina (sovint automàticament: subscripció al butlletí, control d'edat, confirmació d'ubicació), el contingut visible canvia, però el lector de pantalla no rep cap senyal que res hagi canviat. El focus roman a la pàgina subjacent. L'usuari continua navegant per la pantalla que hi havia sota el modal, sense saber gens que ha aparegut un diàleg de bloqueig.

Aquest és el cas de manual d'un modal que falla en totes les dimensions simultàniament: no role="dialog", no aria-modal="true", sense canvi de focus programàtic en obrir, sense trampa de focus mentre està obert, sense comportament Esc per tancar, sense títol anunciat. Com que tots aquests errors viatgen junts, solucionar-ne qualsevol de forma aïllada no fa moure el mesurador de casos.

Utilitzeu un patró de diàleg establert (l'especificació de pràctiques d'autor WAI-ARIA és la referència). En obrir: moveu el focus al primer element enfocable dins del diàleg, definiu aria-modal="true" i role="dialog", etiqueta el diàleg amb aria-labelledby apuntant al seu encapçalament. Mentre està obert: atrapa el focus dins del diàleg. En tancar: retorna el focus a l'element que l'ha activat. Respecta la tecla Esc. Si el modal interromp un flux (per exemple, reproducció automàtica en carregar la pàgina), dóna a l'usuari un únic mecanisme per tancar-lo permanentment.

Els indicadors de focus solen ser eliminats deliberadament per un desenvolupador o dissenyador que va veure el contorn predeterminat del navegador com a soroll visual i va escriure *:focus { outline: none; } en un full d'estil global. La pàgina ara es veu més neta per a un usuari de ratolí vident. Per a un usuari de teclat vident (inclosos la majoria d'usuaris amb baixa visió, usuaris amb discapacitat motora i usuaris que naveguen sense ratolí), la pàgina esdevé inutilitzable. L'usuari pot prémer Tabulador, però no pot veure on es troba.

Aquest és un dels pocs modes d'error que és visible sense cap tecnologia assistiva. Un revisor de QA que prem la tecla de tabulació per la pàgina d'inici una vegada, sense cap altra eina, ho detectarà en menys d'un minut. Que els equips d'accessibilitat ho trobin de manera consistent en llocs web litigats, mentre que la revisió interna no ho hagi fet, és un dels senyals més fiables del conjunt de dades que el lloc web no ha superat cap prova de teclat.

Mai desactivació general :focus contorns sense reemplaçament. Proporcioneu un estil de focus visible (normalment un contorn de 2-3 px amb prou contrast respecte a l'element i el seu fons) utilitzant :focus-visible de manera que l'indicador apareix per a la navegació del teclat però no per als clics del ratolí. Verifiqueu-ho a tots els components interactius, inclosos els widgets personalitzats, els enllaços dins de les targetes i els elements amb tabindex.

El logotip és la imatge més visitada d'un lloc web i una de les que no funciona correctament. Normalment es troba en un enllaç que el retorna a la pàgina d'inici, però la imatge s'envia sense cap... alt, no aria-label a l'enllaç i sense text al seu voltant. El lector de pantalla només anuncia "enllaç", sense informació sobre on va a parar. Multipliqueu per cada pàgina del lloc.

La categoria més àmplia (imatges sense text alternatiu) inclou bàners, fotos de productes, il·lustracions de personatges destacats, glifs d'icones socials i el vast catàleg d'imatges de màrqueting que envia un lloc web comercial típic. Les queixes d'aquesta categoria sovint citen noms de fitxers d'imatges específics, cosa que indica que l'expert del demandant va realitzar una comprovació automatitzada que enumerava totes les imatges de les quals... alt L'atribut faltava o era buit quan hauria d'haver estat descriptiu.

Els logotips han de portar text alternatiu que descrigui el nom de l'empresa i, si el logotip enllaça a algun lloc, la destinació. alt="Acme Co. — homepage". Les imatges decoratives reben un atribut alt buit (alt=""), que les amaga deliberadament de la tecnologia assistiva. Les imatges informatives reben text alternatiu descriptiu. Eviteu generar automàticament text alternatiu a partir de noms de fitxer o subtítols d'IA sense revisió humana; els registres de queixes citen repetidament casos en què les eines de superposició van subtitular el logotip d'una empresa com a "un rètol blau i groc".

Els lectors de pantalla mostren una vista de "llista d'enllaços", molt utilitzada pels usuaris experimentats per escanejar una pàgina en segons. Aquesta vista només mostra el text de l'enllaç, separat del paràgraf que l'envolta. Una pàgina on cada avançament del bloc acaba en "Llegir més" es renderitza a aquesta vista com quinze entrades idèntiques. Una pàgina amb cinc enllaços buits — <a href="..."></a>, habitual quan les icones es troben dins de contenidors d'enllaços sense cap text de reserva: mostra cinc espais en blanc.

La solució és ben coneguda i l'error és ben conegut, i és per això que aquest patró continua apareixent a les queixes: la seva persistència indica un procés de desenvolupament sense linter automatitzat per al text de l'enllaç i sense una passada manual del lector de pantalla.

Cada enllaç ha de tenir un nom accessible que descrigui la seva destinació o acció. Substitueix les frases genèriques per descriptives. "Llegir més" esdevé "Més informació sobre els resultats del tercer trimestre"Per a enllaços només d'icones, afegiu text visualment ocult o un aria-labelExecuteu una comprovació automatitzada (destral, Lighthouse, etc.) per veure si hi ha espai buit. <a> elements durant la CI.

El vídeo apareix a les queixes en dos patrons. El primer és l'obvi: un vídeo de màrqueting, una demostració de producte o una explicació s'envia sense subtítols, transcripció ni cap alternativa de text, i un visitant sord o amb dificultats auditives no pot accedir al contingut. El segon és més subtil: un vídeo estrella que es reprodueix automàticament en carregar la pàgina, cosa que interfereix amb la sortida del lector de pantalla i viola els controls de pausa/aturada esperats al nivell WCAG 2.2 AA (segons SC 2.2.2 Pausa, Atura, Amaga per a contingut en moviment i SC 1.4.2 per a qualsevol àudio).

Algunes queixes d'aquest conjunt de dades afirmen que "la manca de subtítols als vídeos dels llocs web és una violació de l'ADA", emmarcat com una conclusió legal. El fet que aquest emmarcament es compleixi varia segons la jurisdicció i les circumstàncies; el que és més persistent és que aquests vídeos incompleixen sistemàticament la WCAG 2.2 AA, l'estàndard que la majoria de tribunals i acords de conciliació tracten com a referència de compliment operatiu.

Proporcioneu subtítols sincronitzats per a tots els vídeos pregravats amb àudio. Proporcioneu també una transcripció de text; les transcripcions són útils per a usuaris en dispositius silenciats, en entorns de baixa amplada de banda i per a la indexació. Eviteu la reproducció automàtica; si la reproducció automàtica és necessària per motius de disseny, proporcioneu un control de pausa/aturada immediatament accessible amb el teclat. Per al contingut només de vídeo (sense àudio), proporcioneu una descripció d'àudio o una alternativa de text.

L'inici de sessió és el guardià de tota l'experiència d'autenticació. Quan el formulari falla, totes les pàgines que hi ha darrere esdevenen inaccessibles i les queixes sovint tracten aquesta cascada com una única barrera. El patró és el mateix error d'etiquetatge de formularis que l'E·01, sovint combinat amb tres suberrors específics: un botó d'activació/desactivació "Mostra la contrasenya" implementat com un botó només d'icona sense nom i sense anunci de canvi d'estat, un CAPTCHA que impedeix completament l'ús del lector de pantalla i errors en línia ("credencials no vàlides") que es mostren a la pantalla però no s'anuncien.

La casella de selecció "recorda'm" és un altre suberror recurrent: renderitzat com a estilitzat <div>, amb el real <input> Oculta fora de la pantalla, la casella de selecció es pot utilitzar amb el ratolí però no amb el teclat ni amb el lector de pantalla. L'usuari no té cap manera d'optar per a una sessió persistent.

Utilitza real <input>, <label>, i <button> elements. Feu que el botó d'activació/desactivació de la contrasenya sigui real amb un nom accessible que s'actualitzi amb l'estat ("Show password" / "Hide password") i anunciar el canvi amb aria-pressedProporcionar una alternativa accessible als CAPTCHA basats en imatges (CAPTCHA d'àudio o, preferiblement, substituir el CAPTCHA per l'autenticació basada en el risc o les variants accessibles de l'hCaptcha).

Els lectors de pantalla exposen la pàgina a través de tres modes de navegació: per encapçalament, per punt de referència i per enllaç. Una pàgina que es lliura sense un <h1>, sense <main>, <nav>, i <footer> punts de referència, i sense un lang="en" atribut a la <html> element, ha eliminat aquests tres modes de navegació simultàniament. Els usuaris no tenen manera d'escanejar, ni de saltar al contingut, ni de carregar el lector de pantalla amb el motor de pronunciació correcte.

Aquest és un error generatiu inusual: un únic punt de referència perdut provoca una cascada de queixes posteriors perquè totes les estratègies de navegació amb lector de pantalla que en depenen fallen ara. Les queixes d'aquesta categoria solen enumerar quatre o cinc problemes estructurals específics junts, presentats com a prova que el lloc web no té una línia de base semàntica.

Cada pàgina en rep una i només una <h1>, amb subtítols (<h2>, <h3>) imbricats lògicament. Embolica les regions en elements de referència HTML5: <header>, <nav>, <main>, <aside>, <footer>. Conjunt lang a l'arrel <html> element. Valideu amb un corrector d'esquemes o executeu document.querySelectorAll('h1').length === 1 com a prova de fum en CI.

La majoria del control de qualitat de l'accessibilitat es fa en navegadors d'escriptori amb NVDA o JAWS. La tecnologia d'assistència mòbil (VoiceOver a iOS, TalkBack a Android) exposa una representació diferent del mateix DOM, sovint amb errors diferents. Les queixes utilitzen repetidament l'abreviatura "mobile SRU" (usuari de lector de pantalla mòbil) per marcar errors que són exclusius de la vista mòbil: un menú hamburguesa que funciona amb NVDA a l'escriptori però que és silenciós amb VoiceOver, un botó d'Apple Pay accessible en un portàtil però no a l'equivalent de la pàgina per a iPhone, missatges d'error que anuncien a l'escriptori però no al mòbil.

El conjunt de dades suggereix que els demandats, l'accessibilitat dels quals a l'escriptori és, per altra banda, sòlida, encara estan sent demandats per qüestions específiques dels dispositius mòbils. La paritat mòbil és el seu propi passi d'auditoria.

Proveu amb VoiceOver a iOS Safari i TalkBack a Android Chrome com a mínim, en els mateixos fluxos que cobreix el control de qualitat de l'escriptori. Presteu especial atenció a les interaccions basades en gestos, els botons de pagament natius i l'anunci del camp de formulari en el focus. Si existeix una aplicació nativa, feu-la passar per la mateixa auditoria; les queixes sovint cobreixen tant el web com l'aplicació en el mateix cas.

La capa d'accessibilitat és l'única mostra d'aquest catàleg on l'error no es troba en absolut al lloc web subjacent, sinó a la suposada capa de remediació que es va afegir per solucionar-lo. Les queixes d'aquesta categoria descriuen dos danys diferents. El primer és que les capes en realitat no solucionen les barreres subjacents, de manera que l'usuari es troba amb els mateixos modals trencats, formularis mal etiquetats i errors no anunciats independentment de si el widget és present. El segon és més greu: les capes de vegades introdueixen nous errors injectant etiquetes incorrectes, aplicant malament rols ARIA o interferint amb la configuració de la tecnologia assistiva de l'usuari.

Un detall que val la pena destacar: les queixes del 2024 i el 2025 citen cada cop més el proveïdor de la capa superior pel seu nom. Dos passatges específics de les queixes identifiquen UserWay i AccessiBe en un llenguatge inequívoc, i les accions recents de la FTC han creat un risc explícit que afegir una capa superior sigui en si mateixa una prova d'un fracàs a l'hora de fer un treball de remediació real, en lloc d'una defensa contra litigis.

Tracteu les superposicions com una bandera, no com una solució. Si ja n'hi ha una implementada, planifiqueu una guia de correcció real que abordi el codi subjacent en lloc d'emmascarar-lo. La ruta ben provada és una combinació de: un escàner automatitzat integrat a la CI, una auditoria humana passada contra les WCAG 2.2 AA, proves manuals amb almenys un lector de pantalla i navegació només amb teclat, i un control de qualitat de l'accessibilitat continu en el procés de disseny i enginyeria.