L'accessibilitat dins de l'sprint: refinament, revisió de codi i deute

A la lliçó «Shift-left» vas veure com escriure criteris d'acceptació i una definició de fet amb accessibilitat, i a la de design systems, com aconseguir components accessibles per defecte. Són necessaris, però no n'hi ha prou: un equip pot tenir una definició de fet impecable i un bon sistema de disseny i continuar produint barreres si l'accessibilitat no apareix en les converses del dia a dia. Aquesta lliçó recorre les cerimònies d'un equip àgil (refinament, estimació, desenvolupament amb revisió de codi, demostració i retrospectiva) i explica com gestionar el deute d'accessibilitat, és a dir, les barreres conegudes que arrossega el producte.

Refinament: tres preguntes per història

El refinament del backlog és el moment més barat per detectar riscos. N'hi ha prou que algú de l'equip faci tres preguntes a cada història abans de donar-la per preparada per entrar en un sprint:

1. Quins components fa servir? Si tot surt del design system, el risc és baix. Si la història necessita un component nou o una variant, cal decidir si s'incorpora al sistema, amb la seva revisió, o si és un cas puntual, i localitzar el patró APG (s'obre en una finestra nova) que li correspon.
2. Toca un flux crític? Accés, registre, compra, pagament, signatura o qualsevol tràmit complet. Si la resposta és sí, la història necessita criteris d'acceptació d'accessibilitat específics i una prova obligatòria amb lector de pantalla.
3. Introdueix contingut o un tercer? Imatges, vídeo, documents descarregables, un giny extern. Cadascun arrossega requisits (text alternatiu, subtítols, PDF etiquetat, avaluació del proveïdor) que algú ha de tenir assignats amb nom.

Quan un component és complex i ningú de l'equip no l'ha construït abans (un selector de dates, un mapa interactiu, un editor de text enriquit), crea una spike: una tasca curta d'investigació, amb temps limitat, per prototipar la interacció amb teclat i lector de pantalla abans d'estimar la història real.

Estimar amb l'accessibilitat a dins

L'accessibilitat forma part de la feina de la història, no és una feina addicional. Si l'equip estima amb punts d'història o amb hores, l'estimació inclou els estats de focus, la gestió del focus, els missatges d'error i les proves manuals. Amb un design system madur, aquest cost és petit perquè la major part ja està resolta als components; sense, és simplement el cost real de fer bé la feina.

Durant el desenvolupament: revisió de codi amb una llista fixa

La revisió de codi (code review) és l'última oportunitat de detectar un problema abans que entri a la branca principal. Inclou un bloc d'accessibilitat a la plantilla dels pull requests (les sol·licituds per integrar canvis al codi comú) perquè qui programa el marqui i qui revisa el comprovi:

## Accessibilitat
- [ ] Fa servir components del design system (si en crea un de nou, enllaça el seu patró APG)
- [ ] Elements natius per a accions i enllaços; res de div o span amb onclick
- [ ] Provat només amb el teclat: ordre lògic, focus visible, sense paranys
- [ ] Noms accessibles revisats a l'arbre d'accessibilitat del navegador
- [ ] axe sense violacions en els estats nous (obert, amb error, buit)
- [ ] Provat amb lector de pantalla si afegeix una interacció nova

La revisió no consisteix només a llegir el codi: la persona revisora obre l'entorn de previsualització i recorre el canvi amb el teclat. Dos minuts que detecten el que el linter no veu. Aquesta és una troballa típica a la revisió dels filtres de cerca d'una botiga en línia:

<!-- Incorrecte: no pot rebre el focus i no exposa funció ni estat -->
<span class="filtro" onclick="alternar(this)">Enviament gratuït</span>

<!-- Correcte: botó natiu amb el seu estat exposat -->
<button type="button" class="filtro" aria-pressed="false">Enviament gratuït</button>

En la versió correcta, l'script només ha de canviar aria-pressed entre true i false en prémer-lo. El botó ja pot rebre el focus, s'activa amb Retorn i amb Espai, i el lector de pantalla l'anuncia com un botó de commutació premut o no premut, amb la fórmula que faci servir cada lector (2.1.1 Teclat, 4.1.2 Nom, funció i valor).

Una altra pràctica eficaç és la programació en parella: una persona amb experiència en accessibilitat treballa al costat d'una altra que no en té en la primera història que toca un component complex. És la manera més ràpida que el coneixement deixi de dependre d'una sola persona.

Demostració i retrospectiva

A la revisió de l'sprint, la demostració davant les parts interessades, ensenya almenys una funcionalitat nova fent servir només el teclat i, de tant en tant, amb lector de pantalla. Verifica en directe que funciona i normalitza davant la direcció i el negoci que l'accessibilitat és part del que es lliura. A la retrospectiva, afegeix una pregunta fixa: s'ha escapat algun defecte d'accessibilitat aquest sprint i en quina cerimònia s'hauria d'haver detectat? La lliçó «Operació» amplia aquesta idea a les incidències de producció.

Si l'equip treballa amb Kanban en lloc d'sprints, les mateixes comprovacions es converteixen en polítiques explícites de les columnes del tauler: una targeta no passa d'«En disseny» a «Preparada per a desenvolupament» sense revisió de disseny, ni d'«En revisió» a «Fet» sense el bloc d'accessibilitat completat.

Deute d'accessibilitat: fer-lo visible i pagar-lo

El deute d'accessibilitat és el conjunt de barreres conegudes que manté el producte: troballes d'auditories sense corregir, excepcions aprovades en un llançament, defectes heretats de components de tercers i dreceres preses amb pressa. Com el deute tècnic, genera interessos: cada pantalla nova que copia un patró defectuós multiplica el cost de corregir-lo, i cada mes que passa augmenta la probabilitat d'una reclamació.

Registre del deute

El deute que no està escrit no existeix per a qui prioritza. Mantén un registre únic, al mateix gestor d'incidències i amb una etiqueta pròpia, amb aquests camps:

Prioritzar i reservar capacitat

Prioritza combinant impacte (la severitat), abast (un defecte en un component compartit o en un flux crític pesa més) i esforç. Els defectes en components compartits solen ser els més rendibles, perquè una sola correcció en resol totes les aparicions. Perquè el deute baixi de debò, reserva una part fixa de la capacitat de cada sprint per pagar-lo i acorda aquesta reserva per endavant amb la persona responsable de producte: el que es negocia sprint a sprint acaba perdent davant la novetat següent.

Resum

• Al refinament, tres preguntes per història (components, flux crític, contingut o tercers) detecten els riscos d'accessibilitat; els components complexos mereixen una spike prèvia.
• L'accessibilitat s'estima dins de cada història; les històries separades «per fer-ho accessible» s'ajornen i deixen que el defecte es copiï.
• La plantilla de pull request inclou un bloc d'accessibilitat, i la revisió de codi inclou recórrer el canvi amb el teclat.
• La demostració amb el teclat i la pregunta fixa a la retrospectiva fan visible l'accessibilitat a cada sprint; a Kanban, es converteixen en polítiques de columna.
• El deute d'accessibilitat es registra amb impacte, abast i alternativa, es prioritza començant pels components compartits i es paga amb una reserva fixa de capacitat.