One Year After the Accessibility Deadline, Widgets Still Are Not a Strategy

One year after the European Accessibility Act became applicable, the easiest bad habit is still pretending an overlay solves accessibility. Widgets can add options. They cannot repair the underlying structure of a broken form, inaccessible navigation, missing labels, or confusing content.

Accessibility has to live in the site, not float above it.

Make source-level accessibility answer to a real-world case before choosing a solution. Picture the point at which a user encounters custom navigation, a modal, a form, and a third-party document despite an accessibility overlay being present. That is where claims meet behavior and where vague responsibility becomes expensive. A focused case also limits the scope enough for a small team to improve it without turning the entire website into an endless audit.

Fix the source experience

Real accessibility work touches design, code, content, media, documents, and QA. It asks whether users can perceive, operate, understand, and rely on the interface. That cannot be outsourced to a button in the corner.

For business owners, this is also a governance issue. New content and new features can reintroduce barriers.

• Use semantic controls instead of custom lookalikes where possible.
• Write clear labels and instructions.
• Test keyboard and screen reader flows.
• Check documents and third-party embeds.
• Make accessibility part of acceptance criteria.

Automation helps, but people decide

Scanners are useful for catching obvious issues. Manual testing and user-centered review catch the problems automation misses.

Accessibility is not a layer. It is how the product is built and maintained.

Test the Interface Beneath the Overlay

Test the example once in its happy path, then deliberately disturb the weakest dependency. The concern is that the widget changes presentation but cannot repair semantics, focus order, labels, or inaccessible embedded content. A useful disturbance might be stale content, invalid input, a missing permission, an interrupted request, or a different device. The aim is not exhaustive testing; it is learning whether source-level accessibility remains understandable when reality stops matching the demo.

Inspect Semantics, Focus, Forms, and Documents

Use successful manual testing of priority journeys, resolved barriers, and accessibility criteria applied to new work as the first evidence layer. Add examples from the actual journey so the figures retain meaning: a captured response, failed submission, unclear screen, outdated statement, or mismatched record. The examples should not be selected only to support the preferred conclusion. Look for counterexamples that show where source-level accessibility already works or where the proposed remedy has limits.

Make Source Accessibility a Procurement Requirement

Place accountability with product leadership with shared responsibility across design, code, content, and procurement. Ask that owner to maintain the canonical facts or rules, coordinate specialist fixes, and publish the review date where internal teams can see it. When responsibility changes, transfer credentials, documentation, and unresolved exceptions explicitly. source-level accessibility often fails quietly when knowledge leaves with a contractor or employee.

Repair Critical Barriers in the Product Itself

Address the failure most likely to block or mislead a real person: the widget changes presentation but cannot repair semantics, focus order, labels, or inaccessible embedded content. Use the least disruptive correction that solves the underlying problem and keep a copy of the previous state. Retest on another device, role, query, or input as appropriate. This reveals whether the remedy is robust or merely tuned to the one example used during development.

Use Automation Without Mistaking It for Conformance

A final boundary prevents false confidence: Automated scanning and optional user controls can help, but neither demonstrates conformance or usability on its own. Use the recommendation where its assumptions hold, and choose another method when they do not. The article’s promise is fulfilled when the business can identify one consequential source-level accessibility gap, repair it, and recognize recurrence. It is not fulfilled by adding another unchecked file, widget, report, or claim.

Implementation Checklist: One Year After the Accessibility Deadline, Widgets Still Are Not a Strategy

Work from the highest-dependency action outward. Confirm that you use semantic controls instead of custom lookalikes where possible, then verify you write clear labels and instructions. With those inputs settled, test keyboard and screen reader flows and check documents and third-party embeds. The final check is to make accessibility part of acceptance criteria. Do not mark a line complete merely because a setting exists; inspect the resulting page, response, record, or user outcome. The evidence should match the promise made by the checklist item.

Tie every completed item back to the reason for doing the work. Accessibility overlays cannot replace semantic markup, usable forms, content discipline, and real testing. If the Accessibility review cannot show movement toward that outcome, reconsider whether it measured the right thing. Labels such as Accessibility Widgets, WCAG, EAA are useful for discovery and ownership, but a specific captured result is what supports the decision. End with a dated finding and a trigger for retesting.

Photo by Pavel Danilyuk on Pexels.