Skip to main content
Accessibility Field Guide

How to Use This Guide

A practical pathfinding page for using the Accessibility Field Guide for immediate work, learning, training, and common accessibility review moments.

A trail sign showing different route directions.
Photo: Hiking Sign Showing Different Routes via Pexels — https://www.pexels.com/photo/hiking-sign-showing-different-routes-20543807/
View full screen Download image

You do not need to read the Accessibility Field Guide in order.

Actually, it is probably better if you do not.

Accessibility work rarely shows up in a neat order. Sometimes you are shaping a request. Sometimes you are writing acceptance criteria. Sometimes you are staring at a form error. Sometimes someone asks whether a vendor widget works with a keyboard. Sometimes you are looking at a WCAG number and wondering what it means in normal human language.

Use the path that matches the problem in front of you. If you are here for learning, use the guide as a small practice map instead of a course you have to finish all at once.

If you want the mindset behind that structure, read Start with the Path, Not the Checklist. It explains why the guide is organized around paths and decisions instead of treating accessibility like a last-minute checklist.

If you are new to the guide

Start with the Accessibility Field Guide landing page.

That page gives you the main entry points: Start here, Intake, Requirements, common screen and workflow checks, Review, Checklists, and the WCAG Map. It is meant to help you find the right doorway without turning the guide into a table of contents for every page.

If you want a learning map, use the Accessibility Skill Tree. The skill tree is a personal map, not a report card. It can help you see the different kinds of accessibility understanding people build over time.

Nobody starts with the whole map unlocked.

If you are learning accessibility over time

Start with the Accessibility Skill Tree.

Use it as a map of the kinds of judgment people build over time: noticing risk earlier, writing clearer requirements, checking forms and workflows, understanding keyboard and focus behavior, and knowing when WCAG or specialist review needs to come into the conversation.

Then pick one practical page connected to the work you already do. A good first route is:

  1. Forms and Labels
  2. Keyboard-Only Navigation
  3. QA Keyboard Check
  4. Accessibility Requirements Checklist
  5. WCAG 2.1 A/AA Map when you need the standard behind the issue

For team training or onboarding, pick one current screen, form, or workflow and walk through one guide plus one checklist. The goal is not to memorize the whole collection. The goal is to build the habit of asking better questions earlier.

If the request is still early

Start with Intake.

This is the best place when the work is still flexible enough to shape. Use it when a request is being clarified, a vendor tool is being considered, or a team is trying to understand where accessibility risk might show up later.

The main guide here is Intake Accessibility Questions. It helps teams ask better questions before design, development, and review decisions harden.

If you are writing requirements or acceptance criteria

Start with Requirements.

A lot of accessibility rework starts when the happy path is documented, but the actual behavior is not. Look for missing states, error paths, keyboard expectations, document needs, vendor assumptions, content decisions, and what should happen when the user cannot follow the happy path.

The main working aid here is the Accessibility Requirements Checklist.

If you are reviewing a form, flow, or screen

Start with the pages that match the thing in front of you:

  • If the work is a form or data-entry flow, use Forms and Labels, Error Messages and Recovery, and the Form Review Checklist.
  • If the work has keyboard movement, focus behavior, dialogs, or dynamic updates, use Keyboard-Only Navigation, Focus Visible and Focus Order, Modals and Dialogs, and Status Messages and Alerts.
  • If the work depends on visual meaning, images, charts, dashboards, or dense data, use Color Contrast, Color-Only Meaning, Alt Text Basics, and Tables and Data Displays.
  • If you are doing a no-mouse QA pass, use the QA Keyboard Check.

This route is useful when a page asks someone to enter information, move through a task, recover from mistakes, understand a status, read a table, or complete work without a mouse.

Design and QA decisions often define accessibility behavior before anyone calls it accessibility behavior. That includes labels, instructions, required fields, error messages, focus states, tab order, status updates, visual cues, and what happens when content changes.

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

Start with the Vendor and Third-Party Accessibility Field Guide.

Vendor evidence is useful, but only when it matches the version, configuration, workflow, and documents your users will actually touch. The Vendor Accessibility Questions Checklist gives teams a practical way to ask what the evidence covers, what remains unknown, and who owns follow-through.

If the work is getting close to review

Start with Review.

This section is for catching obvious issues, gathering evidence, and reducing avoidable rework before formal review starts. It does not replace official review. It gives the team a chance to fix the things they can catch themselves.

Use Review Readiness when you need the concept, and Review Readiness Checklist when you need a practical pass through the work.

If you need a checklist

Start with Checklists.

That page collects the working aids in one place: intake, requirements, review readiness, form review, and keyboard QA. Use it when you do not need a full explanation and just want something to work through.

If you are looking up a WCAG criterion

Start with the WCAG 2.1 A/AA Map.

The map gives every WCAG 2.1 Level A and AA success criterion a place in the guide.

The goal is not to rewrite WCAG. The goal is to connect each criterion to plain-language explanations, common work patterns, examples, roles, and checklists.

If you are not sure where to start

Start with one question:

What accessibility decision would be expensive if we waited until review to discover it?

That question usually points toward the right part of the guide.

If the decision is still forming, go to Intake. If it needs to become acceptance criteria, go to Requirements. If the work is close to handoff or formal review, go to Review. If you need a practical working aid, go to Checklists. If you need the standard behind the issue, go to the WCAG Map.

The collection is here when the topic becomes relevant to the work in front of you.

  • Accessibility Glossary — for plain-language definitions of common accessibility terms used across this guide.

What to do next