Accessibility & Inclusive Design: Building Websites for Everyone

Over 1.3 billion people worldwide live with some form of disability — that is roughly 16% of the global population, according to the World Health Organisation. Visual impairments, motor limitations, cognitive differences, hearing loss: the range of needs that a modern website must serve is far broader than most teams account for during design.

Beyond the human case, there is a legal and commercial one. The European Accessibility Act comes into full force in 2025 across EU member states. In the United States, the ADA has been applied to websites through decades of litigation. Australia, the UK, and Canada have equivalent legislation. An inaccessible website is not just a UX failure — it is a liability.

And the commercial case is straightforward arithmetic. Disabled users, their families, and their caregivers represent enormous purchasing power — estimated at over $13 trillion globally. When your product excludes them, you are voluntarily walking away from that market.

The deeper point, however, is that accessibility improvements benefit everyone. Captions help people watching in noisy environments. High-contrast text is easier to read in bright sunlight. Keyboard navigation benefits power users. Voice interfaces help parents with their hands full. Designing for the edges makes the centre better. This is the core insight of inclusive design — it is not about building a special version for people with disabilities. It is about building one version that works for everyone.

The Web Content Accessibility Guidelines (WCAG) are the internationally recognised standard for web accessibility, maintained by the W3C. The current version, WCAG 2.2, organises its requirements around four core principles remembered by the acronym POUR:

Perceivable — Information must be presented in ways that users can perceive. This means providing text alternatives for images, captions for video, sufficient colour contrast, and content that can be resized without loss of functionality. If a user cannot perceive your content through at least one of their senses, the content effectively does not exist for them.

Operable — Interface components must be operable by all users. Everything that can be done with a mouse must also be achievable with a keyboard alone. Interactive elements need to be large enough to activate reliably. Users who navigate slowly or who need more time to read must not be timed out of critical workflows without warning.

Understandable — Content and operation must be understandable. This means plain language over jargon, consistent navigation patterns, clear error messages, and forms that tell users what they did wrong and how to fix it — not just that something went wrong.

Robust — Content must be robust enough to be interpreted by a wide variety of assistive technologies. This means writing clean, semantic HTML so that screen readers, Braille displays, and voice interfaces can make sense of your content reliably.

WCAG has three conformance levels: A (minimum), AA (standard requirement for most legislation), and AAA (enhanced). Most accessibility regulations require AA conformance. Building to AA means passing 50 specific success criteria across the four POUR principles.

This sounds daunting. In practice, following a handful of core patterns gets you most of the way there — and modern tooling makes it easier than ever to catch violations before they ship.

Visual accessibility is where most teams start — and where most teams stop, after adding a few alt text tags and calling it done. The visual layer is more nuanced than it first appears.

Colour Contrast WCAG 2.2 requires a contrast ratio of at least 4.5:1 between text and its background for normal-sized text, and 3:1 for large text (18pt or 14pt bold and above). This is not an arbitrary number — it is calibrated to ensure readability for people with moderate vision loss and for sighted users in suboptimal lighting conditions.

The most common failure: light grey text on white backgrounds. This pattern is aesthetically common in modern design but frequently fails the 4.5:1 threshold. A simple check with a contrast checker (WebAIM's contrast checker is free and takes seconds) will tell you immediately.

Importantly, colour must never be the sole means of conveying information. If your form validation only turns the input border red to indicate an error, users who cannot distinguish red from other colours will not know something went wrong. Add an icon, a text label, or both.

Typography for Readability Body text should be a minimum of 16px. Smaller sizes are technically allowed by WCAG but create unnecessary friction, particularly for users with dyslexia or age-related vision changes. Line height of 1.5 and letter spacing of 0.12em for body text significantly improve readability for users with cognitive disabilities.

Avoid justified text. The irregular spacing between words creates a 'rivers of white' pattern that is disorienting for users with dyslexia. Left-aligned text with consistent spacing is always the more accessible choice.

Focus Indicators Every interactive element — links, buttons, form inputs — must have a clearly visible focus state for keyboard users. The WCAG 2.2 minimum is a focus ring with a 3:1 contrast ratio against the adjacent colours. Removing the default browser focus outline with outline: none without replacing it is one of the most common and damaging accessibility mistakes in modern web design.

A screen reader does not see your visual design. It reads the HTML structure and announces it to the user. If your HTML is semantically correct, the screen reader experience is good. If your HTML is a collection of div and span elements with click handlers, the screen reader experience is close to unusable.

The rules are simpler than they sound:

Use the right element for the job. Navigation should be a nav element. The main content of a page should be wrapped in main. A list of items should be a ul or ol, not a series of divs. Buttons that trigger actions should be button elements, not div elements with onClick handlers. Links that navigate to URLs should be a elements, not buttons.

Why does this matter in practice? Because the browser and assistive technologies understand the semantics of native elements automatically. A button element is keyboard-focusable by default, can be triggered with Enter and Space, is announced as 'button' to screen reader users, and responds correctly to disabled states. A div with an onClick handler does none of these things without custom code — and that custom code is rarely complete.

Heading Hierarchy Headings communicate document structure. An h1 is the page title. h2 elements are major sections. h3 elements are subsections of h2 sections. Skipping heading levels — jumping from h1 to h4 — creates a navigation nightmare for screen reader users who use heading lists to skim pages.

ALT Text Every image that conveys information needs descriptive alt text. The description should convey what the image communicates, not just describe it literally. A chart showing revenue growth should have alt text explaining the trend, not 'a blue line chart'. Purely decorative images should have an empty alt attribute (alt='') so screen readers skip them.

ARIA: Use Sparingly, Correctly ARIA (Accessible Rich Internet Applications) attributes let you add semantic meaning to elements that native HTML cannot express. But the first rule of ARIA is: do not use ARIA if a native HTML element already does the job. The second rule: incorrect ARIA is worse than no ARIA. Incorrectly applied ARIA attributes actively break screen reader experiences.

Not everyone uses a mouse. Users with motor disabilities, tremor conditions, or repetitive strain injuries may use a keyboard exclusively, a switch device, a head pointer, eye-tracking software, or voice control. Your entire interface must be fully operable through these input methods.

The Four Keyboard Navigation Fundamentals

1. Tab order follows visual order. When a user presses Tab, focus should move through interactive elements in a logical sequence that matches the visual layout of the page. A tab order that jumps unpredictably — caused by misuse of tabindex values — is extremely disorienting.

2. All interactive elements must be reachable by keyboard. Buttons, links, form inputs, dropdown menus, modal dialogs, date pickers — every interactive component must be focusable and operable via keyboard. Testing this is simple: unplug your mouse and try to use your product.

3. Focus must never be trapped (except in modals). If a user navigates into a component with Tab, they must be able to navigate out with Tab or Escape. The only legitimate exception is a modal dialog, where focus should be trapped within the dialog until it is dismissed — because allowing focus to move behind an open modal causes significant confusion.

4. Skip navigation links are essential for keyboard users. Keyboard users must Tab through every link in your navigation to reach the main content, unless you provide a 'Skip to main content' link as the first focusable element on the page. This link can be visually hidden and appear only on focus — but it must be there.

Touch Targets for Motor Accessibility For users with limited motor control or tremor, small touch targets are genuinely difficult to activate. WCAG 2.2 sets a minimum touch target size of 24×24 CSS pixels, with a preference for 44×44px following Apple and Google's platform guidelines. Touch targets that are close together without sufficient spacing compound the problem — a misfire activates the wrong element.

Automated testing catches around 30 to 40 percent of accessibility issues. The remaining 60 to 70 percent require manual testing and, ideally, testing with real users who rely on assistive technologies. A passing Lighthouse accessibility score is a floor, not a ceiling.

Automated Tools Axe-core (available as a browser extension, a CLI tool, and integrated into testing frameworks like Cypress and Playwright) is the industry standard for automated accessibility scanning. It flags clear violations with explanations and references to the relevant WCAG criteria. Lighthouse's accessibility audit is built on axe-core. Run these on every page, not just the home page.

Manual Testing Keyboard test — unplug your mouse. Tab through every interactive element on the page. Can you reach everything? Is the focus indicator visible at all times? Can you operate every button, link, and form without a mouse?

Screen reader test — Turn on VoiceOver (macOS/iOS) or NVDA (Windows, free) and navigate your site. Does the page make sense when listened to? Are images described? Do forms announce their labels? Is the reading order logical?

Zoom test — Set your browser zoom to 200% and 400%. Does the layout still work? Does text overflow? Does content overlap? WCAG requires content to remain functional up to 400% zoom.

Colour contrast test — Use the browser's forced colours mode (Windows High Contrast) to see if your interface remains usable when colour is removed.

Testing With Real Users The most valuable accessibility testing is watching someone who relies on assistive technology use your product. Nothing else reveals the gap between 'technically compliant' and 'actually usable' as clearly as this. If your studio does not have ongoing relationships with disabled testers, organisations like AbilityNet and Fable facilitate paid user research with participants who use assistive technologies professionally.

Retrofitting accessibility onto a finished product is significantly harder and more expensive than building it in from the start. The decisions that determine most of an interface's accessibility — heading structure, semantic HTML, colour palette, interactive component patterns — are made during design and early development. Changing them after launch means revisiting design files, refactoring components, and re-testing.

The practical workflow we follow at De Studio:

Design phase — Accessibility checks happen in the design tool, not after handoff. Every colour combination is checked for contrast before it leaves Figma. Interactive states (focus, hover, active, disabled) are designed explicitly. Heading hierarchy is documented in the design spec.

Component development — Every reusable component is built with accessibility baked in: keyboard support, ARIA attributes where needed, focus management for complex interactions like dropdowns and modals. Components that fail axe-core do not get merged.

Page assembly — Automated accessibility tests run on every pull request via CI/CD. A failing axe-core check blocks the build the same way a TypeScript error does. This keeps the cost of fixing violations low by catching them immediately.

Pre-launch audit — Before every deployment, we run a full manual accessibility audit: keyboard test, screen reader test, contrast audit, and zoom test. Issues found here are fixed before the site goes live, not added to a backlog.

Post-launch — Accessibility is not a project milestone. It is an ongoing commitment. New features go through the same checks as the initial build. Annual audits catch regressions that have crept in over time.

The goal of inclusive design is not 100 on a Lighthouse audit. It is a product that a user who is blind can navigate as fluently as a sighted user, a user with one hand can operate as effectively as someone with two, and a user with dyslexia can read as comfortably as someone without. Scores are proxies. The real measure is whether every person who arrives at your product can accomplish what they came to do.