Case study
Accessibility Auditor Skill
An AI-agent workflow for the first layer of accessibility auditing: websites, mobile and desktop apps, repositories, and a clear backlog of fixes.
The problem
Accessibility audits often get stuck between two extremes. A team may receive a broad report saying “accessibility should be improved” without knowing where to start. Or every improvement waits for manual screen-reader testing, even though many issues are already visible in the code, HTML, and baseline standards.
The result is a large, vague accessibility debt: it is unclear which tasks are quick fixes, which ones block users, and which ones need expert judgement.
What this skill is
Accessibility Auditor Skill is a portable skill for an AI agent that helps run a structured first pass of an accessibility audit against a website, mobile or desktop app, GitHub repository, or local project.
It does not promise a “complete audit with one button.” Its practical purpose is to gather evidence quickly, find common violations, map them to standards, and turn the result into a backlog that developers can act on.
Workflow
A typical workflow looks like this:
- Define the audit target: URL, repository, local folder, or a specific user journey.
- Gather available evidence: HTML, components, forms, navigation, page structure, UI code.
- Apply the relevant checklist: web, Electron, mobile, or desktop source patterns.
- Classify findings by severity, confidence, and standards.
- Separate quick fixes from areas that need manual validation.
- Produce an actionable backlog: what is broken, why it matters, how to fix it, and how to verify it.
This format works for a one-off audit and as part of a regular AI-assisted workflow inside a product team.
What it checks
Depending on the target and available tooling, the skill helps inspect:
- HTML semantics, headings, landmarks, and page structure;
- links, buttons, forms, labels, alt text, and accessible names;
- keyboard navigation, focus order, visible focus, and common keyboard traps;
- ARIA: where it helps, where it harms, and where it conflicts with native semantics;
- baseline WCAG 2.1 / WCAG 2.2 notes and GOST R 52872-2019 framing;
- source-level patterns for React, Electron, Android, iOS, Flutter, React Native, and desktop UI.
The main output is not an abstract score. It is a list of concrete problems with context and suggested fixes.
What can be fixed immediately
Many violations do not need to wait for a full manual testing cycle. For example:
- missing labels on form fields;
- buttons without a useful accessible name;
- interactive
divelements instead of native controls; - broken heading hierarchy;
- focus loss after closing a modal;
- form errors not associated with their controls;
- decorative elements exposed in the accessibility tree;
- ARIA that makes native behavior worse.
These are baseline standards. They can become development tasks immediately, while expert validation focuses on more expensive and ambiguous scenarios.
Where focused expert validation is needed
Screen-reader and manual validation remain important for:
- critical user flows: sign-up, checkout, request forms, onboarding, payment;
- complex components: comboboxes, date pickers, tabs, modals, drag-and-drop;
- dynamic states and live regions;
- prioritizing ambiguous issues;
- confirming that a fix actually improves the experience for a blind user.
The point is not to replace the expert. The point is to stop wasting expert time on chaos. The agent prepares the map; the expert validates key flows and decisions where the cost of error is high.
What this gives in practice
The team receives more than a general conclusion. It receives material that can be acted on:
- quick fixes that can be implemented from standards immediately;
- backlog items with severity, evidence, and suggested fix;
- repeated component-level issues;
- scenarios that deserve focused screen-reader validation;
- recommendations for adding accessibility checks to review, QA, or definition of done.
This brings the audit closer to an engineering process: less uncertainty, more concrete tasks, and a clearer next step.
Commercial takeaway
This project demonstrates the Blind Dev approach to accessibility + AI agents: shorten the path from uncertainty to fixes, make audits easier for development teams to act on, and honestly separate the automatable layer from expert validation.
I can use this approach to audit a website, mobile app, desktop app, Telegram Mini App, repository, internal service, or set up a similar AI-assisted accessibility workflow for your team. This is especially useful when the goal is not just to receive a report, but to quickly understand what to fix now, which flows to validate, and how to stop the same issues from appearing in new components.
Links
Related services
- Accessibility audit
- AI workflow consultation