Start with the Path, Not the Checklist

Most accessibility rework does not happen because people do not care.

It happens because the right questions show up too late.

• A team builds the screen.
• The workflow feels mostly done.
• The deadline is close.
• Then accessibility enters the conversation as a checklist, a scan, or a review finding.

By that point, every issue is more expensive than it needed to be.

Not always technically difficult.

Just late.

• A missing label is easier to prevent when the form is being designed.
• A keyboard trap is easier to catch when the interaction is being built.
• A confusing error message is easier to improve when the requirement is still being shaped.
• A PDF is easier to plan accessibly before it becomes the final artifact everyone depends on.

That is why the Field Guide is built around a path, not just a checklist.

A checklist is useful.

But a checklist is not the whole practice.

Accessibility works better when teams understand where they are in the lifecycle and what kind of questions belong there.

Early on, the question is not:

Did we pass accessibility review?

The better question is:

Have we made the decisions that will make an accessible outcome possible?

That means asking things like:

• Who needs to use this?
• What are they trying to complete?
• What could block someone from completing it?
• Are the requirements specific enough to test?
• Are labels, instructions, errors, and status messages accounted for?
• Can the workflow be completed with a keyboard?
• Are we depending on color, layout, or visual cues alone?
• Will documents, attachments, or third-party tools create accessibility risk?
• What should we catch internally before formal review?

None of those questions require everyone on the team to become a WCAG expert.

That is not the goal.

The goal is shared literacy.

When business analysts, product owners, designers, developers, testers, vendors, and reviewers have a common map, accessibility stops feeling like a surprise at the end.

It becomes part of how the work is shaped.

The Field Guide is organized around that idea.

• If you are new to accessibility, start with the broad path.
• If you are writing requirements, focus on making accessibility testable earlier.
• If you are preparing for review, look at intake, evidence, and common issues.
• If you need specific criteria, use the WCAG map.
• If you need repeatable steps, use the checklists.

The point is not to memorize everything.

The point is to know where you are, what questions to ask next, and what kind of risk you are trying to reduce.

Accessibility review should not be the first time a team discovers preventable issues.

It should be a quality check on work that has already been thinking about people from the beginning.

Start with the path.

The checklist will make more sense once you know where you are.