Hire an AI section 508 accessibility reviewer

Everything it can hand back

Your task sets the actual outputs. The specialist picks the methods that cover them.

• A list of barriers, each with the WCAG rule, how bad it is, where it is, and what a real user would hit
• A code fix for each barrier
• A fix order from "blocks a task" to "polish"
• A draft accessibility report (VPAT or ACR), if you ask, with every claim marked tested or not tested
• A list of what only a person with a screen reader and keyboard can confirm

How it does the job well

• A clean automated scan is not proof of access. Scanners miss many barriers. Say so when it applies.
• Never claim conformance, compliance or a pass you did not see tested. This is a review, not a certification, and not legal advice.
• Every claim that a screen reader says or does must come from the user's own test. Otherwise it is LIKELY or NEEDS TEST.
• Do not invent a WCAG number, a law, a date or a tool setting. If unsure, write CHECK: and name the document to look up.
• Do not edit, publish or send anything. Hand over the findings and fixes for the user and their accessibility lead to review.
• Never claim conformance from an automated scan alone — test with real assistive technology. Automated tools catch roughly 30–40% of WCAG failures and zero of the "is it actually usable" questions. Every conformance claim must be backed by manual screen-reader and keyboard testing, or it isn't a claim, it's a liability.
• Native HTML semantics first; ARIA only when native won't do — and never as a band-aid. A <button> beats a <div role="button"> every time. The first rule of ARIA is don't use ARIA if a native element exists; bad ARIA is worse than none because it overrides what the browser already conveyed correctly.

Mistakes it avoids

• Claiming code works without running it or its tests.
• Inventing APIs, package versions or settings instead of checking the installed ones.
• Changing behaviour outside the request, such as reformatting whole files or renaming public interfaces.

What a good result looks like

An example, not your task: You are about to launch a government or public-sector page, form or portal and want a barrier check first.

• Scope. The pages checked, the rule that applies and why, and what is missing.
• Findings. Each barrier with its WCAG rule, severity, location, user effect, status and code fix.
• Fix order. Barriers ranked from those that block a task to polish.
• Still to test by a person. Keyboard, screen reader, zoom and document checks the AI cannot run.
• Draft report. A VPAT or ACR draft with each rule marked and each claim tied to a test.
• Next steps. Retest steps and who must review before you share it.

How the work is checked

• The changed files build, and the relevant tests and linters pass. The commands and results are shown.
• Each change is explained in one line with its reason, and risky areas are named.
• Any check that could not run is reported as NOT_RUN with what it needs.
• States which checks passed, failed or could not run, and names missing inputs.

These checks have not been run against a model yet. Your AI uses them to check its own work.

Capabilities

• Set the standard. It states which rule applies to you and why, so it does not claim a stricter or looser law than the one that governs your site.
• Check the code and scans. It reads your HTML or screenshots for missing labels, bad structure, weak contrast and unreachable controls.
• Mark what is proven. It labels each finding as confirmed from the code, likely, or needs a person to test. It never says it ran a screen reader.
• Write the barrier list. Each barrier gets a WCAG rule, a severity, the place it sits, the effect on a real user and a fix in the page code.
• Plan the fixes. It orders fixes by how much they block users, and lists the retest steps for each.
• Draft the report. If asked, it drafts the conformance report. A rule is only marked "Supports" if testing backs it.

How the role works

1. Checks your task, context and available tools.
2. Picks the methods needed and prepares a work plan.
3. Carries out supported tasks, with each method's limits and review gates.
4. Checks the real deliverables and corrects supported faults.
5. Hands back files, evidence and unresolved gaps.

Your specialist's working setup

Download the base specialist without a task form or account. README.md and SETUP.md explain how to use the folder. SOUL.md defines its scope. INTAKE.md asks missing questions inside your AI. PLAYBOOK.md, SKILLS.md, BEST_PRACTICES.md, CHECKS.md and HANDOFF.md guide the work and its checked deliverables.

Complete associated skills, supporting files and licences are included. Choose only the methods needed for the actual task. Keep context, working files and accepted feedback in your AI project.

Use this specialist through MCP or the API

Call prepare_specialist with role_id engineering-section-508-specialist only. No task is required to load it. Your AI asks what job you need done, what you want back and which relevant context it can use.

For task-led hiring, call find_specialist, explain the suggested specialists and let the user accept or change the team.

Complete ZIP: Download base specialist. API: GET /api/v1/specialists/engineering-section-508-specialist/pack. The host AI supplies its own model, tools and execution; a pack does not connect accounts or run a task.

Inputs and helpful context

The specialist starts from the task brief. Only active methods require their inputs.

For the primary method, when used

• The page, form or flow in scope, as HTML, screenshots or a link, plus what the user must do on it
• Which rules apply to you, such as federal Section 508, state or local government, or your own target
• Output from a scan tool such as axe, WAVE or Lighthouse (optional)
• Any barriers users already reported (optional)
• The PDFs or documents linked from the page (optional)

Helpful context (optional)

• Your agency or contract wording on which accessibility standard applies.
• A short list of the tasks users must finish, such as "file a claim".
• Your last accessibility report, if you have one.

Tools and access

• axe, WAVE or Lighthouse: These free tools catch the barriers a scan can find. Paste their output so the agent can sort what they found.
• NVDA, JAWS or VoiceOver: These are screen readers. Testing with one is how you confirm what the AI could only guess.
• Claude Code or another AI that can open your site files: It can read your real templates and edit the fix in place. In a plain chat you paste the code.

Functions and deliverables

• Section 508 accessibility reviewer: Review a web page or form for Section 508 and WCAG barriers, and get a ranked fix list plus a draft accessibility report (VPAT) to check.
  • A list of barriers, each with the WCAG rule, how bad it is, where it is, and what a real user would hit
  • A code fix for each barrier
  • A fix order from "blocks a task" to "polish"
  • A draft accessibility report (VPAT or ACR), if you ask, with every claim marked tested or not tested
  • A list of what only a person with a screen reader and keyboard can confirm
  Source: Michael Sitarzewski and Agency Agents contributors.
• Web accessibility checker: Check a web page or code for WCAG 2.2 accessibility problems. Get a ranked list with where each one is, and fixes if you ask.
  • A ranked list of WCAG 2.2 problems
  • The place in the page or code for each
  • Fixes applied and re-checked, if you asked
  • A note on what automated checks cannot cover
  Source: sickn33.
• Accessibility standards checker: Check your site against WCAG accessibility rules. Give it your page code or screenshots. You get gaps by level, ranked fixes and draft statement notes. Not legal advice.
  • A gap table with status for each criterion
  • Fixes ranked by priority
  • Annotated code with corrections
  • Draft notes for an accessibility statement
  • A map from rules to laws
  Source: Hemant Naik.
• WCAG accessibility reviewer: Share site code or pages and target WCAG level. It checks selected issues and suggests fixes; retest results depend on tools and manual review.
  • A list of issues by severity
  • Before and after code fixes
  • A re-check after the fixes
  • A report for managers
  • A pipeline check to stop new issues
  Source: Alireza Rezvani.
• AI project context organiser: Share your project and next task. Get a short rules file, a focused file list and a clear handoff for later sessions.
  • A ready rules file for your project
  • A list of which files to load for each task
  • Rules for when to reset or trim the session
  • A checklist for spotting drifting answers
  Source: Addy Osmani.

Tasks you can use it for

• You are about to launch a government or public-sector page, form or portal and want a barrier check first.
• A contract asks for a VPAT (an accessibility conformance report) and you need a first draft.
• A scan came back clean, but a user says they can't finish a form with a keyboard or screen reader.
• You have a list of failed checks from axe, WAVE or Lighthouse and need to know which to fix first.

Limits to check before starting

• You want a plain accessibility audit plan for any site, with no U.S. law angle. Use the Accessibility auditor.
• You are building a government site from scratch on the U.S. Web Design System. Use the USWDS Developer agent.
• You need legal sign-off or a certificate of conformance. Only a qualified auditor or your counsel can give that.
• You want an overlay widget added to fix the problem. This agent fixes the page code instead.

Best way to use this role

Give it one clear outcome, the actual files and a definition of done. Keep the work in one AI project so it can reuse checked context and earlier files.

• Download the pack from this page and add it to your AI as a skill. Or paste SKILL.md into a new chat, then paste references/source-agent.md after it.
• Say which rules apply to you, and paste the page code or screenshots, one page or flow at a time. A chat AI cannot open your site, so paste what you want checked.
• Read the findings. Each one says if it is confirmed from the code or only likely. Treat "likely" as a test to run, not a fact.
• Fix the top items in your page code. Then test the real flow yourself with only a keyboard, and with a screen reader such as NVDA (free on Windows) or VoiceOver (built into Mac).
• Paste your test results back in and ask the agent to update the list. Ask for the VPAT draft last, once testing is done.
• Have your accessibility lead or counsel review any report before you send it to a buyer or agency.

Read it as data

Read the complete role setup as JSON. Connect your AI to the AI Blocks MCP library and read aiblocks://roles/engineering-section-508-specialist for its role instructions and pinned sources.

This is a prepared AI role. No task has run. Your AI carries out authorized work using its available tools and reports the actual deliverables and checks.