Accessible web design is the meaning and operability that remain when somebody cannot use the page exactly as its designer imagined. The mouse is unavailable. Images fail. JavaScript is delayed. The viewport is small. Vision, movement, hearing or cognition changes the route.
If the page’s structure disappears with the ideal conditions, the interface was performing accessibility rather than providing it. My test is not “does the site have an accessibility plugin?” It is this:
Can different users and clients understand the same structure and complete the same important task?
TL;DR
- Start with native HTML for the jobs it already expresses; add ARIA only for what the native element cannot say.
- Fix the repeated component, not the page, and write its meaning contract down.
- Headings are navigation, links go somewhere, buttons do something, and alt text follows the image's job.
- Test the highest-value complete journey under failure conditions, and require evidence from the live build.
Begin with native meaning
Use native HTML for the jobs it already expresses. A heading should be a heading. A navigation link should have an href. A button should perform an action. A form control should have a programmatically connected label.
W3C accessibility guidance recommends informative titles, headings that convey meaning and structure, meaningful links, text alternatives, captions or transcripts, clear instructions and concise content (W3C WAI: writing for accessibility). Those choices create relationships that browsers and assistive technologies can expose.
ARIA is valuable when native HTML cannot express a component’s state or relationship. It is not repair paste for an interface assembled entirely from generic containers. I use the Native Meaning Rule: begin with the element whose built-in behaviour matches the task; add ARIA only for information the native element cannot communicate. This is not aesthetic conservatism. It reduces the amount of custom behaviour the team has to recreate, test and maintain.
Fix the component and let the improvement multiply
One defective card, form or modal can spread across hundreds of pages. A one-off page repair matters. A design-system repair changes the source of the defect. Audit the repeated components first:
For each component, define what must be explicit. I call this the Component Meaning Contract. It turns accessibility from a list of page defects into a maintained design-system responsibility.
| Contract field | What must be explicit |
|---|---|
| Element choice | Native element or justified custom role |
| Keyboard behaviour | Keys, order and expected action |
| Focus | Entry, visible position, trapping and return |
| Accessible name | What the component is called |
| State | Expanded, selected, invalid, busy or unavailable |
| Error recovery | What failed and how to fix it |
| Fallback | What remains when scripts or media fail |
| Route | Whether the state needs a stable URL |
Headings are navigation, not font sizes
Headings should describe the subject, question or decision inside a section. “Delivery and returns”, “Who this service is for” and “What the quotation excludes” let somebody move directly to the needed information. Six sections called “More information” do not.
W3C explains that headings communicate content organisation and can support in-page navigation (W3C WAI: headings). Preserve the hierarchy on mobile instead of flattening it because the visual scale changes. This is not about earning a green SEO tick. It is about making the same organisation of meaning available outside the visual composition.
My rule is that every heading should still help when read as a plain outline without the surrounding layout. If the outline becomes a sequence of slogans, the page is forcing people to inspect every section to discover its job.
Links go somewhere; buttons do something
Links navigate to resources. Buttons change state or perform an action. The difference affects keyboard behaviour, browser controls, assistive-technology announcements and crawl discovery. Google generally discovers links through anchor elements with resolvable href values (Google: crawlable links). A generic element with a JavaScript click handler can look like navigation while providing a brittle route.
Use meaningful link text. “Read the boiler installation process” survives extraction better than five identical “learn more” links. Use buttons for actions such as submitting a form, opening a filter or changing a view. Styling can make either control look appropriate. Semantics should still describe what will happen.
I use a Destination-or-Action Test. If activation takes the user to another resource, start with a link. If it changes the current interface or submits an action, start with a button.
Forms are where inclusion becomes revenue
A service page can attract the right visitor and lose them at the final control. Forms need visible labels, clear instructions, suitable input types, accessible errors, predictable focus and a confirmation explaining what happens next. Placeholder text is not a durable label. It disappears when somebody types and may fail to explain the expected format. An error communicated only through red colour does not show how to recover.
Test the complete journey by keyboard:
- Reach every control in a sensible order.
- Identify the current focus position.
- Understand requirements before submission.
- Trigger and correct validation errors.
- Submit without a mouse.
- Receive a useful confirmation.
- Recover entered information where a correctable error occurs.
Prioritise quotation, booking, checkout and contact routes before polishing obscure archive pages. Accessibility is not only a compliance inventory. It removes barriers from the tasks the business depends upon. My commercial priority is simple: test the highest-value complete journey, not merely the easiest component to score.
Images require an editorial decision
An informative image needs a text alternative that communicates its relevant purpose. A decorative image should usually be ignored by assistive technology. If substantial text or evidence exists only inside an image, provide the useful information accessibly. Ask one question: what information disappears when this image fails?
If the answer is nothing, the image may be decorative. If a product feature, chart finding, process step or evidence item disappears, provide an equivalent appropriate to the context. Google says alt text helps people using screen readers and helps search engines understand images in context (Google: image SEO). That does not make the field a place for keyword repetition.
I call this the Information Loss Test. Alt text follows the image’s job in the page, not a universal description quota.
JavaScript should improve the route, not hide it
Tabs, filters, infinite scroll and load-more interfaces require explicit decisions. Which states need stable URLs? Which content must be discoverable? Can keyboard and screen-reader users operate the control? Is newly loaded content announced? Does focus remain sensible? Can somebody share or return to the state?
Google notes that it generally does not click buttons to trigger additional page loading during crawling, so incrementally loaded content intended for discovery needs crawlable routes (Google: pagination and incremental loading). Progressive enhancement provides the core information and route first, then lets JavaScript improve the interaction.
My boundary is not “avoid JavaScript”. It is do not make a custom interaction the only doorway to important meaning without testing who and what can operate it.
Not sure which of your components would survive a keyboard, a small screen or a failed script? We audit the repeated components and the journeys that earn money first.
Test failure states, not only ideal use
Check priority journeys at 200% zoom, by keyboard, on a small screen and with images or scripts delayed. Use automated tools to find repeatable defects, then perform manual task testing because a passing scanner cannot prove that the journey makes sense. The first commercial sample should include:
- homepage and primary navigation;
- a high-value service or category page;
- search, filters or product selection;
- a proof page such as a case study;
- the main enquiry, booking or checkout route;
- contact and support access.
Record what the barrier prevents rather than only the rule it violates. “The quotation form has no accessible error recovery” gives the team a user, task and place to repair. “Accessibility score: 82” mostly gives it a number.
I use a Barrier Consequence Record with four fields: affected user condition, blocked task, responsible component and required recovery. That makes prioritisation intelligible beyond the audit team.
Require evidence from the live build
Design files and staging promises are not what users receive. The rendered production output is the product. Before sign-off, require evidence for:
Re-test after theme, plugin and component-library updates that can alter output. A design-system token can improve contrast across the estate; a new component version can also reintroduce a barrier everywhere at once.
Keep the evidence attached to a release and representative URL. A screenshot of a perfect component in isolation does not prove that content editors used it correctly, that production CSS preserved it or that the complete journey remains operable. Component evidence and journey evidence answer different questions; require both where the task is commercially important.
My final component question is blunt:
If CSS, images, JavaScript, a mouse or perfect vision is unavailable, does this component expose enough meaning and control to complete its job?
It need not behave identically under every condition. It should remain understandable, operable and recoverable. Build that resilience into the component system and the website becomes less brittle for users, search engines and the team expected to maintain it.
Good to know
FAQs
No. A plugin cannot supply structure the page never had. The test is whether different users and clients can understand the same structure and complete the same important task when the mouse, images or scripts are unavailable.
Only when native HTML cannot express a component’s state or relationship. Begin with the element whose built-in behaviour matches the task, then add ARIA for the information the native element cannot communicate.
The highest-value complete journeys: the homepage and navigation, a key service or category page, search or product selection, a proof page, the main enquiry or checkout route, and contact access. Fix the repeated component rather than one page.
Ask what information disappears when the image fails. If nothing, the image may be decorative. If a product feature, chart finding or process step disappears, provide an equivalent. Alt text follows the image’s job, not a keyword quota.
Next step
Want to know what your site looks like when the interface stops cooperating?
We audit repeated components and the journeys that matter commercially, then record each barrier as a user, a blocked task and a repair.