What does an accessibility claim need to cover?
Define the product version, routes, roles, content and complete tasks included in the claim, then evaluate them against an agreed standard such as WCAG 2.2. Accessibility is not established by checking a homepage or component library alone. The scope must include the states and steps a person needs to finish the product's important journeys.
Map complete processes before sampling pages
List the tasks that matter: registering, signing in, recovering access, finding information, completing a form, paying, changing settings and getting help. Include every page, dialog and external step required to finish each task. W3C evaluation methodology treats complete processes as a unit because an inaccessible step can block the whole outcome.
State the boundary honestly
Record third-party widgets, documents, authenticated areas, languages and responsive layouts in scope. If part of the product has not been evaluated, say so rather than allowing a broad claim to imply otherwise. A standards-based review is valuable evidence, but standards also cannot represent every individual user's experience or need.
Which journeys, states and content should be sampled?
Choose representative pages and components, but always include complete critical journeys, shared templates and varied content. Test empty, loading, success, validation, permission, timeout and failure states as well as the ideal path. Include different roles, data volumes, viewport sizes and authentication conditions where they change what a user perceives or can operate.
Test content as part of the interface
Headings, link purpose, instructions, alternatives for images and plain error language affect whether the product makes sense. Generated, translated and user-entered content can create problems even when the component is sound. Sample the kinds of content that appear in production, including unusually long labels and records with missing optional information.
Include change over time
Open and close dialogs, add and remove items, sort results, submit forms and wait for asynchronous updates. Check whether focus moves deliberately and whether a screen reader receives useful announcements. A static page inspection will not reveal a focus lost after deletion or an important status change that is visible but never announced.
What can automated accessibility tools prove?
Automated tools can consistently find certain detectable failures, such as missing programmatic names, invalid relationships and some contrast issues. They are valuable in development and regression checks, but a clean report does not prove conformance or usability. Many requirements depend on meaning, sequence, context and human judgement, so automated results must be combined with manual evaluation.
Use automation early and repeatedly
Run checks in component development, page tests and deployed environments. Prevent known violations from returning and review tool output rather than accepting every warning mechanically. Automation provides fast coverage for rules it can inspect; it should reduce repetitive work so reviewers can spend more time on interaction and meaning.
Do not turn techniques into a checklist claim
W3C explains that techniques show recognised ways to meet success criteria, but passing selected techniques does not by itself establish that every applicable criterion is satisfied. Review the actual requirement and user outcome. A control can have a technical name yet remain ambiguous, or follow a pattern while becoming unusable in context.
Which manual and assistive-technology checks matter?
Use the product with a keyboard alone, visible focus, zoom and reflow, high contrast or forced colours where relevant, and representative screen-reader combinations. Check pointer alternatives, target size, motion, timing and media. The exact matrix should follow the product's platforms and users, with tests centred on completing tasks rather than demonstrating isolated controls.
Follow focus and meaning through the journey
Start at the browser chrome and complete the task without a pointer. Confirm that every control is reachable, the order follows the interface, focus remains visible and overlays do not trap or lose it. With a screen reader, inspect landmarks, headings, control names, state, errors and live updates while performing the same journey.
Check magnification and responsive behaviour
Zoom text and the page, narrow the viewport and use platform text-size settings where applicable. Important information and controls should remain available without destructive overlap or two-dimensional scrolling where the criterion disallows it. Test orientation and spacing changes. Responsive design can introduce a different navigation or control order that deserves its own review.
How should findings become a release decision?
Record each finding with the affected journey, standard criterion, user impact, evidence, environment and a reproducible path. Prioritise blockers to essential tasks and failures affecting several pages or components. Re-test fixes in context and run regression checks. A release decision should state unresolved limitations, ownership and remediation dates rather than collapsing accessibility into one score.
Combine standards evidence with user insight
Conformance evaluation and testing with disabled people answer related but different questions. Standards checks provide a repeatable technical baseline; research or usability sessions can reveal friction, workarounds and unmet needs that criteria do not fully express. Involve people with relevant access needs throughout design and testing rather than using one late session as certification.
Keep accessibility testable after launch
Store the journey inventory, manual scripts, tool configuration and known limitations with the product. Add checks when a defect escapes and review accessibility when shared components, content systems or third-party services change. Twofold can help teams build accessibility into product acceptance so evidence grows with the system instead of being recreated before each release.