Browse by Topic

Use this page when you have a practical accessibility question and do not want to start with WCAG numbers.

The Accessibility Field Guide is organized around project moments: a request is getting shaped, a screen needs a quick check, a form is confusing, a vendor tool is coming in, or a component is behaving in a way people may not expect.

Start with the issue you are seeing.

Then follow the smallest useful path.

If you are new to the guide

Start here when you need the map before the details.

• How to Use This Guide — choose the right entry point for the moment you are in.
• Accessibility Glossary — look up common terms without starting from standards language.
• Accessibility Skill Tree — see the kinds of accessibility judgment people build over time.
• WCAG 2.1 A/AA Map — connect practical issues back to WCAG 2.1 A and AA.

If the work is still being shaped

Use this route before design, development, vendor selection, or review expectations have hardened.

• Intake Accessibility Questions — ask better questions before accessibility risk becomes rework.
• Intake Accessibility Questions Checklist — turn intake into a quick working prompt.
• Accessibility Requirements Checklist — turn accessibility risks into requirements and acceptance criteria.
• Review Readiness — understand what should be ready before formal review.
• Review Readiness Checklist — check whether the work is ready to send forward.

If you are checking a form or data-entry flow

Use this route when someone has to enter, review, correct, or submit information.

• Forms and Labels — check labels, instructions, required fields, grouping, and form structure.
• Error Messages and Recovery — make errors easy to find, understand, and fix.
• Form Review Checklist — run a practical pass through a form or flow.
• Status Messages and Alerts — check confirmations, errors, alerts, and live updates.

If keyboard or focus behavior might break the path

Use this route when a screen has dialogs, menus, tabs, dynamic content, custom controls, or multi-step movement.

• Keyboard-Only Navigation — check whether someone can complete the task without a mouse.
• Focus Visible and Focus Order — check whether focus is visible and moves in a logical order.
• QA Keyboard Check — use a no-mouse QA pass.
• Modals and Dialogs — check focus movement, escape paths, and background interaction.
• Status Messages and Alerts — check whether dynamic updates are announced when needed.

If the issue is visual meaning, structure, or content

Use this route when people need to understand a page from headings, text, images, color, tables, or layout.

• Headings and Page Structure — make the page easier to scan and navigate.
• Link Text and Button Labels — make control text clear out of context.
• Alt Text Basics — decide what image meaning needs to be available as text.
• Color Contrast — check whether text and interface elements have enough contrast.
• Color-Only Meaning — avoid making color the only way to understand status or choice.
• Tables and Data Displays — make data relationships easier to understand.

If the issue is a control or component

Use this route when the question is about what a control is, how it should behave, or whether ARIA is helping.

• Native HTML First — start with the browser behavior that already exists.
• Button vs Link — choose the control type based on what activation does.
• Accessible Names — make sure controls have names people and assistive technology can use.
• Name, Role, and Value — check whether a component exposes what it is and what state it is in.
• ARIA Is Not Duct Tape — use ARIA to describe working behavior, not hide broken behavior.
• Developer Component Checklist — run a practical component handoff/build check.
• Accordions — check show/hide sections.
• Combobox — check searchable/selectable inputs.
• Tabs — check tabbed interfaces.

If a vendor or third-party tool is part of the experience

Use this route when a product, widget, platform, document generator, embedded service, or vendor workflow will affect users.

• Vendor and Third-Party Accessibility Field Guide — understand the risk and ownership questions.
• Vendor Accessibility Questions Checklist — ask what the evidence covers, what remains unknown, and who owns follow-through.

Supporting notes:

• A VPAT Is Not a Magic Shield
• Accessibility Evidence Should Match the Thing You’re Shipping
• Ask Vendors How Accessibility Works in Your Configuration

If you need the checklist version

Use Checklists and Job Aids when you want the working prompts instead of the explanatory pages.

A good pattern is:

1. Read the topic page when the team needs context.
2. Use the checklist when the team needs a practical pass.
3. Use the WCAG map when the team needs the standard behind the issue.

What to do next

• If you are deciding where to start, read How to Use This Guide.
• If you need a quick working aid, use Checklists and Job Aids.
• If someone uses a term that is slowing the conversation down, use the Accessibility Glossary.
• If you need the WCAG connection, use the WCAG 2.1 A/AA Map.