Web accessibility: a practical guide to inclusive design

Web accessibility: a practical guide to inclusive design

A blind user opens a shop’s checkout page, fills in card details with a screen reader, and abandons the purchase at the final step because a custom dropdown announces only “item 3 of 7” with no label. The product team never sees the failure in their analytics, because the user simply leaves. This is the everyday shape of web accessibility work: the gap between what a site intends to show and what each visitor can actually perceive, operate, and understand.

This guide explains what web accessibility really covers, how the WCAG framework structures it, which design and code decisions matter most, and how to test for barriers before launch. It is written for designers, developers, product owners, and editors who want a working mental model, not a compliance checklist disguised as advice.

What web accessibility actually means

Web accessibility is the practice of building websites and applications so that people with disabilities can perceive, understand, navigate, and interact with them on equal terms with everyone else. The phrase covers a wide spectrum: blind and low-vision users, deaf and hard-of-hearing users, people with motor impairments who cannot use a mouse, and people with cognitive or neurological conditions such as dyslexia, ADHD, or photosensitive epilepsy.

Accessibility is also useful for people without diagnosed disabilities. A person reading a page on a bright phone in sunlight, a parent completing a form one-handed while holding a child, a surgeon using voice control in a sterile environment, and a search engine crawler all benefit from the same structural qualities: clear semantics, predictable behaviour, and content that does not depend on a single sense or input method.

The legal framing matters too. Many jurisdictions treat inaccessible digital services as a form of discrimination. The European Accessibility Act, the United States Americans with Disabilities Act, and the United Kingdom’s Equality Act all touch digital products. The exact obligations vary, but the practical standard they point to is the Web Content Accessibility Guidelines (WCAG), currently at version 2.2, with a working draft of version 2.3 under review.

Who web accessibility is for

Accessibility is often described as serving “users with disabilities”, but a useful design exercise is to map real tasks to real conditions. The table below shows common scenarios and the design features each one depends on.

Scenario	User need	Primary design dependency
Blind user paying a bill with a screen reader	Every control has a name, role, and value exposed to assistive technology	Semantic HTML and accurate ARIA where native elements are not enough
Low-vision user reading in bright daylight	Text remains legible without zooming	Sufficient color contrast, scalable text, and reflow at 400 percent zoom
User with tremor using a switch device	All actions reachable without precise pointing	Full keyboard support, large hit targets, and timing that does not require steady hands
Deaf user watching a product demo	Audio information available as text	Captions, transcripts, and visual equivalents for sound cues
User with cognitive load from a medical condition	Predictable layout, plain language, and clear errors	Consistent navigation, short sentences, and error messages that say how to fix the problem
User with photosensitive epilepsy	No content flashes more than three times per second	Animation limits, prefers-reduced-motion respect, and content warnings on video

Notice how each row connects a real human situation to a measurable design property. That mapping is the working definition of web accessibility in practice: it is not a list of features, it is a list of decisions that decide who can finish a task.

How WCAG structures accessibility work

WCAG organizes accessibility under four principles, often shortened to POUR: Perceivable, Operable, Understandable, and Robust. Each principle contains a set of guidelines, and each guideline contains testable success criteria at three conformance levels.

Principle	Meaning	Example criteria	What it rules out in practice
Perceivable	Information must be presentable to users in ways they can perceive	1.1.1 Non-text content, 1.4.3 Contrast minimum, 1.4.11 Non-text contrast	An image that conveys meaning but has no alternative text, or grey text on a grey background
Operable	Interface components and navigation must be operable	2.1.1 Keyboard, 2.4.3 Focus order, 2.5.5 Target size	A custom slider that only responds to mouse drag, or focus that jumps in an illogical order
Understandable	Information and operation must be understandable	3.3.1 Error identification, 3.3.2 Labels or instructions	An error message that simply says “Invalid” without saying which field or what to do
Robust	Content must be robust enough to be interpreted by a wide range of agents	4.1.2 Name, role, value, 4.1.3 Status messages	A button built from a div with no role or accessible name, or dynamic updates that are not announced

Most national laws reference WCAG 2.1 or 2.2 at level AA. That is the practical target for most commercial sites, with AAA criteria applied selectively where they do not conflict with design intent.

Designing with accessibility in mind

Accessibility is much cheaper when it shapes the design from the first sketch. Retrofitting an inaccessible component after launch can cost several times more than designing it correctly, because every screen, every state, and every copy decision has to be re-examined.

Start with content structure

Before any visual work, agree on the document outline. A page should have one logical heading that matches the title of the article or section, followed by a sequence of subheadings that mirror the questions a reader is actually asking. Screen reader users often navigate by jumping from heading to heading, so the outline is their table of contents.

• Use a single H1 per page, supplied by the WordPress title field, and never duplicate it in the body.
• Keep heading levels sequential. Do not jump from H2 to H4 just because a section feels less important.
• Write headings that read as questions or decisions, not labels. “Choosing a payment provider” beats “Payment provider” when the reader is comparing options.

Treat color as a layer, not a signal

Color is a powerful design tool, but it is one of the most common sources of accessibility failure because designers naturally use it to carry meaning. The rule is simple: color can reinforce meaning, it cannot carry it alone.

• Pair color with an icon, label, or pattern. A red error state should also have an icon and text that names the problem.
• Maintain at least 4.5:1 contrast for body text against its background, and 3:1 for large text and meaningful UI components.
• Verify contrast in both light and dark modes, and across the actual gradient or image behind any overlay.

Make interaction obvious

Every interactive element needs three signals: a clear resting state, a visible focus state, and a clear selected or active state. Focus styling is not optional decoration; for keyboard users it is the only way to know where they are on the page.

• Use a focus ring that meets 3:1 contrast against the background and is at least two pixels thick.
• Avoid removing the default outline without replacing it with an equivalent style.
• Keep the focus order aligned with the visual order so users do not have to predict where Tab will land next.

Writing accessible content

Copy decisions are accessibility decisions. Word choice, sentence length, and the way errors are explained all determine whether a user can complete a task under stress, on a phone, or with a cognitive condition.

Plain language

Plain language is not the same as simplistic language. It means choosing the clearest construction for the intended reader. A short sentence that uses a specific noun is usually easier to follow than a long sentence that uses a vague pronoun.

• Lead with the action. “Save your draft before closing the tab” is clearer than “Before you close the tab, you may wish to ensure your work has been saved.”
• Define jargon on first use. If a term like “session token” is necessary, link to a plain-language explanation.
• Use active voice unless the actor is unknown or unimportant.

Links and calls to action

Screen reader users often pull up a list of links on a page to scan destinations. “Click here” and “Read more” become a meaningless list of identical entries. Link text should describe the destination in isolation.

• Write “View the pricing plans” rather than “Click here to view the pricing plans”.
• Avoid using the same link text for different destinations on the same page.
• Indicate when a link opens a new tab or downloads a file, and warn users about file types and sizes.

Alt text that earns its place

Alt text exists to give an image a text equivalent in the context it appears. It is not a place for keyword insertion, and it is not a caption.

• Describe the information the image conveys, not its visual style. A bar chart of revenue by quarter needs the data, not “bar chart”.
• Mark decorative images with empty alt attributes so assistive technology can skip them.
• For complex images such as diagrams, provide a longer description in the surrounding text or a linked description page.

Building accessible components

Components are where accessibility either holds up or falls apart. A site can have good copy, good colors, and good headings, and still fail completely because a single custom widget traps the keyboard or hides its state from assistive technology.

Native elements first, ARIA second

The single most common accessibility mistake in front-end code is reaching for ARIA before checking whether a native HTML element already does the job. A button is not a div with a click handler. A select is not a list of divs with custom logic.

Intent	Native element	When ARIA is acceptable
Button action	button	Rarely; only when no native element is available, and only with proper role and name
Tab interface	Buttons inside elements with role=”tablist”, “tab”, “tabpanel”	Acceptable when native tab semantics are not provided by the framework
Modal dialog	dialog element with showModal()	Acceptable for legacy code with role=”dialog” and aria-modal=”true”
Live status update	Output or region with aria-live=”polite”	Acceptable for dynamic content that must be announced

Keyboard support is the contract

Every interactive element must be reachable and operable using the keyboard alone. The standard keys are Tab and Shift-Tab to move focus, Enter and Space to activate, arrow keys for composite widgets, and Escape to dismiss overlays. If a component cannot deliver that contract, it is not finished.

Forms that explain themselves

Form fields need visible labels, not placeholder text acting as a label. They need to announce required state, error state, and any format expectations. They need to preserve user input when an error is shown, so the user does not have to start over.

• Associate each label with its input using the for attribute, or wrap the input in the label.
• Use aria-describedby to link helper text and error messages to the field they explain.
• Move focus to the first error after submission so screen reader users hear the problem immediately.

Testing web accessibility in practice

Testing is not a single event. It is a layered practice that catches different kinds of failure at different stages of design and build.

Automated checks

Automated tools can scan a page and flag a meaningful share of common issues: missing alt attributes, low contrast, missing form labels, empty links, and broken heading order. They are fast and repeatable, which makes them useful in CI pipelines. They are not sufficient on their own, because many real failures depend on context that a scanner cannot see.

Keyboard walkthroughs

Unplug the mouse or disable the trackpad. Complete every important task on the site using only the keyboard. Watch where focus goes, whether it is visible, and whether any trap exists. Try Escape on every overlay. Try Tab on every form. This step surfaces a large class of issues that automated tools miss.

Screen reader testing

Testing with at least one screen reader, on at least one platform, is the single most revealing step in an accessibility audit. NVDA on Windows, VoiceOver on macOS and iOS, and TalkBack on Android are the main options. The test is not to memorize commands, but to listen to what a real user would hear, and to notice when something is missing, wrong, or confusing.

Testing with real users

When the budget allows, sessions with users who have disabilities are the most valuable form of testing. They surface issues that no checklist predicts, from a confusing focus order in a checkout flow to a tone of voice in error copy that feels accusatory. They also reveal which compromises actually matter to users and which ones only matter on paper.

Common accessibility mistakes and how to avoid them

Mistake	Why it fails	What to do instead
Custom dropdowns that ignore native select	Keyboard navigation, type-ahead, and mobile pickers all break	Use native select for simple cases, or build with the WAI-ARIA Authoring Practices combobox pattern and test thoroughly
Modal that traps scroll but not focus	Background content remains in the tab order, screen reader users get lost	Move focus into the dialog on open, trap focus inside, restore focus to the trigger on close
Carousel with autoplay and no pause	Users with vestibular conditions and cognitive load can be harmed; control is taken away	Provide a visible pause control, respect prefers-reduced-motion, and avoid autoplay for essential content
Icon-only buttons with no accessible name	Screen readers announce “button” with no purpose	Provide a visible label, an aria-label, or a visually hidden text node for every icon button
CAPTCHA without an alternative	Blind and motor-impaired users cannot solve visual or drag challenges	Offer an audio alternative, use a logic test, or choose a service that supports accessible verification
Video with auto-captioned transcript that is never edited	Auto captions are often wrong in ways that distort meaning	Edit captions for accuracy, provide a full transcript, and describe important visual information in audio description

Accessibility, SEO, and performance overlap

Accessibility work tends to improve search visibility and core web vitals at the same time, because the underlying signals are similar. Crawlers read the same semantic HTML that screen readers read. Fast pages help users with motor and cognitive conditions as much as they help ranking. A page that is well structured for a screen reader is usually well structured for a parser.

• Heading hierarchy gives both users and crawlers a clear outline of the page.
• Alt text provides indexable text for images that would otherwise be invisible to search.
• Transcripts and captions create text equivalents for audio and video that boost keyword coverage and accessibility at once.
• Reduced motion and efficient code both lower the cost of interaction on low-powered devices.

Treat accessibility as a quality bar rather than a separate project, and the SEO and performance benefits arrive as a side effect rather than an extra deliverable.

Building an accessibility practice on a real team

Most teams do not need a dedicated accessibility specialist to make meaningful progress. They need a shared vocabulary, a small set of design and code conventions, and a habit of testing before launch. The steps below describe a practical starting point for a small product team.

1. Adopt WCAG 2.2 AA as the written target and link it from the design system documentation.
2. Add an accessibility checklist to the design template, covering contrast, focus, alt text, and motion.
3. Add an automated scan to the CI pipeline for every pull request, and fail the build on new violations.
4. Run a keyboard and screen reader walkthrough before each release candidate, recorded and shared with the team.
5. Track accessibility bugs in the same backlog as functional bugs, with severity labels and a definition of done.
6. Schedule a quarterly audit by an external accessibility specialist who can spot patterns the in-house team has normalised.

Each step is small on its own. Together they change the default. After a few cycles, inaccessible patterns stop reaching the design stage at all, because the team has internalised the constraints.

A short checklist for shipping an accessible page

• One H1 in the title field, with a logical H2 to H4 outline in the body.
• Body text at 4.5:1 contrast against its background, or better.
• Every interactive element reachable with Tab, with a visible focus style.
• Every form field has a visible label and a programmatic association.
• Every meaningful image has descriptive alt text, every decorative image has empty alt.
• Every video has accurate captions, every audio asset has a transcript.
• No content flashes more than three times per second.
• Animations respect prefers-reduced-motion where they are not essential.
• Automated scan is clean, keyboard walkthrough is clean, screen reader spot check is clean.

Frequently asked questions

What is the difference between web accessibility and usability?

Usability describes how easily any user can accomplish a task on a site. Web accessibility describes whether users with disabilities can perceive, operate, and understand the site at all. Accessibility is a prerequisite for usability for a significant share of the population, and the two disciplines overlap heavily. A site can be accessible but still hard to use, and a site can be usable for most people but entirely unusable for someone who relies on a screen reader.

Is WCAG a law?

WCAG itself is a technical document published by the W3C. It is not a law. However, many countries and regions reference WCAG in their accessibility legislation, often at version 2.1 level AA or the equivalent of 2.2 level AA. In practice, conforming to WCAG 2.2 AA is the safest way to meet most regulatory expectations, but it is wise to confirm the specific standard referenced in each jurisdiction where the site operates.

What is the minimum standard I should aim for?

For most commercial sites, WCAG 2.2 level AA is the practical minimum. It balances the cost of implementation with the breadth of users it covers. Level AAA criteria are stricter and not always realistic for every page, but individual AAA techniques can be applied selectively where they do not conflict with design intent, such as providing sign language interpretation for important announcements.

Do I need to make every PDF accessible too?

If a PDF is part of a public service or a key user journey, it should be accessible. At minimum, that means a logical reading order, tagged headings, alternative text for images, and a way to extract the text. For long or complex PDFs, a separate accessible HTML version is often a better answer than retrofitting the document.

Can automated tools make a site fully accessible?

No. Automated tools can detect a meaningful share of common issues, often between 30 and 50 percent of the problems a manual audit would find, but they cannot judge whether alt text is meaningful, whether a focus order makes sense, or whether a custom widget behaves correctly. Automated tools are a safety net, not a substitute for human review.

What is ARIA and when should I use it?

ARIA stands for Accessible Rich Internet Applications. It is a set of attributes that describe roles, states, and properties to assistive technology when native HTML cannot. The first rule of ARIA is to prefer native HTML where possible, because native elements come with built-in keyboard handling, focus management, and semantics. Use ARIA to fill gaps, not to replace the basics.

How do I test for color contrast correctly?

Test the actual rendered colors, not the values in the design file, because variables, opacity, and blend modes can change them. Check body text at 4.5:1, large text at 3:1, and meaningful UI components at 3:1. Pay special attention to placeholder text, disabled states, and text on images, which are frequent offenders.

What is the prefers-reduced-motion media query for?

It lets users tell the site that they prefer to see less motion, often because of vestibular conditions or a preference for a calmer interface. When a user has set this preference, the site should reduce or remove non-essential animation, parallax effects, and auto-playing video. Respecting the preference is part of WCAG 2.2 success criterion 2.3.3.

How do I get buy-in for accessibility work internally?

Frame accessibility in the language the business already cares about. Show the size of the affected audience, the overlap with SEO and performance, the cost of retrofitting versus designing in, and the legal exposure in the markets the company operates in. Pair the case with a small, visible win, such as an audit of the top user journey and a before-and-after comparison, so the conversation moves from principle to evidence.

Related reading

• MADE Visual Studio blog
• Website accessibility checklist