ACCESIBILIDAD ≠ OVERLAY · 30
Accessibility ≠ Overlay: 10 checks to find out whether your website is truly accessible
📅 29 October 2026 · ⏱ 4 min read
A floating icon does not prove accessibility. What matters is whether people can navigate, understand information and complete meaningful tasks. These ten practical checks focus on real experience.
01. Start with a task, not a widget
Choose a meaningful visitor goal: request a quote, book an appointment, purchase an item or find contact details. Follow the entire journey rather than merely checking for an accessibility button.
Record where the process becomes confusing or impossible. A website may appear polished yet prevent a visitor from completing the action that brought them there.
02. Test the complete keyboard journey
Put your mouse aside. Navigate with Tab and Shift+Tab, activate controls with Enter or Space as appropriate, and try every menu, form and confirmation step.
Unexpected focus order, unreachable controls and keyboard traps are functional barriers. An overlay that changes colours cannot repair the underlying interaction.
03. Check focus and modal dialogs
Make sure keyboard focus is clearly visible and not hidden behind sticky headers. When a modal opens, focus should move appropriately, stay within the intended interaction and return sensibly when it closes.
A checkout dialog that leaves keyboard focus behind the window is not usable. The dialog behaviour must be fixed in the site itself.
04. Listen with a screen reader
Use a screen reader to inspect headings, links, buttons and fields. Listen for meaningful names, sensible reading order and informative alternative text for relevant images.
Visual appearance does not supply missing HTML semantics. Assistive technologies need correctly associated labels, headings and state changes.
05. Inspect forms and error messages
Submit an empty form and enter invalid data. Check whether each error explains what happened and how to correct it, and whether required fields and labels are clearly identified.
A message saying only ‘Error’, or relying solely on red text, does not provide adequate guidance. Make validation understandable and associated with the relevant control.
06. Zoom, reflow and mobile layouts
Zoom the browser to 200% and inspect smaller screens. Essential actions should remain available, with no overlapping controls or unusable horizontal scrolling.
Text enlargement is only helpful when the layout adapts. A floating widget cannot compensate for broken responsive design.
07. Review content and semantic structure
Use a logical heading hierarchy, descriptive link text and plain instructions. Ensure informative images have appropriate alternatives and avoid embedding essential text in images.
Good content structure supports both screen-reader navigation and quick scanning. Accessibility is an editorial responsibility as well as a technical one.
08. Understand automated test limitations
Automated scanners can detect some missing names, markup problems and contrast failures. They cannot determine on their own whether a workflow is understandable or practical.
Combine automated findings with manual keyboard checks, assistive technology testing and, where possible, feedback from disabled users. A scanner score is not WCAG conformance.
09. Prioritise blockers and assign owners
Prioritise issues by their effect on real tasks. A blocker preventing payment or form submission normally matters more than a minor visual inconsistency.
Describe the issue, how to reproduce it, where it occurs and who owns the fix. Addressing a shared component is usually better than patching individual pages.
10. Retest after every change
A WordPress update, Divi module, plugin or new form can introduce fresh barriers. Include accessibility checks in routine publishing and maintenance.
Use WCAG 2.2 as a technical reference and document the tests performed. The objective is independent use, not the presence of a symbolic icon.