Shift-left: requisits i disseny accessibles des de l'inici

Shift-left («desplaçar a l'esquerra») significa moure les activitats de qualitat cap a les fases inicials del cicle de vida, on corregir és barat. Aplicat a l'accessibilitat, vol dir que un problema de contrast es resol a la paleta, no en producció; que un formulari es dissenya amb etiquetes visibles abans que existeixi una línia de codi; i que una història d'usuari no es dona per acabada sense els seus criteris d'acceptació d'accessibilitat. En aquesta lliçó veuràs com introduir l'accessibilitat en requisits i disseny amb plantilles i una revisió de disseny que funcioni.

Per què a l'esquerra

El cost de corregir un defecte creix de manera molt marcada segons la fase en què es detecta. Un botó amb text gris clar sobre fons blanc s'arregla al fitxer de disseny en dos minuts; en producció cal obrir una incidència, prioritzar, modificar codi, provar, desplegar i, sovint, discutir amb màrqueting sobre la identitat corporativa. Multiplica això per centenars de components i entendràs per què les organitzacions que només auditen al final no arriben mai a la conformitat: cada versió nova introdueix errors més de pressa del que es corregeixen els anteriors.

El shift-left no elimina l'auditoria final; la converteix en una confirmació en lloc d'un descobriment.

Accessibilitat en els requisits

Requisits no funcionals del producte

Tot producte digital hauria de tenir, en el document de requisits o en la definició inicial, una clàusula d'accessibilitat amb el nivell exigit (WCAG 2.2 AA; EN 301 549 (PDF, s'obre en una finestra nova) per a programari, documents i apps), les tecnologies de suport amb què es provarà (per exemple, NVDA amb Firefox i Chrome, VoiceOver a Safari i iOS, TalkBack a Android), els navegadors i les mides de finestra admesos, i com es verificarà abans de cada lliurament.

Històries d'usuari amb criteris d'acceptació

En equips àgils, la unitat de treball és la història d'usuari. La manera més eficaç d'integrar l'accessibilitat és doble: criteris d'acceptació específics en cada història i una definició de fet (definition of done) comuna amb comprovacions d'accessibilitat que s'apliquen sempre.

Observa que els criteris s'expressen com a comportaments observables («es pot fer servir amb el teclat», «s'anuncia»), no com «compleix WCAG». Això permet a QA verificar-los i a desenvolupament saber què ha de construir.

Plantilla de definició de fet (fragment d'accessibilitat)

• Passa les proves automàtiques d'axe-core sense violacions en els estats principals del component o de la pantalla.
• Tota la funcionalitat es fa servir amb el teclat; el focus és visible i segueix un ordre lògic.
• Provat amb un lector de pantalla d'escriptori en els fluxos que inclou la història.
• Contrastos de text i de components verificats amb els tokens del design system.
• Funciona amb zoom del 200 % i en una finestra de 320 píxels CSS d'amplada sense pèrdua de contingut (1.4.4 Canvi de mida del text, 1.4.10 Reajustament dels elements).
• Sense contingut que depengui només del color, del moviment o d'un gest complex.
• Si introdueix contingut, té textos alternatius, encapçalaments i, en vídeo, subtítols.

Accessibilitat en el disseny

El disseny fixa desenes de decisions que després ningú no reconsidera: colors, mides, espaiats, ordre visual, estats dels components, textos d'etiquetes i d'error. Dues pràctiques converteixen el disseny en un aliat:

Anotacions d'accessibilitat als fitxers de disseny

Cada pantalla lliurada a desenvolupament hauria de portar anotacions de: ordre del focus (números sobre els elements interactius), encapçalaments i el seu nivell, landmarks (regions: capçalera, navegació, principal, peu), nom accessible d'icones i botons sense text, comportament amb el teclat dels components complexos, textos alternatius de les imatges, i què passa amb el focus en obrir i tancar diàlegs. Hi ha kits d'anotació per a eines com Figma que faciliten la feina; el que importa és que la convenció sigui única a l'organització.

Revisió de disseny (design review) amb llista de comprovació

Abans de passar a desenvolupament, una persona formada revisa cada pantalla amb una llista fixa. Una llista de 12 punts és suficient per detectar la majoria dels problemes de disseny:

1. Contrast de text normal ≥ 4,5:1 i de text gran ≥ 3:1 (1.4.3 Contrast (mínim)).
2. Contrast de vores de camps, icones informatives i estats ≥ 3:1 (1.4.11 Contrast no textual).
3. Cap informació transmesa només pel color (1.4.1 Ús del color).
4. Objectius tàctils d'almenys 24 × 24 píxels CSS, preferiblement 44 × 44 (2.5.8 Mida de l'objectiu (mínim)).
5. Estat de focus dissenyat per a cada component interactiu i visible sobre tots els fons (2.4.7 Focus visible).
6. Etiquetes visibles en tots els camps; el placeholder no substitueix l'etiqueta (3.3.2).
7. Missatges d'error dissenyats: on apareixen, què diuen, com es relacionen amb el camp (3.3.1, 3.3.3).
8. Jerarquia d'encapçalaments coherent amb l'estructura visual (1.3.1, 2.4.6 Encapçalaments i etiquetes).
9. Ordre de lectura i de focus definit, especialment en dissenys de diverses columnes (1.3.2 Seqüència significativa, 2.4.3 Ordre del focus).
10. Comportament a 320 píxels d'amplada i amb el text al 200 % (1.4.10, 1.4.4).
11. Sense reproducció automàtica d'àudio ni animacions no desactivables de més de 5 segons (1.4.2, 2.2.2 Posar en pausa, aturar, amagar).
12. Les funcions que requereixen arrossegar tenen una alternativa d'un sol punter (2.5.7 Moviments d'arrossegament).

Com introduir-ho en un equip que no ho fa

Si l'equip no té la pràctica, no imposis la llista completa de cop. Un camí que funciona: començar amb la definició de fet (tres comprovacions: axe, teclat, zoom); al cap de poques setmanes, afegir la revisió de disseny a les pantalles noves; després, els criteris d'acceptació específics a les històries de formularis i fluxos crítics; finalment, les anotacions completes. Mesura a cada pas quants defectes d'accessibilitat arriben a producció: la xifra ha de baixar i és el millor argument per continuar.

Resum

• El shift-left mou l'accessibilitat a requisits i disseny, on corregir costa una fracció del que costa en producció.
• Cada història d'usuari porta criteris d'acceptació d'accessibilitat observables; la definició de fet comuna afegeix comprovacions que s'apliquen sempre.
• El disseny es lliura amb anotacions (ordre del focus, encapçalaments, regions, noms accessibles, estats) i passa una revisió amb una llista de comprovació de 12 punts.
• Dissenyar tots els estats (focus, error, càrrega, buit) evita que s'improvisin a desenvolupament.