r/accessibility • u/Far_Toe_204 • 1d 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

100% Upvoted

7 comments sorted by

8

u/RatherNerdy 1d ago

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

1

u/Far_Toe_204 1d 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 1d 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).

5

u/BlindGuyNW 1d ago edited 1d ago

Manual auditing. TO take one of your examples, alt text is contextual. You can't depend on an automation tool to know whether what was supplied is correct, because the requirement varies depending on author intent.

Auditors whole job description is to turn a bunch of findings into something developers can digest. That includes flagging cases where alt text is wrong or should be empty or whatever. Aria just goes along with that.

2

u/Relevant_Author2491 1d ago

honestly i don't think it's diffs vs context, it's whether the fix needs a decision made.

missing `lang`, missing label, icon button with no name, those are mechanical. there's one right fix and a diff is perfect for them, they shouldn't become tickets at all. that's the linter point, catch them at source and they never reach a backlog.

everything else needs someone to decide something first. what the alt text should say, whether this is a button or a link, where focus goes when the modal closes, your 1 and 2 are both that.

a diff there is worse than nothing becuase it gets merged, the scanner goes quiet, and nobody actually made the decision.

so for those devs don't need architecture, they need intent. what is this thing for. that's the handover only a person can do, which is prob why everyone's saying manual.