ACCESIBILIDAD ≠ OVERLAY · 31
Accessibility ≠ Overlay: ongoing maintenance is essential for accessibility
📅 30 October 2026 · ⏱ 6 min read
A website that is accessible today may develop barriers tomorrow. Updates, new content and redesigned components require regular checks rather than reliance on a floating widget.
01. Accessibility does not end at launch
Passing an accessibility audit is a milestone, not a permanent guarantee. Every change to a template, form or content block can alter how someone experiences the site.
A useful question is not just whether the website passed a test months ago, but how new barriers are detected before users encounter them.
02. Updates can change interactions
WordPress, Divi and plugin updates may change menus, focus behaviour, dialogs and forms. A seemingly minor visual adjustment can hide controls when text is enlarged.
Test important updates in a staging environment and repeat essential journeys before deploying changes to the live website.
03. New content needs editorial checks
An image without meaningful alternative text, an unclear link or an illogical heading structure can create a barrier even when the underlying template is sound.
Give editors a short checklist for headings, links, image alternatives, table structure and understandable instructions.
04. Test every new form
A new enquiry form might look fine with a mouse while missing labels or displaying errors only through colour. These failures can prevent someone from contacting the business.
Check labels, required fields, error explanations, keyboard navigation and confirmation messages before publishing.
05. Keyboard focus and dialogs matter
Use Tab and Shift+Tab to explore navigation, menus and essential actions. Focus should be visible, follow a sensible sequence and never become trapped.
When a dialog opens, focus should move appropriately and return to a logical place after the dialog closes.
06. Check zoom, mobile and assistive technology
At 200% browser zoom, content and controls should remain available without overlapping or disappearing. Test narrow screens and different orientations as well.
Use a screen reader to inspect headings, accessible names, instructions and changes of state that are not obvious visually.
07. Automated checks have limits
Scanners can flag some contrast failures, missing names and markup issues. They cannot decide on their own whether a complex checkout is understandable.
Combine automated findings with manual testing and, where possible, feedback from disabled people. A scanner score is not proof of WCAG conformance.
08. Create a practical maintenance schedule
Review critical journeys after significant updates. Check new content before publication and periodically inspect shared templates, forms and navigation.
Record the date, owner, findings and fixes. A repeatable process is more reliable than depending on one person’s memory.
09. Prioritise blockers
A barrier preventing payment or form submission generally deserves attention before a minor cosmetic issue. Record how to reproduce each problem.
Assign ownership, fix the underlying component and retest the affected task rather than treating the issue as a one-off visual defect.
10. An overlay cannot replace maintenance
A floating panel may change presentation, but it cannot guarantee correct keyboard behaviour or meaningful form errors after a website update.
Accessibility belongs in design, development, editorial workflows and quality assurance. Fix causes, not just symptoms.
11. A small action plan
Choose three real tasks: find information, contact the business and complete a transaction. Test them without a mouse, with zoom and with clear error handling.
Then decide who will test future changes and which checks must pass before release. Use WCAG 2.2 as the technical reference.