Accessibility is one of those subjects that can receive serious attention for ten minutes during a project kick-off, then quietly slide down the list when designs need approving and launch dates begin to tighten.
The result is predictable. The website goes live, somebody runs an automated audit a few months later and a long list of issues appears. Fixing those problems properly is then harder and more expensive than designing and building the website accessibly from the start.
This is not a niche problem, and it does not necessarily mean the project team had bad intentions. It usually means accessibility was treated as a final check rather than a delivery standard.
For a WordPress website, accessibility needs to influence discovery, user experience, design, development, content, testing and ongoing support. It cannot be owned by one automated tool or added through one plugin after the main decisions have already been made.
Accessibility Is a Delivery Standard, Not a Feature
The most common mistake is treating accessibility as a bolt-on: something to layer over a completed website or provide through a separate mode for users who need it.
A separate “accessible version” is rarely an adequate answer. It creates a second experience that can become incomplete, outdated or disconnected from the service available to everyone else. Users should not be sent to a lesser version because the main website was designed without their needs in mind.
Accessibility is a quality standard that should run through the whole project. In the same way that a well-built WordPress website should be secure, maintainable and reliable, it should also be perceivable, operable and understandable for people using different devices, input methods and assistive technologies.
When accessibility is considered from the beginning, it becomes part of normal design and engineering. When it is deferred until the end, teams are forced to revisit approved interfaces, component behaviour, content structures and third-party technology.
Why Website Accessibility Is Often Left Too Late
Projects tend to run into trouble at predictable points.
Designs are approved before anybody checks colour contrast, focus states or keyboard behaviour. Content is written with headings chosen for appearance rather than structure. Links use phrases such as “click here” without explaining their destination. Interactive components are signed off with a mouse but never tested with a keyboard.
Responsibility is then divided between the designer, developer, client team and third-party suppliers. Each assumes another party will perform the final review.
By the time formal accessibility testing occurs, the templates are complete, the CMS is configured and the content is published. Correcting a problem can then affect many pages or require an approved component to be redesigned.
The principle is simple: accessibility needs to be part of the conversation from discovery onwards, with clear ownership at every stage.
What Accessibility Looks Like During Discovery
Good discovery identifies the users, content, systems and constraints that should shape later decisions. For an accessible WordPress project, that means asking several questions early.
Who will use the service? Known audiences may have specific access needs, but accessibility should not depend on having a neatly documented user group. People use websites with a wide range of permanent, temporary and situational impairments.
Which journeys are critical? Forms, account registration, checkout, search, applications and protected content need particular attention because a barrier can prevent somebody from completing the purpose of the website.
Which content formats are involved? Video, audio, data tables, diagrams, maps and downloadable documents introduce requirements that affect production processes as well as website development.
Which standard and legal duties apply? The Web Content Accessibility Guidelines 2.2 provide the current international technical standard. UK public sector websites and mobile apps have specific duties under the Public Sector Bodies Accessibility Regulations, including meeting WCAG 2.2 AA where required and publishing an accessibility statement. Other service providers may have broader duties under the Equality Act 2010, including avoiding discrimination and making reasonable adjustments. Organisations should obtain appropriate legal advice about their particular obligations.
Which third-party systems are unavoidable? Booking systems, payment services, video embeds, recruitment tools, maps and CRM widgets may sit partly outside your control. Identifying them early allows the team to test alternatives, challenge suppliers or document limitations before they become central to the service.
These questions should feed directly into the wider design and UX process, the technical specification and the project acceptance criteria.
What Accessibility Means for Design and UX
Accessible design does not mean making every interface grey, plain or visually unambitious. Most accessibility decisions improve clarity and usability for everyone.
Colour contrast. Under WCAG 2.2 AA, normal text generally needs a contrast ratio of at least 4.5:1, while qualifying large text generally needs at least 3:1. Testing the palette during initial design is far easier than changing an established visual system later.
Typography and resizing. Text needs to remain readable when enlarged, and layouts should accommodate increased text size without hiding controls or forcing users through an impractical horizontal journey.
Visible focus states. Keyboard users need a clear indication of which link, button or control is active. Focus indicators should be designed intentionally rather than removed because they appear visually disruptive.
Navigation and interaction. Menus, tabs, accordions, modals, carousels and mobile navigation should be understandable and operable without relying on a mouse, precise pointer movement or drag gestures alone.
Forms and errors. Labels must be clear and connected to their fields. Instructions should not rely on placeholder text. Errors need to identify what went wrong and help the user correct it, including when the message is announced through assistive technology.
Responsive layout and reading order. Content should remain logical when the viewport changes, the page is zoomed or the visual layout is not available. A design that looks correct on screen can still have a confusing source order.
Reduced motion and time limits. Animations, automatic movement and expiring interactions need to account for users who cannot comfortably process motion or complete a task within a narrow period.
None of these requirements is unusual or prohibitively complex when it is part of the design system from the outset.
What Accessibility Means During WordPress Development
Front-end development is where accessible design intent either becomes a usable experience or quietly falls apart.
Semantic HTML matters. Buttons should be buttons, links should be links and navigation should use appropriate landmarks. Screen readers and other technologies rely on the document structure to identify what an element is and how it should behave.
Keyboard operation needs deliberate testing. Every interactive component should be usable without a mouse. This includes navigation, accordions, tabs, filters, modal windows, date pickers and custom controls.
Gutenberg blocks need accessible output. WordPress core includes significant accessibility work, but custom blocks and third-party block libraries vary. The editor interface and the front-end output both need consideration, especially where a block includes interaction rather than static content.
Heading structure should reflect the document. Heading levels are not styling controls. Pages should have a meaningful hierarchy that allows users to understand and navigate the content.
Form labels must be programmatically associated. Text positioned near an input is not necessarily a label, and placeholder text should not be the only instruction available.
Native HTML should come before ARIA. ARIA attributes can communicate states and relationships that native HTML cannot express, but incorrect ARIA can create conflicts or make an interface less usable. It should supplement sound HTML rather than compensate for avoidable markup.
Third-party components require scrutiny. Sliders, maps, chat tools, cookie interfaces, booking widgets and embedded forms are frequent sources of barriers. Their accessibility should be part of supplier and plugin selection, not discovered after launch.
For a new WordPress website or connected platform, these requirements should sit inside the definition of done for every relevant component.
The Role of Editors After Launch
A freshly launched website can pass a structured review and still accumulate accessibility problems over the following months. Routine publishing introduces new images, headings, links, documents and video, all of which can create barriers.
Common editorial problems include:
- Images without appropriate alternative text, or descriptions that do not communicate the image’s purpose in context.
- Generic link text such as “click here” or repeated “read more” links that are unclear when encountered out of context.
- Heading levels selected for appearance rather than the structure of the page.
- Tables used for layout, or data tables published without appropriate headers and relationships.
- Video and audio without alternatives such as accurate captions, transcripts or descriptions where needed.
- Inaccessible documents uploaded as PDFs, presentations or spreadsheets without checking their structure and reading order.
These problems are preventable when editors receive practical training and the CMS makes the right behaviour easier. Reusable blocks, sensible permissions, editorial checklists and clear guidance can protect the standard without making publishing unnecessarily difficult.
Accessibility after launch is a collaboration between the development team and the people responsible for content. Without both, the website will drift.
Why Automated Accessibility Testing Is Not Enough
Automated tools such as Axe, WAVE, Lighthouse and Pa11y are useful. They can identify many issues that can be detected programmatically, including certain contrast failures, missing labels, invalid markup, language settings and ARIA errors.
They cannot determine whether the complete website is understandable and usable.
A tool cannot reliably decide whether alternative text communicates the purpose of an image, whether a menu is logical to a screen-reader user or whether instructions make sense without the surrounding visual design. It may identify that an element has an accessible name while being unable to judge whether that name is useful.
A thorough review therefore combines several approaches:
- Automated scanning across representative templates and journeys.
- Keyboard-only navigation and visible-focus testing.
- Manual inspection of structure, labels, instructions and content alternatives.
- Testing with relevant screen readers and browser combinations.
- User testing with disabled people where appropriate to the service and project.
An automated report is useful evidence. It is not, by itself, proof that a website is accessible.
Accessibility Is an Ongoing Platform Responsibility
A website is not a fixed object. New content is published, plugins are updated, components are redesigned and new services are integrated. Each change is an opportunity to introduce a new barrier.
Ongoing accessibility work should include:
- Reviewing accessibility implications when new functionality is proposed.
- Including accessibility checks in quality assurance for theme, plugin and component changes.
- Running periodic automated and manual reviews.
- Keeping editorial guidance current as the platform evolves.
- Reviewing new third-party integrations against the same expectations as the main website.
- Maintaining an accessibility statement where one is required or useful.
- Providing a clear route for users to report accessibility problems.
For organisations with an ongoing WordPress Support & Growth relationship, this work can be included in normal platform stewardship rather than deferred until a large remediation project becomes unavoidable.
Where to Start With an Existing WordPress Website
Most accessibility failures are not the result of a deliberate decision to exclude people. They are the result of delivery and publishing processes that never made accessibility a consistent requirement.
The right starting point is a structured review of representative pages, templates and critical journeys. That review should consider design, content, front-end components, keyboard behaviour, forms, third-party tools and the editorial process, not simply produce an automated score.
A WordPress website audit can help separate quick editorial fixes from deeper component or platform problems, then prioritise work by user impact, risk and effort.
Make Do can review accessibility across design, content, WordPress components and ongoing publishing workflows. Talk to the Make Do team about where your website needs attention and the most practical route to improvement.
