Accessibility overlays or remediation: how to evaluate proposals

When deciding between an accessibility overlay and remediation, do not start by comparing feature lists or licensing models. Ask for evidence that users can actually complete your essential tasks: find information, use an account, correct a form or complete a purchase. An additional control panel may make individual settings easier to access. It does not establish that these journeys are accessible or that legal requirements have been met. What matters is the effect within your particular system, the limits of the solution and accountable responsibility for remaining barriers.

For procurement, this means favouring proposals that connect root causes, interventions, testing and ongoing operation in a transparent way. An additional technical layer may have a limited role, but it must not replace assessment of the underlying website. The examples below are explicitly hypothetical procurement situations, not documented client outcomes. Content reviewed: 7 November 2026.

1. Establish what is actually being offered

The term overlay covers different products. Some provide a panel for adjusting font size, contrast or motion. Others modify page elements after loading, add attributes or attempt to correct errors automatically. Other proposals combine software with manual assessment and development services. Evaluate the individual services rather than the product label alone. Ask the supplier to explain which changes actually occur, when they run and which parts of the website remain untouched.

Here, remediation means correcting the responsible source: HTML, a shared component, CSS rules, editorial content or process logic. A form field might receive a correctly associated label in its template rather than a name inferred after the page has loaded. Source-level corrections also require testing. Their advantage is not automatic perfection, but a traceable foundation that can be maintained independently of an additional runtime script.

2. Base your specification on user journeys

A list of URLs is rarely enough to define the work. Describe tasks with a starting point, necessary steps and an expected outcome. For a hypothetical online shop, one journey could lead from product search through variant selection to order review. It should also cover unavailable variants, empty search results, invalid entries and an expired session. These states are often absent from demonstrations, even though they determine whether people can use the service independently.

Also record which shared components, languages, documents and external services are in scope. Ask explicitly about embedded payment services, appointment booking and cookie dialogs. A proposal that examines only the homepage or selected default states is not equivalent to a journey-based audit. Representative sampling can be appropriate, but its selection and limitations must be transparent. The eventual acceptance record should return to the same user journeys.

3. Separate convenience features from essential accessibility

Additional settings can be useful, for example when someone wants to select larger text directly on a website. However, many users already rely on browser zoom, operating system settings, personal colour schemes or assistive technologies. A website should support these approaches without requiring people to find and understand a special menu first. A second settings system can complement existing preferences, but should not silently override them or hide a necessary basic function.

Therefore, test the underlying presentation without an additional profile activated. WCAG 2.2 addresses, among other things, text resizing to 200 percent and reflow at a width of 320 CSS pixels, within the scope and exceptions of the respective criteria. It does not prescribe a particular font family. Its text spacing requirements also concern users being able to apply specified spacing adjustments without losing content or functionality; they do not require every website to use those settings by default. Offering a font menu does not demonstrate these properties.

4. Ask for a technical explanation of every correction

For typical defects, request a comparison showing the cause, the intervention and how its effect will be verified. If an icon button lacks an accessible name, a targeted addition may help. An automatically generated name is only useful, however, if it describes the actual function. Where two identical icons trigger different actions, appearance alone cannot reliably establish their meaning. An informed decision about the interface remains necessary.

Runtime corrections can also depend on loading order, selectors and dynamic updates. Ask whether a correction survives a filter change, whether it runs twice when a dialog reopens and how frontend changes are detected. A documented interim solution may be reasonable for a legacy system that is difficult to modify. It still needs a defined scope, regression tests and a plan for replacement or continued maintenance. Without this information, “automatically fixed” is not a dependable description of the service.

5. Require more than an automated test report

Automated checks are valuable for finding certain technical issues quickly and repeatedly. They can, for example, flag missing labels or some contrast problems. They cannot reliably decide whether a label is understandable, a focus sequence remains meaningful or an entire task can be completed. The W3C guidance on selecting evaluation tools makes clear that tools cannot assess every aspect of accessibility and that human evaluation remains necessary.

A persuasive proposal therefore distinguishes automated methods from manual ones. It describes keyboard testing, assessment with selected screen reader and browser combinations, and checks at increased magnification and narrow viewport widths. For each finding, request reproducible steps, the affected state, its impact and a justified mapping to the evaluation standard. A green dashboard or a single overall score does not replace this evidence. Conversely, the limitations of automated testing do not establish that every overlay is harmful; they limit the conclusions that can reasonably be drawn.

6. Test forms through to successful correction

Suppose a hypothetical enquiry form marks an invalid telephone number only with a red border. An additional mode might change the colours, but that does not resolve the missing error message or its association with the field. Effective remediation includes a clear label, any necessary instructions and actionable guidance for correction. Information already entered should remain available while the user fixes the error. The WAI Forms Tutorial explains the connections between labels, grouping, instructions and feedback.

For acceptance testing, have the evaluator deliberately trigger an error, identify it using the keyboard and a screen reader, and then correct it. Record not only the visible message, but also its programmatic relationship and the successful continuation of the task. Next, examine the success state: is it clear whether the enquiry was submitted? Can a necessary confirmation be perceived? This prevents a proposal from improving only the ideal, error-free route while excluding precisely those situations in which users need support.

7. Test dialogs and dynamic states

A hypothetical shopping basket opens as a modal dialog. Although its close button now has a name, keyboard focus still moves into the page behind it. The problem has not been resolved. A modal dialog needs coherent opening behaviour, an appropriate initial focus position, Tab navigation contained within the dialog and meaningful focus restoration when it closes. The ARIA Authoring Practices Guide: Dialog (Modal) Pattern describes this interaction, including dismissal with Escape. ARIA attributes alone do not implement it.

Acceptance testing should open the dialog, operate it fully, close it and reopen it. Different content states also need testing, such as an empty basket and an error after a quantity change. For dynamically filtered results, assess separately whether a qualifying status message is programmatically determinable without moving focus. The entire new result content does not necessarily need to be announced automatically. What matters is feedback that lets users understand the change and choose their next step independently.

8. Assess third-party risks independently of marketing claims

An externally loaded script adds a technical dependency to your website. Establish what data is processed, which network connections occur, which subprocessors are involved and whether configurations or usage events are transmitted to the provider. These are questions for investigation, not allegations about particular behaviour. Privacy, information security and development stakeholders should assess them together. Potential conflicts with Content Security Policy, consent management and other scripts also belong on the checklist.

Test failure conditions as well: what happens if the service is blocked, responds slowly or is no longer licensed? Critical tasks should not become silently dependent on an apparent convenience feature. Agree on a controlled way to disable the service, responsibilities during incidents and notification of relevant product changes. If a supplier demonstrates its effect only with the extension enabled, also request a comparison without it. This reveals which underlying barriers remain and which risks return when the contract ends.

9. Turn promises into contractual deliverables

A contract should promise more than “improving accessibility”. It should identify the evaluation standard, the elements assessed, the findings to be resolved and the evidence required. For WCAG 2.2 AA, this includes the applicable success criteria at both Level A and Level AA. EN 301 549 is not interchangeable with that standard. Similarly, a technical audit is not a complete assessment of legal compliance. Separate technical acceptance, organisational duties and any necessary legal advice.

In Austria, the BaFG has applied to covered services since 28 June 2025, not automatically to every website. Use the Austria guide to accessible websites to assess your offering rather than inferring an obligation merely from having a website. The procurement contract should also address corrective work, retesting, access to the issue tracker and handover of changes. Require outstanding issues to be stated explicitly rather than concealed beneath a sweeping claim such as “fully covered”.

10. Agree on acceptance testing that can reproduce defects

Useful evidence includes a finding identifier, the affected version, prerequisites, test steps, expected behaviour and the actual result. Screenshots can supplement this, but alone they are insufficient for focus behaviour or screen reader output. Record the test environment and observations as well. A finding should only be closed when the previously blocked task demonstrably succeeds and the change introduces no observable new problems in the associated journey.

Retesting should cover both the specific correction and neighbouring states. If a shared button component has changed, assessment extends beyond the button originally reported. If a form has been rebuilt, check its error messages and confirmation as well. Agree who performs the retests and how disagreements will be evaluated. Independent assessment can help, but does not replace precise criteria. Testing with users can also usefully complement technical assessment without, by itself, covering every criterion.

11. Compare the full operational effort

Compare recurring licence costs, initial analysis, development effort, testing, editorial work and maintenance separately. An apparently small deployment can create long-term dependencies; a more extensive source-level correction can also require regular maintenance. Meaningful comparison does not need invented savings figures: which recurring tasks arise, who handles them and which changes trigger fresh testing? Pay particular attention to the effort required after a relaunch or the replacement of a third-party service.

Request a handover plan for components, documentation and editorial rules. W3C guidance on Sustaining Accessibility emphasises embedding accessibility through responsibilities, checks and skills development. WCAG does not prescribe a universal monthly or annual audit schedule. Choose your testing routine according to the frequency of changes and the associated risk: a new checkout needs different attention from an unchanged contact page. What matters is that relevant changes do not reach production without appropriate checks.

12. Make the decision using transparent evidence

A practical comparison matrix links each important user journey to its root cause, proposed measure, intervention point, responsible party and acceptance evidence. Add dependencies and remaining limitations. This makes different proposals comparable: a preferences panel, a temporary runtime correction and a sustainable component revision may address different needs. They should not be artificially treated as equivalent alternatives. A combined proposal can also make sense when its services are clearly separated and verifiable.

Warning signs are not simply particular product categories, but unlimited promises without a defined scope, refusal to disclose testing details and acceptance based exclusively on a score. Positive signs include clear limitations, understandable defect examples and willingness to test a critical user journey in a pilot. Start by commissioning the evidence you lack for an informed decision. That might be an independent audit, a limited technical trial or an assessment of a particularly important component.

Frequently asked questions

Is every accessibility overlay unsuitable?

No. Individual features may be helpful. What matters is which problems are demonstrably resolved, which remain and whether the product supports existing ways of using the website. The product category alone cannot replace evaluation.

Is a clean automated scan enough?

No. It establishes only that the tool found no errors it could detect under the particular test conditions. Keyboard operation, understandable feedback and complete user journeys require additional assessment.

Can an interim solution be part of a proposal?

Yes, provided its scope, limitations, maintenance and exit arrangements are defined. It should not be presented as lasting remediation if the underlying barrier returns unchanged when the solution is switched off.

What should we commission first?

If you lack a reliable baseline assessment, begin with a clearly scoped audit of your most important journeys. The findings provide a sound basis for specifying remediation, supplementary tools and retesting.

Your next step with Zensations

Zensations is a digital studio founded in Vienna in 2010. If you want to compare proposals or review existing measures, an accessibility audit provides a useful starting point for transparent priorities and acceptance criteria. For subsequent work on design, technology and processes, see the accessibility service. The objective is a verifiable improvement to your actual user journeys, not a blanket guarantee of compliance or search rankings.

Sources

• W3C: Web Content Accessibility Guidelines (WCAG) 2.2 – the normative technical evaluation standard.
• W3C WAI: Selecting Web Accessibility Evaluation Tools – capabilities and limitations of evaluation tools.
• W3C WAI: Forms Tutorial – accessible forms and feedback.
• W3C WAI: Dialog (Modal) Pattern – keyboard and focus behaviour for modal dialogs.
• W3C WAI: Sustaining Accessibility – maintaining accessibility in ongoing operations.