--- title: "Más vale ARIA que fuerza" id: "1347" type: "post" slug: "mas-vale-aria-que-fuerza" published_at: "2026-08-06T10:26:45+00:00" modified_at: "2026-08-06T10:26:46+00:00" url: "https://www.guindo.com/blog/ca/mas-vale-aria-que-fuerza/" markdown_url: "https://www.guindo.com/blog/ca/mas-vale-aria-que-fuerza.md" excerpt: "En 2026 escribimos más código etiquetado como «accesible» que nunca, pero publicamos una web objetivamente peor. El último censo de WebAIM deja un dato demoledor: el uso de atributos ARIA se ha disparado un 27% en un año, mientras que..." taxonomy_category: - "Diseño" taxonomy_post_tag: - "accesibilidad" - "diseño" --- [← Blog](https://www.guindo.com/blog/ca/) de **[Guindo Design](https://www.guindo.com/blog/ca/)**, Disseny Estratègic de Producte Digital # Més val ARIA que força 6 ag., 2026, *per* Sergi. Cada febrer, [WebAIM](https://webaim.org/projects/million/) , un centre d'investigació en accessibilitat de la Universitat Estatal de Utah, analitza el milió de pàgines d'inici més visitades d'internet i publica quantes hi fallen. Des de fa 8 anys, és el cens més gran que tenim per saber com està l'accessibilitat en el món real. L'informe del 2026 aporta dues dades que convé llegir juntes. El primer: **El 95,91 % de les pàgines tenen problemes d'accessibilitat detectables automàticament.**, gairebé un punt més que l'any anterior. El nombre d'errors per pàgina va passar de 51 a 56,1, un augment del 101 TP3T. Després de sis anys de petites però constants millores, la tendència s'ha invertit. El segon explica bastant millor el que està passant. WebAIM va comptar 133 milions d'atributs ARIA, uns 133 per pàgina. ARIA (sigles de *Aplicacions d'Internet riques i accessibles*) és un conjunt d'atributs que s'afegeixen a l'HTML per explicar a un lector de pantalla el que és un element quan el mateix HTML no ho diu: que aquest `div` és un botó, que aquest panell és un diàleg o que aquest text és una alerta. **Va créixer un 271 TP3T en un sol any, i ara n'hi ha sis vegades més que el 2019.** Així doncs, en el mateix any hem escrit més codi per millorar l'accessibilitat que mai abans, però hem llançat un lloc web que és menys accessible que el de l'any passat. ## El fet incòmode Podem desglossar-ho encara més. Les pàgines que utilitzen ARIA tenen una mitjana de 59,1 errors, en comparació amb 42 per a les que no ho fan. I la tendència és progressiva: **com més atributs ARIA té una pàgina, més errors se li detecten.** Això no vol dir que l'atribut ARIA sigui incorrecte; vol dir que s'està utilitzant sense els criteris necessaris perquè funcioni. Per exemple, un `aria-label` en un element que ja tenia un nom correcte: ara el lector de pantalla anuncia el text de l'atribut i no el que es veu a la interfície, així que qui ho escolta sent una cosa diferent de la que hi ha a la pantalla. O un `role="button"` en un `div`, que anuncia un botó encara que l'element segueixi sense poder activar-se amb el teclat, la qual cosa incompleix el [Criterio 2.1.1 sobre el teclat](https://jeikin.com/wcag/2-1-1-keyboard) semblava que hagués estat arreglat. O un `aria-hidden="true"` s'utilitza per amagar una icona decorativa que acaba aplicant-se a tot el contenidor, cosa que fa que el missatge d'error que hi ha dins ja no sigui visible per a aquells que no el poden veure. Cadascun d'aquests atributs representa una promesa trencada feta a l'usuari del lector d' pantalla. **La**[primera regla d'ARIA](https://www.w3.org/TR/using-aria/#rule1) **, segons el que han escrit els seus dissenyadors, no s'ha d'utilitzar ARIA.** Si existeix un element HTML que ja fa el que necessites, aquest element és la resposta. Doncs bé, aquesta regla s'està incomplint 133 milions de vegades. Res d'això no és un descobriment recent. [Andy Carter ja ho havia explicat el 2024.](https://andycarter.dev/blog/why-aria-label-can-be-bad-for-accessibility) , amb l'informe WebAIM d'aquell any a mà: les pàgines que utilitzaven ARIA tenien un 34,21 % més d'errors detectats que les que no ho feien, i vaig revisar, una per una, les maneres en què un `aria-label` Mal posat trenca coses que funcionaven. Dos anys després aquesta escletxa no s'ha tancat, s'ha eixamplat. ## D'on ha sortit tot aquest ARIA WebAIM assenyala dues causes i no té por de nomenar-les: les pàgines web s'estan tornant cada cop més complexes (un augment del 22,51 % en el nombre d'elements en un any) i hi ha una dependència més gran dels frameworks de tercers i de les pràctiques de programació assistides per IA, o 'vibe coding'. Sobre això últim val la pena aturar-se, perquè el mecanisme és interessant i no és el que podem suposar en primera instància. Un model lingüístic aprèn a predir el codi més probable donat un context. Les dades amb les quals ha après són aquest lloc web: aquell que conté 951 TP3T pàgines amb errors, aquell que cobreix sis anys de `div` amb `en fer clic`, la de l'ARIA mal col·locat. Quan genera un component inaccessible no està fallant, està reproduint amb bastant fidelitat el que hi ha per aquí fora. **En altres paraules, estava molt ben entrenat en llocs molt mal dissenyats.** I hi ha alguna cosa pitjor. Un model sap que l'accessibilitat importa, perquè també ha après de la documentació, dels articles i de les xerrades on s'explica. Així que afegeix ARIA, molta ARIA, sense el criteri per saber quan sobra, quan contradita l'HTML i quan està tapant un problema en lloc de resoldre'l. El resultat és exactament el que mesura WebAIM: més atributs, més errors. A això s'afegeix que la fallada és invisible on solem mirar. Un lector de pantalla no llegeix la pantalla, llegeix [l'arbre d'accessibilitat](https://jeikin.com/blog/the-accessibility-tree-is-the-new-api) , una estructura que el navegador calcula a partir de l'HTML, el CSS i aquells atributs ARIA. Dos botons poden semblar idèntics i ser completament diferents allà sota. Una captura de pantalla no ho mostra, i una revisió visual tampoc. Quan un model multimodal revisa la seva pròpia feina mirant una imatge, està mirant l'artefacte equivocat. ## Per què això va de disseny i no només de codi Aquí és on això deixa de ser un problema d'accessibilitat, i comença a assemblar-se a una cosa que, segur que vosaltres també heu notat en el vostre flux de treball. Les parts que a priori semblaven més difícils surten ràpid amb IA. En canvi, les que portem dècades donant per sabudes s'encallen: decidir si una pantalla hauria d'existir, què passa quan no hi ha dades, si aquest cas és una excepció real o un patró que ja vam resoldre en un altre lloc, què significa exactament aquest estat per a l'usuari. Decisions de producte que costaria defensar en una revisió. Durant un temps vaig pensar que el problema era el model, que no estava prou entrenat. Així que quan em vaig asseure a escriure els criteris perquè un LLM pogués seguir-los, vaig descobrir que no estaven prou documentats. Prova a fer-ho. Agafa una decisió que prenguis en pilot automàtic, quan alguna cosa mereix una pantalla pròpia i quan és un pas dins d'una altra, i escriu la regla exacta que segueixes. No la teoria, la regla. A les tres o quatre línies acabas escrivint «depèn del context», i aquí s'acaba el document, perquè el context, la informació sobre el producte i sobre qui l'usa, és justament el que tu aportes sense adonar-te'n i la màquina no té. Ningú ens va demanar mai que escriguéssim o verbalitzéssim aquestes regles. Les vam aprendre mirant, corregint i acumulant decisions fins que les vam interioritzar. Només funciona mentre l'executor siguis tu o algun altre que hagi estat a les mateixes reunions. Els sistemes de disseny van ser el nostre intent d'arreglar-ho, i sabem com acaba: documenten bé els components i malament els criteris quan viuen a la zona grisa. **L'ARIA mal col·locat és la versió visible d'això mateix.** És un criteri a mig escriure, aplicat sense la part que no es va escriure. I com que en el cas de l'accessibilitat les regles sí que estan publicades i són comprovables, el desastre es pot mesurar. Amb la resta de les decisions de producte passa el mesmo, però no hi ha ningú comptant pàgines. Abans cada variació costava temps i diners, així que en algun moment s'acabava el pressupost i sorties amb el que tenies. La concessió era imposada pel calendari. Ara el cost de demanar una altra versió s'ha reduït molt, així que pots continuar polint indefinidament, i com que cada iteració millora una mica, mai hi ha un moment evident per parar. Així que la decisió difícil ha canviat de lloc. Ja no és com aconseguir el resultat que vull, **sió quan accepto que aquest tros queda per sota del meu estàndard i m'ocupo d'una altra cosa.** ## El que sí que es trasllada Amb l'accessibilitat, aquesta conversa no es produeix, i per això és un bon lloc per aprendre. Les regles porten escrites des de les WCAG 1.0 del 1999, numerades, amb criteris d'acceptació i amb una manera clara de comprovar si es compleixen. No he de justificar què significa un contrast suficient, ja que algú altre va fer aquesta feina fa anys, i no va ser un equip concret de producte, sinó persones que necessitaven que estigués ben fet. Quan el criteri està escrit així, es trasllada. Pots passar-li a un model el [criteri 1.4.3 sobre contrast mínim](https://jeikin.com/wcag/1-4-3-contrast-minimum) abans d'escriure una línia, i el que en surt ho compleix, perquè no hi ha res a interpretar: el llindar de contrast és un nombre. És la raó per la qual vaig començar per aquí quan vaig construir [Jeikin](https://jeikin.com/) , ja que les regles ja estaven escrites. Pel que fa a l'abast, convé ser honest. Les eines automàtiques detecten una part dels criteris, no tots, i al juliol el W3C ho va deixar per escrit al [WCAG-EM 2.0](https://jeikin.com/blog/wcag-em-2-the-official-recipe) que ninguna metodologia per si sola permet declarar que alguna cosa compleix. Però fixa't en allò que diuen els números de WebAIM: **De tots els defectes detectats, el 96% es concentra en sis tipus, que són els sis defectes mecànics més comuns.** Contrast, [text alternatiu](https://jeikin.com/wcag/1-1-1-non-text-content) , [etiquetes de formulari](https://jeikin.com/wcag/1-3-1-info-and-relationships) , enllaços buits, botons buits. Res d'això no necessita criteri de disseny. Tot això s'hauria de resoldre abans que el codi arribi a una revisió. El fet que el 2026 el 96% encara representarà la majoria de defectes, malgrat que hi hagi més eines disponibles que mai, diu alguna cosa sobre on estem centrant els nostres esforços. Hem passat els darrers dos anys preguntant-nos si això ens substituirà; he trobat més útil preguntar-me quina part del que sé fer — però que no aporta valor — puc explicar i documentar, per poder centrar-me en allò que realment importa. ## Articles relacionats - [Affordance i disseny pla: el que va perdre Gmail al seu redisseny](https://www.guindo.com/blog/ca/affordance-i-disseny-pla-gmail/) - [Jeikin: programa amb IA sense descuidar l'accessibilitat](https://www.guindo.com/blog/ca/jeikin-accesibilitat-ia/) - [Escales, formularis, arracades i ensopegades](https://www.guindo.com/blog/ca/escales-pendents-i-ensopegades/) Més entrades de [Disseny](https://www.guindo.com/blog/en/category/diseno/)