This note turns the central question into concrete decisions, checks, boundaries, and ownership.
An audit can detect debt but cannot make every creative decision
Automated checks are valuable for missing labels, malformed structure, and some contrast failures. They cannot determine whether the reading order communicates the intended hierarchy, whether motion is necessary, or whether a complex interaction is worth its cognitive cost. These are direction decisions. Include accessibility criteria in the visual contract: type sizes, focus language, colour roles, motion policy, landmark structure, and how errors will be explained. The earlier those rules exist, the less likely accessibility becomes a visual compromise imposed at the end.
Build colour roles, not a pile of approved hex values
A palette may contain colours that pass in one pairing and fail in another. Define roles such as page background, primary text, muted text, action, warning, success, border, and focus. Test each permitted pair at the text size and weight where it will appear. Include hover, disabled, visited, validation, and selected states. Never rely on colour alone to distinguish state. In a high-contrast concept, verify the accent does not become unreadable when used for small text rather than large graphic fields.
Treat type scale as navigation
Large display typography creates character, but body text, labels, metadata, and controls carry orientation. Define a minimum body size, comfortable line length, and line height before composing dramatic headings. Ensure zoom to 200 percent does not hide actions or require horizontal scrolling. Long headings should wrap intentionally rather than shrink into illegibility. On narrow screens, preserve hierarchy with spacing and weight instead of attempting to reproduce desktop scale mechanically. A visitor should identify page, section, and next action without interpreting decoration.
Design keyboard behaviour with the interaction
Every interactive element needs an expected tab order, visible focus state, keyboard trigger, and escape route where relevant. Native elements usually provide the safest foundation. When a custom menu, filter, modal, or carousel is proposed, write its keyboard behaviour beside the visual sketch. Ask whether the interaction communicates something unavailable in a simpler structure. A dramatic website can remain accessible when animation and geometry support the sequence rather than controlling access to information.
Motion needs a reason and an alternative
Motion can clarify continuity, reveal a state change, or establish a transition. It can also delay reading, trigger discomfort, and create focus confusion. Identify the informational purpose of each motion pattern. Respect prefers-reduced-motion by removing nonessential translation, scaling, parallax, and autoplay. Do not replace motion with an abrupt state that loses context; provide a stable equivalent. Test with keyboard and reduced motion together, because focus can move while an animation is still rearranging the visual field.
Errors are content, not red borders
A form error should identify the field, describe the problem, and explain how to correct it. Associate the message programmatically and move focus only when that helps recovery. Preserve entered values. For a local-only prototype, state clearly that validation is local and nothing was transmitted. For a production endpoint, distinguish validation failure, network failure, duplicate submission, and successful receipt. A generic ‘something went wrong’ message hides operational information and leaves assistive technology users with no reliable next step.
Test structure without the visual layer
Read headings and landmarks as an outline. Navigate links and controls by keyboard. Inspect text at 200 and 400 percent zoom. Disable images and verify that alternatives preserve meaning. Review the page with CSS reduced or a reader mode to expose source-order problems. Use a screen reader for the key route and interaction, not merely the homepage. These tests are most useful before the direction is considered fixed, while the team can still change order and interaction without defending sunk effort.
Accessibility evidence belongs in launch ownership
Record what was tested, at which viewport and zoom, with which browser and assistive technology, and which limitations remain. Assign an owner for future content and component changes. A compliant snapshot can decay when a new campaign introduces poor contrast, a third-party widget changes, or an editor skips heading levels. Include accessibility in the maintenance schedule and release checklist. The goal is not a permanent badge; it is a visible practice for detecting and correcting barriers as the site changes.
Include cognitive load in composition review
A technically conforming interface can still demand too much interpretation. Review whether labels use familiar language, choices are grouped predictably, instructions appear before the action, and important consequences are visible at the point of decision. Avoid presenting several competing calls to action with equal weight. Break complex forms into meaningful groups only when the division helps orientation; unnecessary steps create memory burden. Test with someone unfamiliar with the project and ask them to narrate what they believe each action will do before activating it. A mismatch is a content and direction problem, not merely a usability note.
Plan media alternatives before production
When photography, diagrams, animation, audio, or video carry meaning, decide the alternative during storyboarding. Decorative media should be ignored by assistive technology; informative media needs concise alternatives; complex diagrams may require a nearby explanation or data table. Captions and transcripts need ownership and timing. Do not wait until upload to ask an editor for alt text without context. The team that selected the media understands its intended contribution and should record that purpose while the choice is fresh. If the same information is already adjacent, avoid forcing a screen-reader user through redundant description.
Review responsive order and reflow
Visual direction can place labels, notes, and imagery in separate columns whose source order becomes confusing when stacked. Inspect the DOM reading order early. At 400 percent zoom and narrow widths, require one-directional reflow without horizontal scrolling except for genuinely two-dimensional data with an accessible alternative. Ensure sticky regions do not consume the viewport and fixed controls do not cover content. If desktop relies on spatial association, add headings or grouping that preserve the relationship when position disappears. Reflow is not simply a media query; it is a test of whether the information architecture survives.
Create an accessibility acceptance record
Before implementation begins, list the critical routes, components, user flows, content formats, target browsers, assistive technologies, zoom levels, and reduced-motion conditions that will be reviewed. Assign owners and distinguish automated, manual, and user-informed checks. Record known dependencies that cannot be controlled. During release, log defects, severity, remedy, and retest evidence. This does not guarantee universal access, but it turns a broad value statement into accountable work and gives future maintainers a baseline when content, browser behaviour, or third-party services change.
Turn the method into a reviewable record
Apply the ideas in Accessibility Begins in Direction, Not in the Final Audit to one real route, decision, or update rather than discussing the entire website in the abstract. Record the current condition, the audience question, available evidence, responsible owner, proposed change, risk, and acceptance check. Attach screenshots or route lists where they clarify the record, but do not substitute visual evidence for an explanation. Ask a reviewer who did not prepare the record to identify the decision and reproduce the check. If they cannot, revise the language or evidence. Keep the record with the project source so a future maintainer can distinguish an intentional rule from an accidental implementation detail. This small discipline reduces repeated debate and makes later corrections safer.
Use a stop condition, not endless refinement
Define what would make the recommendation inappropriate, incomplete, or unsafe. A missing content owner, unverifiable claim, inaccessible interaction, unmapped legacy route, unknown data destination, or absent recovery path may be a reason to pause. Write who can resolve the condition and what evidence allows work to continue. This prevents schedules from converting uncertainty into silent assumptions. It also protects creative work: once the named conditions and acceptance checks pass, the team can stop polishing details that do not improve the audience decision. Review the condition after an ordinary publishing cycle, because real use may reveal a different constraint from the one imagined during design.
The useful standard is a decision somebody else can understand, test, and maintain.
Questions to carry into the project
- Which decision is this work meant to improve?
- What evidence is available now, and who can verify it?
- Which owner can maintain the result after launch?
- What condition should stop, revise, or reverse the release?