Find detectable WCAG barriers
and areas for manual verification.

The accessibility module scans a specific URL and detects automatically measurable barriers — contrast, labels, headings, structure. It is not a full WCAG audit: it shows what to fix first and which criteria need a human.

Illustrative product view
68
Automated test score: 68/100 This is not a WCAG conformance percentage
Contrast
3.2:1
Rules
2 14 occurrences
Keyboard
n/a Needs Tab test
Insight organizes detectable barriers and prepares the manual verification scope.

Every finding includes a WCAG criterion, evidence, affected element, user impact and whether the issue can be confirmed automatically — with no certification promises or EAA compliance claims.

From scan to a fix list.

Four steps from URL to decision — without guessing whether the issue is contrast, forms or keyboard navigation.

Contrast Scan

Text and background color pairs — whether they meet AA on the rendered page.

AACTAText
Forms

Field labels, error messages and aria-describedby associations.

LabelError
Keyboard

Tab order, focus-visible and semantics of interactive elements.

TabFocus

Page analysis

You test a specific URL — homepage, landing or form. You see scan context and barriers detected automatically.

Audit areas · scan
Contrast 3
Issues
Forms 2
Warnings
Keyboard 1
Warning
Scan · contrast + forms

Problem explanation

Each finding has context: rule, WCAG criterion, occurrence count and why it may make the page harder to use.

Accessibility priorities
11

Fix priorities

Barriers are ordered by impact on users. You know whether the issue is contrast, labels, structure or needs a keyboard test.

68
+6
58 before
68 after

Same methodology · same URL

Check the effect after shipping

After fixes, you return to the previous scan with the same methodology and URL. You see whether barriers disappeared.

What the module covers

  • WCAG
  • Contrast
  • Structure & ARIA
  • Keyboard
  • Screen reader & AT
  • Content & media
  • User groups
  • Risk & remediation

Action plan

The fastest path to organizing barriers against WCAG 2.2 AA.

Instead of a raw violation list, the module orders recommendations by impact. You see rules with issues, occurrence counts and estimated effect on the automated score — without promising full conformance.

  • Recommendations sorted by impact
  • Rules · occurrences · WCAG criterion
  • Estimated automated-score uplift
Action plan After fixes: +12 pts (automated score)
1
Low text contrast 1 rule · 23 occurrences · 4 components
WCAG 1.4.3 AA +6 pts
2
Missing form label 1 rule · 7 occurrences · 3 pages
WCAG 1.3.1 A +4 pts
3
No visible focus 1 rule · 4 occurrences · needs Tab test
WCAG 2.4.7 AA +2 pts

WCAG criteria map

Every A and AA criterion on one map — with verification method marked.

The four WCAG principles broken into criteria with status: checked automatically, issue found, needs manual review, not applicable or no data. The map does not mean automation checked every criterion.

  • Criteria grouped by the 4 WCAG principles
  • Status readable by color, pattern and text
  • Automated scope separated from manual
18/32 checked automatically · 4 with issues · 8 need manual · 2 n/a
Perceivable
Operable
Understandable
Robust
  • Checked automatically
  • Issue found
  • Needs manual review
  • Not applicable
  • No data

User groups

Who detected barriers may make the page harder for.

The same violations may affect people with color blindness, screen-reader users, keyboard users and seniors differently. The module maps issues to potentially affected groups — this is not user research.

  • Issue mapping to user groups
  • Potential impact, not confirmed UX research
  • An argument for the client conversation
Color blindness 6 issues
May hinder · ~8% of users (estimate)
Screen readers 9 issues
May hinder · mapped from a11y tree
Keyboard navigation 4 issues
May hinder · some need Tab testing
Seniors · 65+ 7 issues
May hinder · contrast and readability

Assistive technologies

How the page is exposed to assistive technologies.

Insight analyzes structure, accessible names, roles, landmarks and heading order in the accessibility tree. It does not replace testing with NVDA, JAWS or VoiceOver.

  • Accessibility tree · landmarks · names
  • Headings, forms, links, images
  • No real screen-reader emulation
Accessibility-tree analysis — it does not replace testing with NVDA, JAWS or VoiceOver.
Landmarks A11y tree OK
Headings H1–H6 Order / levels Warning
Accessible names Role · name · label Warning
Forms Label / error text Fail
Images & links Alt · link name OK
For agencies and freelancers

Built for accessibility audits across clients

  • Switch domains and specific subpages
  • Compare historical runs with the same methodology
  • Export results to CSV and a technical report
  • Refresh accessibility alone without a full re-audit

Organize detectable
accessibility barriers.

Analyze a URL, see rules with issues and the manual verification scope — without promising full WCAG conformance.

No credit card Report with date and sources No account required