Lintning och CI-spärrar för tillgänglighet

Tester körs efter att koden har skrivits, men en linter markerar problem medan du skriver. Ju tidigare du upptäcker ett problem, desto billigare är det att åtgärda.

För React-projekt kontrollerar ESLint-pluginet eslint-plugin-jsx-a11y din JSX efter vanliga tillgänglighetsmisstag direkt i editorn.

jsx-a11y upptäcker till exempel en bild utan alt-prop, en länk utan href eller en klickhanterare på ett icke-interaktivt element.

Lägg till alt-propen så försvinner varningen. Åtgärden är liten, och du upptäckte den innan koden ens levererades.

En linter läser källkod, inte den renderade sidan. Den kan inte mäta kontrast eller fokusordning, så den kompletterar axegenomsökningar i stället för att ersätta dem.

En CI-grind är en kontroll som måste godkännas innan kod kan slås samman. Om ditt tillgänglighetstest misslyckas blockeras pull-begäran helt enkelt.

Utan en grind är en underkänd granskning bara en varning som alla ignorerar. En grind gör tillgänglighet till ett krav, inte ett artigt förslag.

Ett CI-arbetsflöde installerar beroenden och kör sedan dina lint- och testkommandon. En avslutskod som inte är noll gör automatiskt att jobbet misslyckas.

När bygget blir rött ser utvecklaren exakt vilken regel och vilket element som misslyckades i loggen. Återkopplingsloopen tar minuter, inte veckor.

En grind som går sönder av fel orsaker stängs av. Håll testerna stabila och avgränsade så att teamet litar på att ett rött bygge betyder ett verkligt problem.

Den starkaste uppsättningen kombinerar allt: lint medan du kodar, axe i testerna och en CI-grind vid sammanslagning. Varje lager upptäcker sådant som de andra missar.

Kör lintning medan du kodar, kör axe i testerna och lägg in en grind för sammanslagningar i CI. Tillsammans hindrar dessa skyddsräcken regressioner från att nå produktion. 🚦