Accessibility is not just a technical issue: a holistic approach

1. Accessibility goes beyond code

A website can pass automated checks and still be difficult to use. Accessibility combines technology, editorial decisions, visual design, real user journeys and ongoing maintenance. None of these areas can compensate for the complete failure of another.

For example, correct HTML does not make confusing instructions understandable. Equally, attractive pages cannot rescue a checkout that cannot be completed with a keyboard. A holistic approach considers how people actually interact with a service.

2. Accessible development is the foundation

Semantic HTML allows browsers and assistive technologies to understand headings, links, buttons, forms and page regions. Native controls generally provide more predictable keyboard behaviour than visual elements made to imitate buttons.

Developers should preserve logical reading and focus order, associate labels with fields and make errors available programmatically. ARIA can enhance semantics when needed, but it cannot replace sound HTML or thoughtful interaction design.

3. Content can create barriers too

Editorial accessibility begins before publication. Headings should describe the structure, links should make sense outside their surrounding paragraphs and instructions should not rely solely on colour, position or images.

Informative images need suitable text alternatives. Tables need meaningful headers; downloadable documents need accessible structure; videos need captions and other appropriate alternatives. Correct information is of limited use when people cannot perceive or understand it.

4. Design must remain clear and consistent

Inclusive interfaces use recognisable visual hierarchy, consistent components and distinguishable states. Visitors should not have to relearn how a button works on every page. Contrast, spacing and readable typography directly affect independence.

Colour alone must never communicate an error or selection. Interfaces also need to withstand zoom, reflow and smaller screens without hiding essential content or functions. The aim is one usable experience, not a separate cosmetic accessibility mode.

5. Real journeys matter more than appearances

An attractive homepage says little about whether someone can book an appointment, make a payment or submit an enquiry. Accessibility must be evaluated throughout the entire journey, including forms, confirmations and error recovery.

Test practical tasks: open navigation by keyboard, reach required fields, correct mistakes and receive a clear confirmation. A dialog that traps focus or an unannounced error can stop someone completing a task entirely.

6. Every team has a responsibility

Accessibility problems arise when designers, developers, editors and maintenance teams assume another department will handle them. Every decision, from button colours to notification wording, can create or remove barriers.

Agree shared acceptance criteria and responsibilities. Designers document states and interaction; developers implement semantics and keyboard support; editors provide clear language and alternatives; testers verify complete journeys. Collaboration prevents expensive last-minute fixes.

7. WCAG 2.2 provides testable criteria

The Web Content Accessibility Guidelines organise requirements around four principles: perceivable, operable, understandable and robust. They help distinguish measurable accessibility from isolated visual improvements.

Requirements cover text alternatives, keyboard operation, contrast, focus, error identification and compatibility. Passing an automated scanner is not equivalent to meeting every criterion; context and real interaction still require manual review.

8. Combine testing methods and perspectives

Automated tools can identify some missing names, contrast failures and markup problems. They cannot reliably decide whether instructions make sense, whether reading order is meaningful or whether an image description conveys its purpose.

Combine automated checks with code inspection, keyboard-only navigation, zoom and screen-reader testing. Where possible, involve disabled users and act on their findings rather than treating participation as a formality.

9. Maintenance is part of accessibility

An accessible site can become inaccessible after a theme update, new plugin, changed menu or newly published document. A campaign with poor contrast or a form without proper labels can undo earlier progress.

Include accessibility checks in release and publishing processes. Editorial checklists, regression tests and issue tracking make problems easier to detect and fix. Accessibility is not a permanent certificate obtained once.

10. Why an overlay cannot replace this work

A floating accessibility widget may change some visual preferences, but it cannot guarantee correctly named controls, sensible focus management, accessible documents or understandable error messages.

The presence of a widget is not proof of WCAG 2.2 conformance. Fix underlying structure, content and interactions and verify the results; do not confuse a layer of controls with removing barriers.

11. Start with a practical action plan

Choose three essential tasks and attempt them with keyboard and assistive technology. Review headings, links, forms, errors, contrast, zoom and mobile behaviour. Then examine how your team publishes and updates content.

Record each barrier with reproduction steps, impact and an owner. Prioritise issues that block task completion, retest after fixes and involve every relevant discipline. Accessibility is a working method, not a feature to install.

Semantic controls in everyday use

Consider a contact panel opened by a button. If the control is merely a styled container with a mouse click handler, someone navigating by keyboard may never be able to activate it. A native button with an accessible name and sensible focus behaviour removes that barrier at its source. The same principle applies to tabs, accordions, navigation menus and dialog windows: the appearance alone does not describe how an interface behaves.

A visible label placed beside an input is not enough when it is not programmatically associated with that input. Error messages should identify the affected field, explain the problem and support recovery. Screen-reader users need those messages announced at the right time rather than relying on red borders or icons.

Editorial choices shape independence

Editors can improve accessibility without changing application code. Descriptive link text helps people understand where a link leads, including when navigating a list of links with assistive technology. Important information contained in an illustration should also be expressed in an appropriate text alternative or nearby text. Downloadable documents need meaningful headings, correct reading order and usable form fields.

Instructions must not assume that every visitor sees the same screen layout. Instead of saying ‘choose the green option on the right’, refer to the actual control name. This works better for people using screen readers, magnification, narrow mobile screens or alternative presentation settings. Plain language also helps people understand what is expected before taking action.

Design for changing conditions

Check contrast using the actual foreground and background colours in buttons, fields, messages and disabled states. Keyboard focus must remain visible, while interactive targets should not demand unusually precise pointer movements. At increased text size and browser zoom, essential information and controls should remain available without unexpected clipping.

Inspect reflow on small screens and ensure that ordinary reading does not require unnecessary scrolling in two directions. Dialogs should not obscure critical information or lose focus. Consistent placement and predictable behaviour reduce cognitive effort, particularly when visitors are unfamiliar with a service.

Evaluate a complete journey

Start with a realistic scenario: a visitor finds a service, reads its details, selects an appointment, fills in a form and receives confirmation. A barrier can appear at any stage even when an automated scan reports few issues. Document the expected result, the actual behaviour and the steps required to reproduce the problem.

Repeat the journey without a mouse, with significant zoom and with a screen reader. Prioritise barriers that prevent completion over minor visual inconsistencies. After making a fix, retest the full flow because changes to one component can affect another. Where possible, include people with disabilities in these evaluations and act on what they report.

Make accessibility part of delivery

Accessibility needs to be built into design reviews, development acceptance criteria, editorial publishing and maintenance. A short checklist for new articles, images, forms and interactive components helps prevent the same problems from returning. Assign clear owners and keep a record of outstanding barriers.

After a theme, plugin or component update, repeat checks on critical journeys. WCAG 2.2 provides measurable requirements, but a scanner score is not a substitute for judgement or user testing. An overlay cannot take responsibility for this process or repair every structural and editorial problem. Accessibility is the outcome of coordinated, ongoing work.

WCAG 2.2 — W3C