Errors d'accessibilitat habituals que cal evitar

Per què apareixen una vegada i una altra els mateixos problemes d’accessibilitat

La majoria de les barreres d’accessibilitat no són exòtiques. Any rere any, les auditories automàtiques i manuals fan aflorar la mateixa llista breu d’errors: text alternatiu absent, contrast baix, camps de formulari sense etiqueta, trampes de teclat i estructura trencada. Es repeteixen perquè s’introdueixen en silenci — un desenvolupador publica un component nou, un responsable de màrqueting puja una imatge, un dissenyador tria un color de marca — i res en el flux de treball normal no marca el problema. El resultat visual sembla correcte per a algú que utilitza un ratolí i té bona vista, així que la barrera es publica.

Aquest catàleg recorre els incompliments més freqüents de WCAG 2.2 que veiem en auditories reals. Per a cadascun hi trobaràs per què importa, a qui afecta, el criteri d’èxit corresponent i una solució concreta abans/després. En conjunt, aquests problemes representen la immensa majoria de les barreres que bloquegen els usuaris amb discapacitat — i la immensa majoria de les queixes legals presentades en virtut de la Llei Europea d’Accessibilitat, l’ADA i la Section 508.

Una cosa que cal aclarir abans de la llista: les eines automàtiques no poden detectar tots aquests problemes. La recerca independent mostra de manera coherent que fins i tot els millors escàners només detecten de manera fiable el 30–40% dels problemes de WCAG. Són excel·lents per detectar atributs alt absents, incompliments de contrast programàtics i etiquetes de formulari inexistents, però no poden jutjar si el text alternatiu és exacte, si l’ordre de focus és lògic o si un giny personalitzat realment funciona amb un lector de pantalla. Per això tot programa creïble combina l’escaneig amb la revisió manual. El nostre programari d’escaneig d’accessibilitat s’encarrega de la capa automatitzable; les auditories manuals i les auditories fetes per persones amb discapacitat cobreixen la resta.

Una manera ràpida de trobar el teu propi punt de partida abans de continuar llegint: visualitza la pàgina amb les imatges desactivades, llegeix cada paraula com un sol paràgraf sense estructura i prova de completar cada tasca utilitzant només el teclat. Allà on l’experiència s’enfonsi, hauràs trobat una barrera.

Perceptible: contingut que la gent no pot veure ni llegir

Text alternatiu absent o inexacte per a les imatges

A qui afecta: persones cegues o amb baixa visió que utilitzen lectors de pantalla; qualsevol persona amb una connexió lenta on les imatges no es carreguen.

Criteri WCAG: 1.1.1 Contingut no textual (Nivell A).

Les imatges sense un atribut alt són invisibles per a la tecnologia d’assistència — l’usuari potser ni tan sols sap que la imatge existeix. Pitjor que un atribut absent és un d’inexacte: noms de fitxer com IMG_4821.jpg, paraules genèriques com «imatge» o cadenes plenes de paraules clau enganyen activament l’oient.

La regla és senzilla però depèn de la situació. Les imatges informatives necessiten una descripció concisa del seu significat, no de la seva aparença. Les imatges decoratives que no aporten res han de portar un alt="" buit perquè els lectors de pantalla les ometin. Les imatges funcionals — una icona que actua com un botó — han de descriure l’acció, no la imatge. Els elements visuals complexos com els gràfics necessiten un alt curt més un equivalent textual més llarg a prop.

<!-- Before: useless, misleading -->
<img src="chart-final-v2.png">

<!-- After: meaningful for an informative image -->
<img src="chart-final-v2.png"
     alt="Revenue grew 24% between Q1 and Q4 2025">

<!-- After: decorative image, correctly hidden -->
<img src="divider-flourish.svg" alt="">

Les eines automàtiques detecten l’absència de text alternatiu a l’instant. No et poden dir si el text és correcte — això requereix una persona que llegeixi la pàgina en context.

Contrast de color insuficient

A qui afecta: persones amb baixa visió, daltonisme o pèrdua de visió relacionada amb l’edat; tothom que utilitzi una pantalla amb llum solar intensa.

Criteri WCAG: 1.4.3 Contrast (mínim), Nivell AA; més 1.4.11 Contrast no textual per a components d’interfície.

WCAG 2.2 requereix una relació de contrast d’almenys 4.5:1 per al text normal i 3:1 per al text gran (aproximadament 18pt, o 14pt en negreta). Els components d’interfície i els gràfics significatius — vores de camps, indicadors de focus, icones que transmeten un estat — han de complir el 3:1 respecte al seu entorn. Els incompliments de contrast es troben entre els problemes més habituals en tota auditoria a gran escala, i gairebé sempre s’introdueixen en l’etapa de disseny.

/* Before: light gray on white = 2.8:1, fails AA */
.helper-text { color: #9a9a9a; background: #ffffff; }

/* After: 4.6:1, passes AA */
.helper-text { color: #717171; background: #ffffff; }

Prova tota la paleta, no només el cos del text: el text de marcador de posició (placeholder), els estats deshabilitats que encara s’han de poder llegir, els missatges d’error i el text sobre fotografies són infractors freqüents. No confiïs mai només en el color per transmetre significat (1.4.1) — una vora vermella en un camp no vàlid s’ha d’acompanyar de text o una icona.

Contingut multimèdia i moviment que es reprodueixen automàticament

A qui afecta: persones amb trastorns vestibulars, discapacitats d’atenció o cognitives, usuaris de lectors de pantalla la sortida d’àudio dels quals queda ofegada, i qualsevol persona en un espai compartit tranquil.

Criteris WCAG: 1.4.2 Control d’àudio (Nivell A), 2.2.2 Posar en pausa, aturar, amagar (Nivell A), 2.3.1 Tres parpellejos (Nivell A) i 2.3.3 Animació a partir d’interaccions (Nivell AAA).

L’àudio o el vídeo que es reprodueix automàticament durant més de tres segons ha d’oferir una manera evident de posar-lo en pausa o silenciar-lo. El contingut en moviment, parpellejant o que s’actualitza automàticament i que dura més de cinc segons — carrusels, bàners animats, marquees — necessita un control de pausa accessible. El contingut que parpelleja més de tres vegades per segon pot provocar atacs epilèptics i s’ha d’evitar completament. Respecta la configuració prefers-reduced-motion de l’usuari per atenuar l’animació no essencial.

/* After: honour the user's OS-level motion preference */
@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

Operable: coses que la gent no pot utilitzar

Inaccessibilitat de teclat i trampes de teclat

A qui afecta: persones amb discapacitats motrius que no poden utilitzar un ratolí, usuaris de lectors de pantalla (que naveguen amb el teclat) i persones que utilitzen dispositius de commutació o control per veu.

Criteris WCAG: 2.1.1 Teclat (Nivell A) i 2.1.2 Sense trampa de teclat (Nivell A).

Cada interacció — enllaços, botons, camps de formulari, menús, modals, selectors de data, arrossegar i deixar anar — ha de ser totalment operable només amb el teclat. La variant més perjudicial és la trampa de teclat: el focus entra en un component (sovint un modal o un giny incrustat) i no en pot sortir, deixant l’usuari atrapat a la pàgina. Els ginys creats a mida solen ser els culpables perquè els elements natius com <button> i <a> són operables amb el teclat per defecte, mentre que les imitacions basades en <div> no ho són.

<!-- Before: not focusable, not operable by keyboard -->
<div class="btn" onclick="submit()">Submit</div>

<!-- After: native element, free keyboard support -->
<button type="submit">Submit</button>

Recorre els teus trajectes clau utilitzant només Tab, Maj+Tab, fletxes, Retorn, Espai i Escapada. Confirma que el focus sempre pot avançar i sortir de cada component, que Escapada tanca les superposicions i que res no requereix un punter. El nostre servei d’avaluació amb lector de pantalla prova exactament aquests fluxos tal com els experimenten els usuaris reals de tecnologia d’assistència.

Indicadors de focus absents o invisibles i ordre de focus il·lògic

A qui afecta: usuaris de teclat amb visió, usuaris amb baixa visió i qualsevol persona que hagi perdut la noció d’on es troba a la pàgina.

Criteris WCAG: 2.4.7 Focus visible (Nivell A) i 2.4.3 Ordre de focus (Nivell A); 2.4.11 Focus no ocult (Nivell AA) a WCAG 2.2.

Un error «polit» habitual és eliminar l’anell de focus per defecte del navegador amb outline: none i no substituir-lo mai. Els usuaris de teclat es queden sense saber quin element està actiu. Igual de perjudicial és un ordre de focus que no segueix l’ordre de lectura visual i lògic — normalment causat per valors tabindex positius o per un ordre del DOM que divergeix de la disposició renderitzada.

/* Before: focus ring deleted, keyboard users lost */
:focus { outline: none; }

/* After: a clear, high-contrast indicator */
:focus-visible {
  outline: 3px solid #0b5cff;
  outline-offset: 2px;
}

WCAG 2.2 afegeix el 2.4.11: quan un element rep el focus, no ha d’estar completament amagat darrere de capçaleres fixes, bàners de galetes o ginys de xat. Obre un modal, recorre’l amb el tabulador i confirma que l’element enfocat no queda mai amagat.

Enllaços i botons no descriptius

A qui afecta: usuaris de lectors de pantalla que generen una llista de tots els enllaços per explorar una pàgina, i persones amb discapacitats cognitives.

Criteris WCAG: 2.4.4 Propòsit de l’enllaç (en context), Nivell A; 2.5.3 Etiqueta en el nom, Nivell A.

Els usuaris de lectors de pantalla sovint naveguen saltant entre enllaços fora de context. Una pàgina plena d’enllaços «fes clic aquí», «llegeix-ne més» i «més informació» es torna sense sentit quan es llegeix com una llista. El text de l’enllaç ha de descriure la seva destinació per si mateix. El mateix s’aplica als botons només amb icona, que necessiten un nom accessible.

<!-- Before: ambiguous out of context -->
<a href="/resources/wcag">Read more</a>

<!-- After: self-describing -->
<a href="/resources/wcag">Read our WCAG 2.2 compliance guide</a>

<!-- Icon button with an accessible name -->
<button aria-label="Close dialog">
  <svg aria-hidden="true">…</svg>
</button>

Navegació sobrecarregada i sense manera d’ometre-la

A qui afecta: usuaris de lectors de pantalla, usuaris de teclat i persones amb discapacitats cognitives.

Criteri WCAG: 2.4.1 Ometre blocs (Nivell A).

Un mega-menú amb desenes d’enllaços obliga els usuaris de lectors de pantalla i de teclat a travessar tota la llista a cada pàgina abans d’arribar al contingut. Un enllaç «Vés al contingut principal» com a primer element enfocable els permet saltar directament més enllà dels blocs repetits. Agrupa els elements relacionats, mantén els menús lleugers i assegura’t que l’enllaç d’ometre es faci visible en rebre el focus.

<!-- After: first focusable element on the page -->
<a class="skip-link" href="#main">Skip to main content</a>
…
<main id="main">…</main>

Comprensible: contingut que confon

Camps de formulari sense etiqueta o associats incorrectament

A qui afecta: usuaris de lectors de pantalla, persones amb discapacitats cognitives i usuaris de control per veu que es dirigeixen als camps pel nom.

Criteris WCAG: 1.3.1 Informació i relacions, 3.3.2 Etiquetes o instruccions i 4.1.2 Nom, funció, valor (tots Nivell A).

Els camps d’entrada sense una <label> associada programàticament s’anuncien com «edita text, en blanc» — l’usuari no té ni idea de què escriure. El text de marcador de posició (placeholder) no és un substitut: desapareix en escriure i normalment no compleix el contrast. Els camps obligatoris, les regles de format i els errors de validació també s’han de transmetre amb text, no només amb color o posició.

<!-- Before: placeholder masquerading as a label -->
<input type="email" placeholder="Email">

<!-- After: explicit, associated label + described error -->
<label for="email">Email address</label>
<input type="email" id="email"
       aria-describedby="email-err" aria-invalid="true">
<p id="email-err">Enter a valid email, e.g. name@example.com</p>

Vincula els missatges d’error al seu camp amb aria-describedby, marca els camps no vàlids amb aria-invalid i assegura’t que enviar un formulari incomplet mou el focus al primer error.

Idioma de la pàgina absent

A qui afecta: usuaris de lectors de pantalla — l’idioma incorrecte fa que el sintetitzador pronunciï tot malament.

Criteris WCAG: 3.1.1 Idioma de la pàgina (Nivell A) i 3.1.2 Idioma de les parts (Nivell AA).

Un sol atribut absent trenca la pronunciació de tota una pàgina. Declara l’idioma principal a l’element arrel i marca els passatges en línia en un altre idioma amb el seu propi lang.

<!-- Before -->
<html>

<!-- After -->
<html lang="en">
  …
  <blockquote lang="fr">Le client a raison.</blockquote>

Jerarquia d’encapçalaments incorrecta i regions de referència absents

A qui afecta: usuaris de lectors de pantalla que naveguen per encapçalaments i regions, i qualsevol persona que depengui de l’estructura del document.

Criteri WCAG: 1.3.1 Informació i relacions (Nivell A).

Els encapçalaments són l’esquema de la pàgina. Els usuaris de lectors de pantalla salten d’encapçalament a encapçalament per trobar el contingut ràpidament; quan se salten nivells, s’utilitzen purament per a la mida de la lletra o no hi són, aquesta navegació s’enfonsa. Cada pàgina ha de tenir un <h1> i una seqüència lògica i ininterrompuda de <h2>, <h3>, etcètera. Igual d’importants són les regions de referència — <header>, <nav>, <main>, <footer> — que permeten als usuaris saltar entre les àrees principals. Una pàgina construïda íntegrament amb elements <div> no ofereix cap mapa d’aquest tipus.

<!-- After: semantic landmarks + ordered headings -->
<header>…</header>
<nav aria-label="Primary">…</nav>
<main>
  <h1>Common accessibility issues</h1>
  <h2>Perceivable</h2>
    <h3>Missing alt text</h3>
</main>
<footer>…</footer>

Robust: codi que la tecnologia d’assistència no pot interpretar

Ginys personalitzats inaccessibles i ús incorrecte d’ARIA

A qui afecta: sobretot els usuaris de lectors de pantalla, i qualsevol tecnologia d’assistència que depengui d’un arbre d’accessibilitat correcte.

Criteri WCAG: 4.1.2 Nom, funció, valor (Nivell A).

Els menús desplegables, pestanyes, acordions, quadres combinats, modals i descripcions emergents personalitzats construïts amb <div> i <span> no tenen cap funció, estat ni comportament de teclat inherents. Els desenvolupadors recorren a ARIA per pegar-ho, però ARIA només descriu — no afegeix comportament, i un ARIA incorrecte és pitjor que cap. La primera regla d’ARIA és preferir un element HTML natiu sempre que n’existeixi un. Quan hagis de construir un giny personalitzat, implementa la interacció completa de teclat que especifiquen els patrons de creació d’ARIA i mantén aria-expanded, aria-selected i estats similars sincronitzats amb la realitat.

<!-- Before: a div pretending to be a control, no role or state -->
<div class="dropdown" onclick="toggle()">Choose plan ▾</div>

<!-- After: correct role, name, and state -->
<button aria-expanded="false" aria-controls="plan-list">
  Choose plan
</button>
<ul id="plan-list" role="listbox" hidden>…</ul>

Aquests són precisament els problemes que els escàners automàtics passen per alt més sovint. Un escàner veu un atribut aria-expanded i l’aprova; només una persona (o un provador que utilitza un lector de pantalla) pot confirmar que el valor realment canvia quan s’obre el menú. Consulta la nostra guia de proves amb lector de pantalla per saber com verificar el comportament d’un giny de cap a cap.

Una nota sobre els ginys de superposició (overlay)

És temptador instal·lar un «giny d’accessibilitat» o superposició d’una sola línia que promet conformitat instantània. Aquestes eines no solucionen els problemes anteriors — el text alternatiu continua absent a l’origen, el contrast continua fallant, el giny personalitzat continua sense funcionar. Les superposicions no poden esmenar el codi que causa les barreres, sovint interfereixen amb la pròpia tecnologia d’assistència dels usuaris i han aparegut en un nombre creixent de demandes per accessibilitat. La accessibilitat digital real prové de solucionar l’HTML, el CSS i el comportament subjacents, no d’emmascarar-los.

Atura el retorn d’aquests problemes

Solucionar una llista d’errors una vegada és necessari però no suficient; els mateixos problemes reapareixen amb la propera versió tret que canviïs com es publiquen les coses. La solució duradora és incorporar l’accessibilitat al flux de treball:

Detecta aviat el 30–40% automatitzable integrant escanejos al teu pipeline. La integració d’accessibilitat CI/CD fa fallar la compilació quan s’introdueix una regressió, abans que arribi a producció.
Cobreix la resta amb persones. Programa auditories d’accessibilitat manuals i auditories fetes per persones amb discapacitat, que fan aflorar barreres que cap eina pot detectar.
Dona als equips els instruments adequats. El conjunt d’eines d’accessibilitat de QualiBooth i Agora ajuden dissenyadors i desenvolupadors a fer proves mentre treballen.
Fes-ne un procés, no un projecte. La consultoria d’accessibilitat contínua i la millora del procés d’accessibilitat arrelen els hàbits perquè la qualitat es mantingui amb el temps.

Per a un full de ruta de correcció pas a pas, comença amb la nostra guia sobre com fer el teu lloc web conforme a WCAG.

Per on començar avui

Amb més de 1.300 milions de persones a tot el món que viuen amb alguna forma de discapacitat, l’argument empresarial a favor de l’accessibilitat és clar — i des del juny de 2025, l’argument legal en virtut de la Llei Europea d’Accessibilitat també ho és. Els problemes d’aquest catàleg són els que s’examinen primer en qualsevol queixa o auditoria.

La manera més ràpida de veure on et trobes és executar un escaneig d’URL gratuït — sense configuració, sense compromís. Quan estiguis a punt per anar més enllà del que pot arribar l’automatització, demana una demostració i et mostrarem com un programa combinat d’automatització i revisió manual tanca la bretxa restant.