Accessibility belongs in design, implementation and testing. Treating it only as an audit at the end leaves important interaction decisions until the interface is already built. Planning them earlier does not remove the work, but gives the team a clear requirement to implement.
Specify it per component
The practical technique is to write the requirements alongside each component rather than as a policy document nobody reads.
For a button: the contrast pair for each state, the minimum target size, the focus indicator, and whether it is a real button element.
For a form field: the label association, where the error message lives, how the error is announced, and the relationship between the field and its description.
For a menu: the keyboard interaction, where focus goes when it opens and closes, and what is announced.
Recorded that way, the requirements are implemented as the component is built, and the audit at the end finds very little.
What automation catches, and what it does not
Automated checks are worth running in the pipeline. They can detect many missing labels, contrast failures and structural problems, but coverage depends on the tool and the states exercised. The W3C evaluation guidance explains why tools and human evaluation need to work together.
They cannot tell you whether the keyboard path through a flow makes sense, whether a screen reader announcement is useful rather than merely present, whether alternative text describes the right thing, or whether an interaction is operable under time pressure.
Both are needed. A site that passes every automated check can still be unusable.
The specifics that matter most
Keyboard operation. Everything reachable and operable, in an order matching the visual layout, with no trap. Test it by putting the mouse away for an hour.
Visible focus. Never removed. A focus outline deleted for visual reasons makes the interface unusable for keyboard users, and it is the most common single failure.
Target size. Small controls are hard for everyone and impossible for some. A comfortable minimum costs nothing in a layout designed around it and is painful to retrofit.
Contrast. Choose the pairs as design tokens and record them. Checking at the end and then adjusting colours breaks the visual system.
Colour never alone. Status shown only by hue fails for a colour vision difference and in bright light. Add a label, a shape or a position.
Motion. Honour the reduced motion preference. Where animation carries meaning, keep the meaning and remove the movement rather than removing the feature.
Errors. Associated with their field programmatically, announced when they appear, and specific about what is wrong.
Why it is better for everyone
The strongest argument is not compliance.
Large targets and high contrast can also help a technician working in bright sunlight. Keyboard operation helps people who cannot use a pointer and people who prefer it for repeated tasks. Captions make spoken information available when audio cannot be heard. These examples do not replace the needs of disabled users; they show that one access requirement can improve several working conditions.
Designing for the constraint produces an interface that holds up in the conditions where software is actually used, which is rarely a quiet office with a large screen.
The standard and the honest position
WCAG 2.2 level AA is the engineering target for this site. Legal and procurement requirements depend on the organisation and jurisdiction; a technical target is not a universal statement about compliance obligations.
Conformance is a claim, and a claim should be backed by testing rather than intention. Where something does not conform, say so and describe it rather than quietly hoping. An accessibility statement listing a known limitation is more credible than one claiming perfection.
Where it goes wrong
Two patterns account for most failures.
A component library adopted without checking its accessibility properties, which then propagates the same defect to every screen.
A design approved with a colour pair that cannot meet contrast, discovered in implementation, and resolved by shipping it anyway because the brand is fixed. Verify the actual pairs during design, including hover, error and dark mode states.
Walk through a failed form submission
Begin with the keyboard at the page start. Use the skip link, reach the form and submit it with required values missing. Check that the first error is discoverable, each message identifies its field and the entered values remain available for correction. A red border alone conveys neither the problem nor how to fix it.
Correct one field and submit again. The interface should remove the resolved error without clearing unrelated entries or sending focus somewhere unexpected. If the server rejects a value the browser accepted, the same error association needs to work for that response. Client validation is not the only state that users encounter.
Then simulate a network failure. The message should distinguish a failed submission from a successful one, preserve the draft and provide a usable next action. Do not announce success merely because the button was pressed. If a request is still pending, convey that state without an animation being the only indicator.
Repeat the path at a narrow viewport and with text enlarged. Check that a fixed banner does not cover the focused field or its error, and that controls do not require horizontal body scrolling. An intentionally scrollable table needs a separate keyboard reachable container and an understandable label.
For this design, ordinary standalone controls use a 48 pixel target. That is a project requirement, not a claim that every WCAG AA target has the same minimum. The WCAG target size criterion defines its own minimum and exceptions. State which rule a test enforces so a large visible button is not confused with a complete accessibility review.