QA i automatització: axe-core, Playwright, pa11y-ci i definició de fet

L'automatització no fa accessible un producte, però evita que ho deixi de ser. Un conjunt de proves automàtiques ben col·locat en el flux d'integració contínua detecta les regressions més comunes en segons, allibera QA per a les comprovacions que exigeixen criteri humà i dona a l'organització una xarxa de seguretat mesurable. En aquesta lliçó veuràs quines eines fer servir, on col·locar-les, com configurar-les i, sobretot, què no poden fer.

Què cobreix l'automatització i què no

Les eines automàtiques basades en regles (axe-core és el motor més estès; també el fan servir Lighthouse i moltes extensions) detecten de manera fiable problemes com ara: imatges sense atribut alt, camps sense etiqueta, contrastos insuficients en text pla, atributs ARIA invàlids o mal combinats, absència d'idioma de la pàgina, encapçalaments buits, enllaços sense text, identificadors duplicats. Segons diferents estudis, cobreixen aproximadament entre un 30 % i un 40 % dels problemes que apareixen en una auditoria manual (alguns fabricants, mesurant per volum d'incidències i no per criteris, donen xifres més altes); i en molts casos només assenyalen la possibilitat d'un problema que ha de confirmar una persona.

No poden avaluar si un text alternatiu és adequat, si l'ordre del focus té sentit, si un missatge d'error ajuda a corregir, si un component personalitzat es fa servir amb el teclat com s'espera, si els subtítols són correctes o si un procés complet es pot acabar amb un lector de pantalla. Aquestes comprovacions queden per a les proves manuals, que han d'estar igual de definides en el procés.

On col·locar les proves: la piràmide

axe-core amb Playwright

Playwright és un marc de proves d'extrem a extrem que controla navegadors reals. El paquet oficial @axe-core/playwright permet analitzar la pàgina en qualsevol punt d'un flux, inclosos els estats que només apareixen després d'interactuar (un diàleg obert, un error de validació mostrat).

import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test('el formulari de cita prèvia no té violacions', async ({ page }) => {
  await page.goto('/cita-previa');
  await page.getByRole('button', { name: 'Continua' }).click(); // provoca errors de validació

  const resultados = await new AxeBuilder({ page })
    .withTags(['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa', 'wcag22aa'])
    .exclude('#widget-de-terceros')
    .analyze();

  expect(resultados.violations).toEqual([]);
});

Algunes decisions importants de configuració:

• Etiquetes (tags): limita-les als nivells que exigeixes (A i AA de 2.0, 2.1 i 2.2) perquè el pipeline no falli per regles de bones pràctiques que no són criteris de conformitat, o inclou-les com a avisos, no com a errors.
• Exclusions: exclou components de tercers que no pots corregir, però registra'ls com a risc conegut i revisa'ls a les proves manuals; no te n'oblidis.
• Estats: analitza després d'interactuar. La majoria dels problemes d'ARIA apareixen en menús oberts, diàlegs i missatges d'error, no en la càrrega inicial.
• Informe: desa el JSON de resultats com a artefacte del pipeline per poder analitzar tendències.

Amb Cypress, el paquet cypress-axe ofereix el mateix enfocament amb cy.injectAxe() i cy.checkA11y().

pa11y-ci per a moltes URL

pa11y-ci recorre una llista d'URL (o un sitemap) i falla si troba errors, cosa que el fa ideal per a un rastreig nocturn de l'entorn de proves o de producció. Un fitxer .pa11yci típic:

{
  "defaults": {
    "standard": "WCAG2AA",
    "runners": ["axe", "htmlcs"],
    "timeout": 30000,
    "hideElements": "#cookie-banner",
    "chromeLaunchConfig": { "args": ["--no-sandbox"] }
  },
  "urls": [
    "https://pruebas.ejemplo.es/",
    "https://pruebas.ejemplo.es/tramites",
    { "url": "https://pruebas.ejemplo.es/mi-cuenta", "actions": [
      "set field #usuario to demo",
      "set field #clave to demo",
      "click element #entrar",
      "wait for url to be https://pruebas.ejemplo.es/mi-cuenta/inicio"
    ]}
  ]
}

Fer servir dos motors (axe i HTML_CodeSniffer) amplia la cobertura, tot i que també els falsos positius; revisa els resultats abans de fer-los bloquejants. Un llindar raonable per començar és «no més errors que en l'execució anterior» i, un cop estabilitzat, «zero errors».

Definició de fet i criteris d'acceptació a QA

L'automatització només funciona si forma part del contracte de l'equip. Dos documents ho fixen:

• Definició de fet: el pipeline d'accessibilitat passa en verd; el component o la pantalla s'ha provat amb el teclat; s'ha provat amb un lector de pantalla si la història inclou interacció; qualsevol exclusió està justificada a la mateixa prova i registrada com a deute.
• Criteris d'acceptació manuals: QA disposa d'una llista per tipus d'història (formulari, taula de dades, diàleg, navegació, contingut multimèdia) amb les comprovacions manuals que l'automatització no cobreix. Per exemple, per a un formulari: etiquetes correctes en escoltar cada camp, errors anunciats i amb el focus, enviament amb Retorn, ordre del focus lògic, comprensible amb un zoom del 400 %.

Llista de comprovació per implantar l'automatització

1. Linter d'accessibilitat actiu als repositoris d'interfície.
2. axe-core a les proves de components del design system, sobre tots els estats.
3. axe-core a Playwright o Cypress en els fluxos crítics, analitzant després de les interaccions.
4. pa11y-ci o equivalent sobre l'entorn de proves amb execució nocturna i llindar definit.
5. Resultats desats com a artefactes per mesurar la tendència.
6. Definició de fet amb comprovacions automàtiques i manuals.
7. Llista de comprovacions manuals per tipus d'història a disposició de QA.
8. Registre d'exclusions i regles deshabilitades amb justificació.

Resum

• L'automatització detecta de manera fiable una part dels problemes (al voltant del 30-40 %) i és insubstituïble contra les regressions, però no verifica l'experiència real.
• Col·loca proves en tots els nivells: linter, component, fluxos e2e amb axe-core a Playwright o Cypress, rastreig amb pa11y-ci i proves manuals definides.
• Analitza després d'interactuar, limita les etiquetes als nivells exigits, registra les exclusions i desa els resultats per mesurar la tendència.
• La definició de fet i les llistes manuals per tipus d'història converteixen l'accessibilitat en part del contracte de l'equip.