written by @jsdev This is how I tackle Accessibility I have led teams to perfect independent audits, 1st pass approval to all app stores. Accessibility means inclusivity but also portability. These steps will make your developers better and goes way past accessibility.

1. Tackling Accessibility
awareness, education, transparency, accountability
IDE Linter | Command Line Linter | Live Console Audit | Robust Test Runners

2. AxeLinter
Shift Left, Change Habits
catches mistakes as soon as they are made
• Catches 41 agnostic non-false positive violations
• Has additional support for framework specific libraries
• Actively developed so only getting better

3. Eslint
Shifts Left + Enforcement
extremely granular, configurable, no defaults out of box
• Industry best practice, tremendous plugin community
• Can catch all sorts of code smells that will help teams ship faster
• Can be used to generate a static code report
• Any violation can be configured to be ignored, throw warning, or error
• Can be used as part of git flow, preventing problematic code from getting
merged or pushed, if included as a git hook
• Can be used to fail pipeline builds, if flagged as a build step

4. Live Console Audit
Definition of Done
ability to validate a new feature, has no non-false positive issues
• No test runner needed, no QA person or experience required
• Script include for non prod builds
• Scans DOM rendered as it mutates, and logs violations in console.
• Will catch form validation, dialogs, the full axe-core rule set

5. Robust Test Runner
Regression and exhaustive tests
does not have to be run at pipeline but accessible to run command line
This is the gold standard, tests:
• All zoom levels
• All browsers
• All themes
• All orientations, dimensions
Easy to do validate initial route loads
More work to script user actions
to micro test inject what triggers DOM
mutations, such as dialogs, form
validation, autocompletes, etc.
Requires any Modern Test Runner:
• TestCafe, PlayWright, Cypress, Selenium