What makes a website accessible?

That people can perceive, operate and understand it regardless of how they are using it — with a keyboard, with a screen reader, with magnification, with limited colour perception, with reduced motion, or simply on a small screen in bright sunlight. In practice that comes from semantic structure, operable components, sufficient contrast, clear content and honest error handling.

The Web Content Accessibility Guidelines, published by the W3C. They organise success criteria under four principles — perceivable, operable, understandable and robust — across conformance levels A, AA and AAA. AA is the level most organisations and procurement processes reference. Confirm the current version and the criteria that apply to your situation directly with the W3C.

Is accessibility only about screen readers?

No. Screen reader users are one group among many. Keyboard-only users, people with low vision or colour blindness, people with motor impairments, people sensitive to motion, people with cognitive differences, and anyone temporarily impaired by a broken arm, a bright screen or a bad connection all benefit from the same work.

Can automated tools make a website accessible?

No. Automated checkers find a meaningful subset — missing alternative text, insufficient contrast, absent form labels, invalid ARIA — but they cannot judge whether alternative text is useful, whether focus order is logical, or whether a custom component behaves correctly. Overlay widgets that promise instant compliance are not a substitute for building the site properly.

What is keyboard accessibility?

That every interactive element can be reached and operated without a mouse: tab moves through controls in a sensible order, focus is always visible, enter and space activate controls, escape closes overlays, and focus is never trapped anywhere the user cannot leave.

Does accessibility limit design?

It constrains a few specific decisions — contrast, target size, focus visibility, motion — and those constraints tend to improve the design rather than dilute it. What it genuinely rules out is decoration that depends on colour alone, invisible focus states and controls too small to hit reliably.

When should accessibility testing happen?

Continuously. Component-level checks as components are built, keyboard passes on each significant flow, automated checks in the build pipeline, and assistive-technology review before release. A single audit at the end finds the same problems far later and far more expensively.

Accessibility

Accessibility as part of website architecture

Accessibility is decided in structure, components and content — long before anyone runs a checker. Treated as a final audit, it becomes a list of defects instead of a property of the build.

John M GranskouAugust 22, 202612 min read

Accessibility work arrives late in most projects: the interface is built, a checker is run, and a list of defects appears. Some are fixed, the awkward ones are deferred, and the site ships knowing it excludes people. The problem is not effort or intent. It is that by then most of the decisions that determine accessibility have already been made.

Accessibility begins in architecture

Consider a common example. A designer specifies a set of expanding panels. A developer builds them from generic containers with a click handler. It looks correct and works with a mouse. It cannot be reached by keyboard, its state is invisible to assistive technology, and no colour change will fix that.

Retrofitting the correct roles, states and keyboard behaviour afterwards costs several times more than choosing the right elements would have. Multiply that across a component library and the pattern is clear: accessibility is cheap when it is structural and expensive when it is remedial.

Structure → components → content → interaction

Each layer inherits the decisions of the one beneath it. Fixes applied at the top cannot repair the bottom.

Semantic HTML

The single highest-value practice in accessibility is using the element that already means what you intend. A button is a button, a link navigates, a list is a list, a form control has a label, and landmarks describe the regions of the page. Browsers and assistive technologies already know how these behave.

ARIA exists to describe things HTML cannot express. It is a supplement, not a repair kit — and incorrect ARIA is measurably worse than none, because it asserts a behaviour the component does not have.

Heading hierarchy

Headings are the document outline, and many screen reader users navigate by them before reading anything. One h1 per page describing what the page is, then h2 for each major section and h3 beneath it, without skipping levels. Heading level is structure; visual size is a separate decision handled in the design system.

Everything operable by mouse must be operable by keyboard. Tab order should follow the visible reading order, which means it depends on the order of the markup rather than the order things happen to appear after CSS has rearranged them. A skip link should let a keyboard user bypass the navigation. Escape should close what it opened.

Focus management

Focus is the keyboard user's cursor, and losing track of it is disorienting. It must always be visible — removing the outline without replacing it with something clearer is one of the most damaging single lines of CSS on the web. When a dialog opens, focus moves into it and is contained there until it closes, at which point it returns to whatever opened it.

Forms and labels

Every control has a real, programmatically associated label — placeholder text is not a label.
Related controls are grouped, so the question a radio set answers is announced with the options.
Required fields and expected formats are stated before submission, not discovered through failure.
Errors are described in text next to the field, and identify what to do rather than only what is wrong.
Focus moves to the first error, or to a summary that links to each one.

Colour and contrast

Contrast requirements apply to text, and also to the parts of the interface that carry meaning: focus indicators, form borders, icons that convey state, chart keys. Colour must never be the only carrier of information — an error is not red, it is a message that happens to be red.

Images and alternative text

Alternative text answers what the image contributes here, not what it depicts in general. Decorative images should be marked as decorative so they are skipped rather than announced as a filename. Informative graphics — diagrams, charts, schematics — need their meaning in text, either as alternative text or as an adjacent description.

Motion and reduced-motion preferences

Motion can cause genuine physical discomfort. Respect the operating-system reduced-motion preference: keep the state change, remove the movement. Never use motion as the only way of communicating that something has changed, and avoid anything that moves continuously without a way to stop it.

Interactive components

Custom components are where most serious accessibility failures live: menus, tabs, accordions, modals, carousels, comboboxes, custom selects. Each has an expected keyboard interaction pattern and an expected set of roles and states. Build them once, correctly, in the design system — then every use of them inherits the work.

Error messages

An error must be perceivable, understandable and reachable. Announced to assistive technology when it appears, written in plain language, placed with the control it concerns, and specific about the correction required. "Invalid input" satisfies none of those conditions.

Touch targets

Controls need enough physical area to be hit reliably, with enough separation that adjacent targets are not triggered by accident. This is a motor-accessibility requirement and, incidentally, one of the most reliable mobile conversion improvements available.

Screen readers

Screen reader output is generated from the markup. If the structure is sound, the announcement usually is too. Test with at least one real combination rather than relying entirely on inspection, and check the flows that matter: navigation, forms, search, and any custom component.

Automated testing versus manual testing

Automated tools are valuable and limited. They catch machine-detectable failures consistently — missing labels, insufficient contrast, invalid ARIA — and industry testing repeatedly finds that this is a minority of real accessibility barriers rather than most of them.

Automated, keyboard and human review

Automated checks

In the pipeline, on every change

Why

Reliably finds missing labels, contrast failures, invalid ARIA and structural errors — a minority of real barriers, caught consistently and cheaply.

Keyboard pass

Every significant flow, no mouse

Why

Finds unreachable controls, illogical focus order, focus traps and invisible focus states — none of which an automated tool can judge.

Screen reader and human review

Before release, on the core journeys

Why

Finds misleading announcements, unhelpful alternative text, unlabelled state changes and flows that are technically valid but incomprehensible.

Three layers, three different classes of defect. None of them substitutes for another.

Method	Reliably catches	Cannot judge
Automated checks	Missing labels, contrast, invalid ARIA, structural errors	Whether anything makes sense in use
Keyboard pass	Unreachable controls, focus traps, illogical order, invisible focus	How content is announced
Screen reader review	Misleading announcements, unlabelled state, broken components	Cognitive load and clarity
Human review	Confusing flows, unhelpful alternative text, unclear errors	Nothing — but it does not scale to every page

What each layer of testing is actually good at.

Accessibility and editorial workflow

Most accessibility is published, not coded. Editors add images, write links, choose headings and paste content every week. The content system should make the accessible option the easy one: require alternative text, offer a decorative option, constrain heading levels to the document outline, and warn on link text that says nothing. That is a content-model decision, described further in CMS architecture.

Accessibility needs maintenance

An accessible site drifts. A new component ships without keyboard support, a brand refresh drops contrast below threshold, a third-party embed arrives with none of it. Keep automated checks in the build, keyboard-test each significant change, and review the core flows periodically — the same discipline that protects performance.

Applications carry additional burden, because state changes without a page load and must still be announced. That work sits inside application and PWA development rather than being a separate exercise bolted on afterwards.

Accessibility built into the architecture is nearly invisible. Accessibility added at the end is a list of defects with a deadline attached.

Frequently asked questions

What makes a website accessible?: That people can perceive, operate and understand it regardless of how they are using it — with a keyboard, with a screen reader, with magnification, with limited colour perception, with reduced motion, or simply on a small screen in bright sunlight. In practice that comes from semantic structure, operable components, sufficient contrast, clear content and honest error handling.
What is WCAG?: The Web Content Accessibility Guidelines, published by the W3C. They organise success criteria under four principles — perceivable, operable, understandable and robust — across conformance levels A, AA and AAA. AA is the level most organisations and procurement processes reference. Confirm the current version and the criteria that apply to your situation directly with the W3C.
Is accessibility only about screen readers?: No. Screen reader users are one group among many. Keyboard-only users, people with low vision or colour blindness, people with motor impairments, people sensitive to motion, people with cognitive differences, and anyone temporarily impaired by a broken arm, a bright screen or a bad connection all benefit from the same work.
Can automated tools make a website accessible?: No. Automated checkers find a meaningful subset — missing alternative text, insufficient contrast, absent form labels, invalid ARIA — but they cannot judge whether alternative text is useful, whether focus order is logical, or whether a custom component behaves correctly. Overlay widgets that promise instant compliance are not a substitute for building the site properly.
What is keyboard accessibility?: That every interactive element can be reached and operated without a mouse: tab moves through controls in a sensible order, focus is always visible, enter and space activate controls, escape closes overlays, and focus is never trapped anywhere the user cannot leave.
Does accessibility limit design?: It constrains a few specific decisions — contrast, target size, focus visibility, motion — and those constraints tend to improve the design rather than dilute it. What it genuinely rules out is decoration that depends on colour alone, invisible focus states and controls too small to hit reliably.
When should accessibility testing happen?: Continuously. Component-level checks as components are built, keyboard passes on each significant flow, automated checks in the build pipeline, and assistive-technology review before release. A single audit at the end finds the same problems far later and far more expensively.