# Can an Accessibility Widget Make a Website Accessible? > What accessibility widgets and overlays can help with, where they fall short, and what to ask before buying one. Picture a customer using a screen reader to complete an online order. They leave a required address field blank. An error appears on screen, but the reader does not announce which field needs attention. The customer cannot work out what to correct and either abandons it or calls support. An accessibility icon may still sit in the corner of that page. Its menu may offer larger text, higher contrast, or reduced motion. Software running in the background may try to give an unlabeled button an accessible name. If the order still cannot be completed, the customer has not gained access. The business has lost a sale and created work for its support team. That example is hypothetical, but it is a useful way to assess an accessibility widget, overlay, or SaaS product. Do not start with its feature count or the time it takes to install. Start with a specific user, a specific task, and evidence that the task can now be completed. A widget can reduce some barriers and help some people immediately. Its presence does not, by itself, establish that a website is accessible or that an organisation has met its legal duties. The product's contribution and the work that remains with the organisation need to be clear. ## The legal context depends on the service and jurisdiction The rules vary by service and jurisdiction. In Türkiye, [Circular 2025/10](https://www.aile.gov.tr/media/219872/web_siteleri_ve_mobil_uygulamalarin_erisilebilirligi_hakkinda_genelge.pdf){target="_blank" rel="nofollow noopener"} sets web and mobile accessibility requirements for specified public and private bodies, including public institutions, banks, private hospitals, and certain education and transport organisations. It is not a blanket rule for every website. In the United States, the ADA's [Title II rule](https://www.ada.gov/resources/2024-03-08-web-rule/){target="_blank" rel="nofollow noopener"} gives state and local governments a detailed web and mobile-app requirement. For businesses covered by Title III, the Department of Justice’s [web accessibility guidance](https://www.ada.gov/resources/web-guidance/){target="_blank" rel="nofollow noopener"} says their online goods and services must also be accessible. The detailed Title II technical rule does not apply to those businesses. In the EU, the [Web Accessibility Directive](https://digital-strategy.ec.europa.eu/en/policies/web-accessibility){target="_blank" rel="nofollow noopener"} concerns public-sector websites and mobile apps. The [European Accessibility Act](https://commission.europa.eu/strategy-and-policy/policies/justice-and-fundamental-rights/disability/european-accessibility-act-eaa_en){target="_blank" rel="nofollow noopener"} has applied since [28 June 2025](https://digital-strategy.ec.europa.eu/en/news/eu-becomes-more-accessible-all){target="_blank" rel="nofollow noopener"} to defined products and consumer services, including e-commerce. It does not automatically cover every website or B2B SaaS product. Whether it applies depends on the service, any exceptions, and how the rules are implemented nationally. These differences explain why a visible button or a vendor dashboard cannot answer the compliance question on its own. ## What these tools actually do Products in this market tend to combine three kinds of work. - **Personalisation and runtime changes.** They let users change text size, contrast, or motion, and may attempt a limited repair after the page loads, such as adding a label to a button. - **Scanning and monitoring.** They identify potential problems and can check again as the site changes. A report helps a team identify what needs fixing; it does not fix the problems. - **Source remediation and testing.** Developer tools can help find problems in code and content. Expert review and testing with disabled users reveal whether a real journey works as intended. The third category provides the stronger base for a lasting improvement: fix the code or content where the barrier originates, then test the change. A widget may support that work. The result still needs to be checked against accessibility criteria and tested with users. ## Why a few repairs do not settle the question [WCAG 2.2](https://www.w3.org/TR/WCAG22/){target="_blank" rel="nofollow noopener"} does not require every accessibility improvement to originate in source code. A runtime change can reduce a real barrier if the page, keyboard behaviour, and information presented to assistive technology work correctly for the user. Conformance, however, is assessed across the whole page and the full process needed to complete a task. Repairing one button does not make a checkout accessible if the address error cannot be understood or the payment stage fails. A widget also cannot automatically repair every PDF, mobile app, embedded service, or third-party payment flow. Runtime fixes can fail for ordinary technical reasons. They may load late, be blocked by security controls, miss dynamically opened content, or break after a site update. A poorly applied change can also make keyboard use harder. Where flashing content creates a seizure risk, asking someone to turn on a setting after the page has loaded is not enough; the content itself must stay within the relevant safety limits. ## Use temporary help as a bridge, not a substitute Fixing barriers at the source can take time, particularly in a large organisation with legacy templates, outsourced services, documents, and mobile apps. While that work is underway, a display preference or a targeted runtime fix may still help someone complete a task today. Be clear about which problem the temporary fix addresses, when it will be replaced by a change to the site itself, and what happens if the provider’s service stops working. If an external payment service is inaccessible, the customer may need another way to pay. These temporary measures can help users while that work continues. Responsibility for fixing the underlying barrier remains with the organisation. ## What to ask before buying Ask the provider to explain what the product changes and where further work is still required. If possible, try it on a familiar, high-value journey on your own site: completing a form, making a purchase, requesting an appointment, or finding essential information. A short trial is not a conformance audit, but it can expose the gap between a feature list and a usable journey. You do not need to assess every technical detail alone. Bring in your technical team or an accessibility specialist when needed. The aim is to choose a tool that helps people complete tasks and helps your organisation remove the underlying barriers. A widget can be part of that effort. Installing one does not finish it. I want the articles on this site to be available to as many people as possible. I try to account for accessibility as I develop the site and prepare its content. My current goals, work, and known limitations are set out in my [accessibility statement](/accessibility). --- Language: English License: CC BY 4.0 License URL: https://creativecommons.org/licenses/by/4.0/ Scope: Evren Bal-authored text, unless this article expressly states otherwise. Excluded: Third-party material, quoted excerpts, logos, and separately marked images retain their own rights. Attribution: Credit Evren Bal, link to the canonical source and license, and indicate changes. Source: https://evrenbal.com/can-an-accessibility-widget-make-a-website-accessible