Anotar l'accessibilitat en els dissenys (Figma): lliurables per a desenvolupament

Un disseny a Figma mostra com es veu la interfície, però no com se sent, com es recorre amb el teclat ni quin nom té cada botó d'icona. Si aquesta informació no viatja amb el disseny, l'equip de desenvolupament se la inventa, i se la inventa de manera diferent a cada component. Les anotacions d'accessibilitat són la manera de tancar aquest buit: una capa de notes sobre el disseny que especifica semàntica, ordre, noms i comportaments. Aquesta lliçó explica què cal anotar, com fer-ho a Figma i com convertir-ho en un lliurable que desenvolupament i QA puguin fer servir. És l'últim pas del disseny: anota quan el disseny ja ha passat les proves d'estrès de la lliçó anterior.

Per què anotar

Una part molt important dels problemes d'accessibilitat que apareixen a les auditories té l'origen en decisions de disseny o de contingut, no de codi: un botó sense nom, un ordre de lectura confús, un estat de focus inexistent, un color sense contrast. Anotar-los en el disseny costa minuts; corregir-los després del desenvolupament costa dies. A més, les anotacions converteixen l'accessibilitat en un requisit explícit i verificable: QA pot comprovar el resultat contra l'anotació, igual que comprova un color o un marge.

Què cal anotar

Com anotar a Figma

1. Crea una pàgina o una capa «A11y» per pantalla, separada del disseny visual, que es pugui amagar en presentar-ho al client i mostrar a desenvolupament.
2. Fes servir un kit d'anotacions. N'hi ha diversos de gratuïts a la comunitat de Figma i connectors pensats per a això: Include (d'eBay), A11y Annotation Kit, Stark, Axe for Designers (de Deque) o A11y - Focus Order. Tria'n un i fes-lo servir en tot el projecte; la coherència importa més que l'eina.
3. Numera l'ordre de focus amb marcadors sobre cada element interactiu. Si l'ordre visual i el de focus difereixen, és un senyal que cal replantejar el disseny, no que cal anotar més.
4. Anota els noms accessibles amb el text literal, entre cometes, en l'idioma de la interfície. Evita «posar un aria-label descriptiu»: decideix tu el text.
5. Documenta els components a la biblioteca, no a cada pantalla: l'estat de focus, les tecles i el rol s'anoten una vegada al component del sistema de disseny i s'hereten.
6. Comprova el contrast al mateix Figma amb un connector (Stark, Contrast, A11y - Color Contrast Checker) i anota la ràtio al costat de la paleta. Defineix als estils de color parells «text sobre fons» ja validats.
7. Inclou els estats d'error i buits de cada formulari i llista, amb el text exacte. Són els que més s'obliden.

Del disseny al desenvolupament i a QA

• Revisió conjunta: una sessió curta de disseny i desenvolupament per pantalla per repassar les anotacions evita malentesos.
• Criteris d'acceptació: cada anotació es converteix en una condició verificable a la història d'usuari («el botó de tancar té el nom accessible Tanca el diàleg i en tancar el focus torna al botó que l'ha obert»).
• Llista de comprovació de QA derivada de les anotacions: recorregut amb el teclat, lectura amb lector de pantalla, zoom al 200 i al 400 %, contrast mesurat.
• Manteniment: quan un component canvia, canvia la seva anotació. Les anotacions desactualitzades són pitjors que cap.

Resum

• Moltes barreres neixen en el disseny i el contingut; anotar-les a Figma és la manera més barata d'evitar-les.
• Anota encapçalaments, landmarks, ordre de focus, noms accessibles literals, alt, estats, rol, teclat, anuncis, contrast i comportament responsive.
• Capa «A11y» separada, kit d'anotacions únic, documentació als components de la biblioteca, contrast validat als estils de color.
• Les anotacions es converteixen en criteris d'acceptació i en la llista de comprovació de QA.
• Mantén les anotacions al dia quan canviï el component.