Accessibility Field Guide
A practical collection of accessibility field notes, examples, and small habits that help teams catch common issues before they turn into rework.
Start here
How to Use This Guide
Start here if you are choosing a work route or using the guide to build accessibility skill over time.
Accessibility Glossary
Use this as a plain-language reference for common accessibility terms that show up across project conversations.
Browse by Topic
Find the right Field Guide page by the practical issue or project moment in front of you.
Checklists and Job Aids
Use the checklist index when you need a practical prompt during intake, requirements, QA, review, vendor, or component work.
Intake
A request is forming. Ask better questions before decisions harden.
Requirements
Turn early accessibility risks into clearer requirements, acceptance criteria, and test notes.
Accessibility Requirements Checklist
A checklist for turning early accessibility risks into requirements, acceptance criteria, design notes, and QA checks.
Good Accessibility Requirements Prevent Rework
Accessibility requirements do not need to be complicated. They need to be clear enough that the team knows what to build, test, accept, and review.
“Make It Accessible” Is Not a Requirement
“Make it accessible” is a good intention, but it is not enough for a team to build, test, accept, or review. Useful accessibility requirements describe the behavior people need.
Start with the Path, Not the Checklist
Accessibility work goes better when teams understand the path early instead of treating WCAG like a last-minute checklist.
Common screen and workflow checks
Some readers come to the guide because a specific screen, form, or workflow needs attention. These pages help with the issues that often create rework: labels, errors, keyboard access, and focus order.
Tabs
A practical Accessibility Field Guide page for checking tabbed interfaces, selected state, tab panels, keyboard behavior, focus, and when tabs are the right pattern.
Combobox
A practical Accessibility Field Guide page for checking combobox fields, autocomplete suggestions, selected values, keyboard behavior, focus, and ARIA state.
Accordions
A practical Accessibility Field Guide page for checking expandable accordion sections, disclosure buttons, headings, keyboard support, focus, and expanded state.
Developer Component Checklist
A practical checklist for checking custom buttons, links, names, roles, states, keyboard behavior, focus, and ARIA before component issues become review rework.
ARIA Is Not Duct Tape
Use ARIA to describe real component behavior, not to patch over missing HTML, keyboard support, labels, focus, or state.
Button vs Link
Use buttons for actions and links for navigation so people can predict what will happen before they activate a control.
Name, Role, and Value
Check whether custom controls expose what they are called, what they are, and what state they are in before ARIA becomes guesswork.
Color Contrast
Check whether text, icons, controls, and meaningful visual boundaries are easy to see before contrast becomes a late review finding.
Color-Only Meaning
Do not make color carry the whole message. Pair color with text, shape, labels, icons, or patterns so the meaning is available to everyone.
Alt Text Basics
Write text alternatives that explain the purpose of an image in context, not every pixel in the picture.
Tables and Data Displays
Use tables when relationships matter, keep headers and labels clear, and avoid turning data into a puzzle.
Status Messages and Alerts
A practical Field Guide page about making save messages, alerts, loading updates, and other screen changes understandable without forcing users to hunt for them.
Modals and Dialogs
A practical Field Guide page about making modals and dialogs understandable, keyboard-accessible, and easy to escape.
Headings and Page Structure
A practical Field Guide page about using headings to make screens easier to scan, navigate, and review.
Accessible Names
A practical Field Guide page about how controls get the names people hear, see, speak, and navigate by.
Link Text and Button Labels
A practical Field Guide page about writing link text and button labels that make sense before someone activates them.
Native HTML First
A practical Field Guide page about starting with built-in HTML elements before reaching for custom components or ARIA.
Error Messages and Recovery
A practical Field Guide page about writing and placing error messages so users can understand what went wrong and recover without guessing.
Forms and Labels
A practical Field Guide page about labels, instructions, grouping, and required fields that help forms feel usable instead of like guessing games.
QA Keyboard Check
A practical no-mouse QA checklist for checking keyboard access, visible focus, focus order, traps, dialogs, forms, errors, and common interactive controls.
Form Review Checklist
A practical checklist for reviewing labels, instructions, required fields, errors, grouping, and recovery before a form goes to accessibility review.
Keyboard-Only Navigation
A practical Field Guide page about checking whether people can move through screens, controls, menus, dialogs, and forms without using a mouse.
Focus Visible and Focus Order
A practical Field Guide page about making keyboard focus visible, predictable, and ordered so people do not lose their place on the page.
Review
Catch obvious issues, gather evidence, and reduce avoidable rework before formal review starts.
Vendor and Third-Party Accessibility Field Guide
A practical guide for asking better accessibility questions when a product, platform, widget, or document comes from a vendor.
Vendor Accessibility Questions Checklist
A practical checklist for asking vendors what their accessibility evidence actually covers.
Review Readiness
A practical field note on checking common accessibility issues before formal review so teams can reduce avoidable rework.
Review Readiness Checklist
A pre-review checklist for keyboard access, forms, content, documents, vendor pieces, and review materials.
How to Review a Web App for Accessibility for the First Time
A practical first-pass guide for reviewing a real web app screen before accessibility issues become late rework.
Accessibility Evidence Should Match the Thing You’re Shipping
Accessibility evidence is stronger when it matches the real workflow, content, configuration, documents, and version people will use after launch.
Known Issues Are Better Than Surprise Issues
Known accessibility issues are not ideal, but they are easier to manage than issues nobody named until review, launch, or a user complaint.
Vendor Accessibility Still Needs Ownership
Buying or configuring a vendor product does not remove accessibility ownership; it changes where teams need to ask, test, document, and follow up.
Start with the Path, Not the Checklist
Accessibility work goes better when teams understand the path early instead of treating WCAG like a last-minute checklist.
What Accessibility Review Is Actually Looking For
Accessibility review is not a scavenger hunt for WCAG failures. It is a quality check on whether people can actually use the thing you built.
