ACCESIBILIDAD ≠ OVERLAY · 32
Accessibility ≠ Overlay: accessibility must be planned
📅 2 November 2026
Accessible websites are not an accident. They result from clear requirements, inclusive design, sound development, realistic testing and ongoing maintenance.
1. Accessibility starts with project decisions
If accessibility is only considered at the end, barriers may already be embedded in the navigation, layout and core interactions. Fixing them can require rebuilding entire components.
Planning means asking early how someone will navigate without a mouse, complete a form with a screen reader or enlarge text without losing controls. These questions shape the architecture, not merely the final checklist.
2. Define measurable requirements
Saying that a website should be accessible is not enough. Specify keyboard operation, visible focus, labelled form controls, meaningful errors and responsive content.
Use WCAG 2.2 as a technical reference for acceptance criteria. A menu is not complete if it works with a pointer but cannot be operated with a keyboard. Record the target, scope and person responsible for verification.
3. Understand real users and tasks
Accessibility is about whether people can find information, contact a service, book an appointment or complete a purchase independently.
Consider screen readers, keyboard navigation, magnification, voice control and other ways of interacting. Where possible, involve disabled people in research and usability testing rather than relying solely on assumptions.
4. Design the structure before coding
Plan headings, descriptive links, predictable navigation and understandable form instructions. Establish clear focus styles and sufficient contrast in the design system.
Accessible components should behave consistently across pages. Reviewing these decisions early is far easier than trying to repair every page after the visual design has been approved.
5. Develop semantic, robust interfaces
Use native HTML elements wherever possible: real buttons, correctly associated labels and logical document structure. Assistive technologies benefit from semantics that are built into the platform.
Dynamic dialogs, menus and tabs need appropriate keyboard interaction and understandable state changes. A WordPress plugin or page builder cannot guarantee this automatically; test the resulting interface.
6. Test throughout the project
Start with prototypes and repeat checks during development. Automated scanners are useful but cannot determine whether an entire booking or checkout journey makes sense.
Combine keyboard tests, screen readers, zoom and small screens. Document the steps to reproduce each barrier, assign a fix and retest the complete task.
7. Allocate time, budget and ownership
Accessibility work requires resources. Reserve time for design reviews, editorial guidance, manual testing and remediation rather than treating them as optional extras.
Identify who checks forms, who approves components and who can prevent a release when a critical task is blocked. Include third-party widgets and payment services in this responsibility.
8. Plan maintenance from the beginning
Updates, new content and plugin changes can introduce barriers after launch. Define regression checks for essential journeys and a process for reporting and resolving problems.
Record findings and verify fixes. Accessibility belongs across planning, design, development, testing and maintenance; a floating overlay is not a replacement.
9. A booking website example
Imagine a service booking flow. During planning, identify choosing a service, selecting a date, entering details and confirming a reservation as critical tasks.
Design clear labels and feedback, implement correct focus management and test the whole journey with a keyboard and screen reader. Waiting until launch may mean rebuilding the calendar component.
10. A practical next step
List three tasks visitors must complete. For each, define keyboard behaviour, screen-reader information and error handling before development begins.
Add WCAG 2.2 acceptance criteria, assign reviewers and test external components. The goal is to prevent barriers, not conceal them with a widget.