ACCESSIBILITY ≠ OVERLAY · 35
Accessibility is not proven by a score: it is proven when people can use your website
📅 6 November 2026 · ⏱ 6 min read
A perfect automated score can coexist with serious barriers. Real accessibility means completing real tasks.
01. What an accessibility score actually means
A score summarises a defined set of checks performed under particular conditions. It does not represent every person, device or interaction. A homepage may receive an excellent result while the booking process, shopping basket or account area contains barriers that prevent someone from finishing a task. A more useful question is whether people can achieve their goals independently.
Automated scores are not worthless. They can reveal regressions and help teams track technical issues over time. The mistake is to treat one percentage as a universal guarantee. Accessibility is a quality of the whole service, including the content, interactions and outcomes that a visitor experiences.
02. What automated tools can detect
Automated checkers are good at finding certain machine-verifiable issues: missing image alternatives, some contrast failures, form fields without labels, invalid semantic relationships and incorrect attributes. They are particularly valuable when checking multiple templates or monitoring changes after a deployment.
Yet they cover only part of accessibility. A scan of the homepage says little about a modal, a validation message or a checkout flow. Results require interpretation, and warnings often need editorial judgement. No reported errors should be read as ‘nothing is wrong’, not as evidence that the experience is inclusive.
03. What automated tools cannot understand
Software cannot reliably decide whether alternative text communicates the purpose of an image, whether instructions make sense without seeing the layout or whether a complex journey is understandable. Nor can a single test reproduce every browser, device and assistive technology combination.
A link labelled ‘click here’ may pass some technical checks while remaining meaningless when a screen-reader user navigates through a list of links. The problem is not the existence of a link but its unclear purpose. Human review must consider the task and the surrounding context.
04. When a perfect score hides real barriers
Imagine an online shop displaying a perfect accessibility score. Buttons have names and images have alternatives, yet opening the basket moves focus nowhere. Keyboard users cannot reach the close control, and closing the panel returns them to an unexpected place. The transaction becomes impossible despite the attractive report.
Other examples include errors indicated only by red borders, controls that require dragging, or confirmation messages that disappear too quickly. A static page can look technically clean while an important interaction fails. Test complete tasks, not merely screenshots or individual URLs.
05. Keyboard navigation as an essential test
Put the mouse aside. Use Tab and Shift+Tab to reach links, buttons and inputs; activate controls with Enter or Space as appropriate. Check that focus is visible, moves logically and remains manageable when menus, dialogs or dynamic components open.
Reaching a control is only the beginning. People must be able to activate it, dismiss it and continue their journey. Focus traps without an exit, unexpected jumps and disappearing indicators are serious barriers. Record the exact steps and repeat the test after making changes.
06. Screen readers: beyond labels
A screen reader exposes how headings, landmarks, links, controls and status messages are announced. A visually large line is not necessarily a heading in the accessibility tree. An icon-only button without a name may be announced without meaning. Structure should support orientation independently of appearance.
Listen to what happens after actions. Is a validation error announced? Does the message identify the affected field? Is an item-added confirmation communicated? Can the user find the main content again? These questions reveal the practical limits of a single global score.
07. Forms, errors and complete journeys
Forms often contain barriers that automated reports cannot fully describe. Instructions may arrive too late, required fields may be unclear and errors may provide no recovery guidance. A usable form explains expectations in advance and lets people correct mistakes without losing their work.
Assess the complete journey from opening the service to receiving confirmation. An accessible information page is little help if the appointment calendar cannot be operated with a keyboard. In ecommerce, success means completing the purchase, not merely opening the basket.
08. Visual design, zoom and understanding
Contrast, focus visibility, target size, spacing and responsive behaviour all matter. Test substantial browser zoom and confirm that essential information remains visible without unnecessary two-direction scrolling. Never rely solely on colour to communicate a status or error.
Clear language matters as well. Descriptive headings, meaningful button names and consistent navigation help visitors predict outcomes. An interface that unexpectedly changes its behaviour may be difficult even when its individual controls satisfy isolated technical checks.
09. WCAG 2.2: a standard, not a trophy
WCAG 2.2 provides testable success criteria and a shared language for teams. It supports requirements, audits and verification of fixes. However, an automated percentage is not a WCAG conformance claim. No single scanner can establish that every applicable criterion has been met.
Use the guidelines within a wider method: code review, manual inspection, functional testing and input from people with disabilities. An accessibility statement should accurately describe the service and known limitations rather than promise unverified perfection.
10. Testing with people and assistive technology
People with disabilities can reveal barriers, workarounds and expectations that project teams overlook. Observe realistic tasks and listen carefully, without assuming one participant represents everyone. Different disabilities, preferences and technologies expose different issues.
Prepare scenarios such as finding information, booking a service, updating a preference or downloading a document. Record what happened, where the person became blocked and the impact on their goal. Prioritise critical failures and test the corrections again.
11. Why an overlay is not a solution
An accessibility overlay may provide presentation controls, but it cannot replace semantic HTML, a properly constructed form or reliable keyboard and screen-reader interaction. It cannot determine whether instructions are understandable or whether a complex transaction works end to end.
Installing a widget does not automatically make a website conform to WCAG 2.2. The extra interface may itself need accessibility testing. Sustainable improvement requires fixing the original product, assigning ownership and maintaining the result.
12. Building continuous improvement into delivery
Begin with the website’s most important journeys and the templates they use. Combine automated checks with keyboard, focus, structural, form, zoom and screen-reader testing. Log issues with reproducible steps, severity and a responsible owner.
Then build checks into content publishing, design reviews and updates. Retest shared components and critical tasks after changes. The goal is not a number to display in a report: it is a service that more people can use independently and confidently.