Integració d'accessibilitat a CI/CD

L’error d’accessibilitat més barat és el que mai no es fa merge. La integració d’accessibilitat a CI/CD mou les proves cap a l’esquerra, dins de la teva canonada de desenvolupament, de manera que les regressions es detecten automàticament a cada pull request en lloc d’aparèixer mesos més tard en una auditoria — o en una reclamació.

Per què integrar l’accessibilitat a CI/CD

La majoria dels equips proven l’accessibilitat a posteriori: una auditoria periòdica genera una llista llarga, l’equip la corregeix, i després les mateixes classes de problemes tornen a colar-se silenciosament amb les funcionalitats següents. Automatitzar les comprovacions a la canonada trenca aquest cicle. Cada canvi s’avalua a mesura que es fa, els desenvolupadors reben feedback mentre el codi és fresc, i la teva conformitat tan costosa d’aconseguir queda protegida contra la regressió silenciosa.

Com funciona

La funció Code Analysis de QualiBooth s’integra amb GitHub Actions. Un cop configurada, el workflow s’executa automàticament a cada push i pull request:

1. Instal·la el QualiBooth GitHub Action i afegeix el teu secret QUALIBOOTH_ORG_UUID.
2. Fes commit del fitxer de workflow — GitHub desencadena escanejos d’accessibilitat automàticament a partir d’aquell moment.
3. Els resultats apareixen al tauler Scan Runs de QualiBooth, cercable per repositori, branch o hash de commit.
4. Cada violació es localitza fins al camí del fitxer i el número de línia amb gravetat Error o Warning.
5. Quan s’aplica una correcció, el següent escaneig marca el problema com a Resolt — el progrés és mesurable execució per execució.

L’escaneig basat en ESLint admet actualment bases de codi React, Vue, JavaScript i TypeScript. El suport per a frameworks addicionals i plataformes de CI està en el full de ruta.

Què configurem

1. Integració amb GitHub Action — l’action de QualiBooth connectada al workflow del teu repositori.
2. Feedback al PR — comprovacions automàtiques que comenten els resultats directament als pull requests.
3. Detecció de regressions — cada anàlisi es compara amb una línia base perquè els nous problemes estiguin clarament separats del backlog existent.
4. Línies de base — una instantània dels problemes existents perquè posis portes als problemes nous, no a tot el teu backlog de cop.
5. Tauler Scan Runs — cada execució registrada amb branch, commit, recompte de problemes i seguiment de problemes resolts.

On s’executen les comprovacions

• Pull requests — escanejos ràpids de fitxers modificats per a un feedback àgil del revisor
• Branch pushes — monitoratge continu perquè les regressions es detectin abans de la revisió del PR
• Comprovacions pre-merge — detectar noves regressions abans que arribin al branch main
• Escanejos programats — escanejos més complets cada nit o per a cada release a tota l’aplicació

Un límit honest

Les proves automatitzades només detecten de manera fiable un 30–40% dels criteris d’èxit de WCAG. Som explícits sobre això: la integració a CI/CD és la manera d’evitar que els problemes automatitzables arribin mai a producció i de protegir-te contra la regressió — però no substitueix el criteri humà. La nostra guia sobre les proves d’accessibilitat automatitzades a CI/CD explica on cau aquesta línia a la pràctica. La imatge completa s’aconsegueix combinant portes automàtiques amb auditories manuals fetes per persones amb discapacitat i auditories recurrents.

Per a qui és

Equips d’enginyeria i de plataforma que despleguen contínuament i volen que l’accessibilitat sigui una porta de qualitat estàndard i automàtica — igual que els tests i el linting. És un component natural d’un programa més ampli de millora del procés d’accessibilitat.