What Is Website Accessibility?
Website accessibility means designing and maintaining digital content so people with different disabilities, devices and ways of interacting can use it.
Part of our guide: Mobile-Friendly Websites: The Complete Guide for Businesses
Website accessibility means designing, writing, building and maintaining content so people with different disabilities and ways of interacting can perceive, understand, navigate and use it. Plan for it throughout the website’s development and upkeep.
Who website accessibility supports
People may browse with limited or no vision, reduced hearing, limited movement, cognitive differences, speech disabilities or combinations of these. Some disabilities are permanent, while others are temporary or vary from day to day.
Accessible choices also help people with an injured hand, tired eyes, a noisy environment, bright sunlight, a slow connection or an unfamiliar device. Give people different ways to complete tasks so the website works across those conditions.
The W3C Web Accessibility Initiative’s introduction to accessibility explains how people, technologies and design decisions interact.
Thinking about your own rebuild?
Tell us about your business, your current website and what you would like to improve. We will help you work out the next step.
The four broad principles
The Web Content Accessibility Guidelines organise requirements around four principles: perceivable, operable, understandable and robust. These principles are often shortened to POUR.
Perceivable content can be received in more than one way. Operable interfaces do not depend on a mouse or precise gesture. Understandable pages use clear structure and predictable behaviour. Robust code works with current and future browsers and assistive technologies.
These principles are more useful than a list of fashionable features. They help a team ask whether a design decision creates an equivalent route for people who cannot see, hear or perform the assumed interaction.
Perceivable content
For implementation checks, use the guides to colour contrast, zoom and reflow and video captions and transcripts.
Informative images need text alternatives that convey their purpose. Video may need captions, transcripts and audio description depending on its content. Colour must not be the only way to communicate an error or status.
Text should have sufficient contrast and remain readable when enlarged. Important words should not be baked into an image. A clear heading structure lets readers scan visually and gives screen-reader users a navigable outline.
Make the information available in a form each person can use, which may involve different ways of presenting it. The guide to alt text explores one part of that work.
Operable interfaces
Use the keyboard-only task checklist for a focused first review. Record what was tested without treating that one check as a complete audit.
Every important action should work without a mouse. Keyboard focus needs a visible indicator and a logical order. Menus, dialogs, disclosures and forms must open, update and close predictably.
Touch targets need enough size and separation. Avoid interactions that depend only on hovering or complex gestures. Give people enough time, and provide controls for moving or flashing content. Respect reduced-motion preferences.
Keyboard testing is a powerful first check: use Tab and Shift+Tab to move, Enter or Space to activate controls and Escape where a component should close. This does not replace testing with assistive technology, but it reveals many barriers quickly.
Understandable content and behaviour
Use plain, specific language suited to the audience. Break long information into meaningful sections and keep navigation names consistent. Explain unusual terms instead of assuming specialist knowledge.
Forms need visible labels, helpful instructions and errors that identify the problem and its correction. Preserve valid entries after a mistake. Confirm successful actions and explain what happens next.
Predictability also matters. A familiar control should not produce a surprising outcome. Avoid opening new windows, starting media or moving focus without a clear reason. Consistent components reduce the learning required from page to page.
Robust foundations
Semantic HTML communicates the role and structure of content to browsers and assistive technology. Use real headings, buttons, links, lists and form controls for their intended purposes. A styled generic element does not automatically inherit the keyboard and accessibility behaviour of a button.
ARIA can describe advanced states and relationships, but it does not repair an unsuitable interaction model. Prefer native HTML where it meets the need, then add ARIA carefully and test the result.
Validate important components across browsers and assistive technologies. Code can meet a formal pattern yet remain confusing when its focus, labels and announcements are experienced as a sequence.
Accessibility and mobile design
Mobile accessibility involves text size, reflow, zoom, touch, orientation and the virtual keyboard. A responsive layout should preserve the content and reading order rather than simply fitting boxes into a narrow viewport.
Fixed headers, consent controls and chat buttons can stack until little screen remains. Test landscape as well as portrait. Make sure form fields and errors remain visible when the keyboard opens.
The mobile-friendly website guide shows how accessibility, performance and responsive design support one another.
Content accessibility
A clear H1, H2 and H3 outline makes the section hierarchy understandable. For interactive content, review form error recovery as carefully as the initial labels.
Editors influence accessibility every time they publish. They choose headings, link wording, image descriptions, tables and document formats. Provide approved content components and guidance so accessible patterns do not depend on remembering technical rules.
Write descriptive links that make sense out of context. Use headings to describe sections, not merely to create large type. Keep tables for genuine relationships and identify their headers. Provide accessible HTML information rather than relying only on a PDF download.
Avoid instructions based only on position, shape or colour, such as “press the green button on the right”. The layout and colour may differ for another user.
Forms and transactions
Forms combine content, design, code and business process, so they deserve careful attention. Associate every label with its control, identify required fields and group related options. Do not use placeholder text as the only label.
When validation fails, provide a useful summary and a message beside each affected field. Move focus predictably and keep the information the person entered. Error styling must not rely solely on red colour.
After submission, announce success, provide a reference where appropriate and explain the next step. Test the email or back-office delivery as well as the screen. An accessible interface cannot compensate for an enquiry that disappears.
Documents and multimedia
Downloadable documents need their own accessible structure, reading order, headings, link text and alternatives. When the information is central to a service, an accessible web page is often easier to maintain and use than a document alone.
Videos need accurate captions for speech and meaningful sound. A transcript can help people who prefer to read or search the content. Audio description may be required when important visual information is not conveyed by the soundtrack.
Do not autoplay audio. Give users controls and make the player operable by keyboard. Check any third-party player rather than assuming accessibility from the supplier’s marketing.
How accessibility is evaluated
Automated tools can identify missing labels, some contrast problems and certain code errors. They cannot decide whether alternative text is useful, a heading structure makes sense or a task is understandable. The W3C notes that knowledgeable human evaluation is required.
Combine automated scans with keyboard testing, zoom and text-resize checks, screen-reader sampling and task-based review. Include disabled people in research and testing where possible, compensate them appropriately and act on what they report.
Test templates and shared components as well as individual pages. A problem in the navigation or form field can affect the entire site.
Accessibility is an ongoing practice
A site can become less accessible when new content, plugins or campaigns are added. Assign ownership, document standards and include accessibility in design reviews, development acceptance criteria and editorial checks.
Train people in the tasks they perform. Writers need different detail from component developers, but both should understand the customer impact. Record known issues, severity, ownership and expected resolution.
Monitor feedback routes and make them usable. People encountering a barrier need a practical way to report it and obtain the service through another route while the issue is repaired.
Common misconceptions
Accessibility is not only for blind screen-reader users. It includes hearing, mobility, cognition, speech, vision and multiple forms of interaction. It is not achieved by installing an overlay or toolbar over inaccessible foundations.
Conformance does not guarantee that every journey is easy, and a clean visual design does not guarantee accessible code. Accessibility is also not opposed to creativity. Clear constraints can produce distinctive, flexible design.
The question does a business website need to be accessible considers the commercial and legal context without replacing professional legal advice.
A sensible starting plan
Identify the website’s essential tasks and the templates that support them. Repair keyboard blockers, missing form labels, severe contrast failures, inaccessible menus and absent alternatives for important content first.
Establish an accessible component library and publishing guide. Test new work before release. Plan the remaining issues by user impact rather than choosing only the easiest automated findings.
Accessibility often improves the ease of using a website for a much wider audience, but disabled people should not have to rely on incidental benefits. Their access is a direct requirement of inclusive service design.
Frequently asked questions
Is accessibility the same as usability?
They overlap, but accessibility specifically addresses barriers experienced by disabled people and compatibility with different ways of interacting. A site can feel simple to a mouse user while remaining inaccessible by keyboard.
Is WCAG a testing tool?
WCAG is a standard containing testable success criteria and guidance. Tools can assist, but human evaluation remains necessary.
Can a plugin make a website accessible?
No single plugin can repair content, structure, keyboard behaviour, third-party systems and business processes. Accessibility must be built and maintained throughout the site.
Should accessibility wait until a redesign?
No. Repair serious barriers now and use a redesign to improve shared foundations. Waiting can leave customers unable to use the service.
Who owns accessibility?
Everyone who shapes the service has a role, including leadership, procurement, design, development, content and customer support. Named ownership helps coordinate the work.
Build access into normal website quality
Accessibility works best when it is part of ordinary decisions about content, components and customer journeys. It helps a business reach more people, reduces avoidable friction and creates a website that adapts more reliably to changing contexts.
Afterworks includes accessibility review and resilient component design within a website rebuild, while recognising that continued publishing and testing are needed after launch.
