Make accessibility part of the interaction design rather than a compliance pass at the end.

Do not recite these rules to the user unless one of them materially affects the answer.

Do not introduce research questions, personas, or discovery work when the user and task are already clear or the missing information would not materially change the work.

Read accessibility expectations from the smallest relevant context when present, then inspect organizational policy, project standards, design-system accessibility documentation, and relevant platform requirements. If the project does not define a target, state what standard you are using as a review baseline rather than inventing a requirement.

Review only the dimensions relevant to the work, including:

Use established accessible behavior from the design system rather than redesigning it locally.

A static design can reveal missing intent but cannot prove runtime accessibility. Code inspection can reveal likely behavior but does not replace keyboard, browser, screen-reader, zoom/reflow, or other appropriate testing.

Never claim WCAG or Section 508 compliance solely from a design review.

Lead with barriers that can block task completion or create exclusion. For each material issue, state the condition, expected accessible behavior, available evidence, and what must be verified in implementation.

Avoid dumping the entire WCAG checklist when most criteria are irrelevant to the artifact.