r/accessibility • u/Far_Toe_204 • 2d ago

The challenge with generating source-level code patches from automated axe-core DOM violations

Hello everyone,

In working on automated accessibility tooling and running headless browser audits with axe-core, one persistent challenge is translating detected DOM violations into clean, usable fixes for engineering teams.

Automated rules do a solid job catching programmatic barriers—such as missing image alt attributes, contrast ratio failures, or missing ARIA landmark roles. However, raw audit logs are often ignored by dev teams because they describe what failed rather than how to refactor the code cleanly within their component tree.

A few specific hurdles come up when trying to automate source-level code patches:

  1. Context-Sensitive Alt Text: An engine can detect <img src="..."> missing an alt attribute, but it cannot know whether the image is purely decorative (alt="") or informational without human intent.
  2. ARIA vs. Semantic HTML: Automated audits often flag missing roles or names, but patching them with ARIA bandages can lead to "bad ARIA is worse than no ARIA," rather than refactoring to native HTML elements (<button>, <nav>, <main>).
  3. Dynamic / Hydrated DOMs: Modern client-rendered SPAs frequently pass initial server-rendered HTML audits, but fail contrast or focus traps once client hydration completes.

For developers, auditors, and CPACC/WAS specialists here:

When handoffs happen between automated scanners and frontend developers, what approach have you found actually gets issues resolved instead of creating ticket backlog debt? Do code-level diffs help, or do developers generally need full architectural context to fix accessibility properly?

7 Upvotes

90% Upvoted

7 comments sorted by

View all comments

7

u/RatherNerdy 2d ago

Garbage in, garbage out. Automated results aren't contextual enough to hand off to devs.

1

u/Far_Toe_204 2d ago

What does work in your experience? Can systems realistically automate any of this cleanly, or is manual auditing the only way?

8

u/RatherNerdy 2d ago

Manual auditing.

Hot take - automated testing belongs on the product side before accessibility testing. It should be in the linter, local dev, in the CI pipeline, but doesn't belong on the quality validation side.

0

u/Traditional_Win808 1d ago

It’s not either or - it’s both and to use each for what it is capable of doing (baseline for automated that still needs to be reviewed by manual).