AI Accessibility Audit Helper

What the Audit Helper Does

The audit helper turns a described accessibility problem into a structured write-up. You give it a description of the issue, an optional code snippet, and the technology and component involved; a hosted language model returns a bug-ticket style analysis with a title, a severity, the current and expected behaviour, the effect on users, the WCAG success criteria involved, a recommended fix with example code, ordered implementation steps, a testing checklist, and links to further reading.

The response streams in as it is written, so you see the sections complete one by one, and it falls back to a single request if streaming fails. The server checks that every required section is present and that the severity is one of critical, high, medium, or low before returning it; a missing severity defaults to medium.

How to Use It

1. Describe the issue as a user experienced it. “Screen reader users hear ‘button’ for every icon in the toolbar” gives the model the symptom, the audience, and the component in one sentence.
2. Paste the relevant code. With a snippet, the model reviews your actual markup and returns a corrected version. Without one, it explains the pattern from semantic HTML up to the ARIA needed and offers more than one approach.
3. Choose the stack and component type. Both are optional but they shape the example code, so a React team gets JSX and a WordPress team gets PHP templates and plain HTML.
4. Run the analysis and verify it. Read the WCAG section against the linked criterion pages, apply the fix, then work through the testing checklist before you close the ticket.

What the Analysis Covers and Its WCAG 2.2 References

The model is prompted to name each criterion by number and title, state its level, and explain why it applies to your issue, and to write the testing checklist around the things automated tools miss: screen reader behaviour, keyboard operation, 200 percent zoom, voice control, and mobile screen readers. The criteria that come up most often for the component types in the form are:

• Navigation, buttons, dropdowns, tabs, and accordions: 2.1.1 Keyboard, 2.4.3 Focus Order, 2.4.7 Focus Visible, and 4.1.2 Name, Role, Value.
• Forms: 1.3.1 Info and Relationships, 3.3.1 Error Identification, 3.3.2 Labels or Instructions, 3.3.3 Error Suggestion, and 4.1.3 Status Messages.
• Modals and dialogs: 2.1.2 No Keyboard Trap alongside the focus criteria above.
• Images and videos: 1.1.1 Non-text Content, 1.2.2 Captions (Prerecorded), and 1.2.5 Audio Description (Prerecorded).
• Carousels: 2.2.2 Pause, Stop, Hide; tables: 1.3.1 again, for header and cell relationships.

WCAG 2.2 has 86 success criteria, and the model can reference any of them. The site's criterion pages give you the normative text to check its reasoning against.

What It Cannot Do

The helper never sees your page. It cannot confirm that the issue you describe actually exists, cannot find issues you did not mention, and cannot test the fix it proposes. Its severity rating is the model's reading of your description, not a measurement, so two differently worded reports of the same bug can come back with different severities. Its links are constructed from the criterion and pattern names it chooses, and occasionally point at a slug that does not exist.

Reading the Output

The first card is the ticket: a plain title, a severity badge, the user impact as a subtitle, and side-by-side Current Problem and Expected Solution boxes you can paste into an issue tracker. WCAG Criteria and Review Requirements lists each criterion with its level and the reason it applies. Review Recommendations is the narrative fix, and Code Solution, when present, is the corrected markup with a copy button.

Implementation Steps is an ordered list you can hand to a developer, and Testing Checklist is the acceptance criteria: use it to decide when the fix is done, not just whether it was attempted. Related Resources closes with the external reading the model chose. Your remaining credit balance and, for guests, your remaining trial uses are shown above the form once an analysis completes.

Frequently Asked Questions