Feedback widgets are easy to forget in an accessibility review. They load late, sit in a corner or inside an iframe, and often come from a vendor. But a survey a keyboard or screen reader user cannot answer leaves those readers out of your results, and since June 2025 it can also be a legal problem for sites in scope of the European Accessibility Act.
This post explains what the Act covers, then goes through the WCAG 2.2 AA points that matter most for widgets and surveys. It describes the rules as of October 2026 and is not legal advice.
The short answer
If your website falls under the European Accessibility Act, everything on its pages counts, including a feedback widget or on-page survey. In practice that means meeting WCAG at level AA: every control works from the keyboard with a visible focus, questions and buttons have proper names, text and controls have enough contrast, targets are big enough to tap, motion can be turned off, and the widget never hides the content on a phone. An accessibility overlay script cannot fix a widget that gets these wrong.
What the European Accessibility Act covers
The European Accessibility Act, Directive (EU) 2019/882, sets common accessibility requirements for a list of products and services sold in the EU. Member states wrote it into national law, and those laws apply from 28 June 2025. Services in scope include:
- e-commerce: websites and apps that sell products or services to consumers;
- consumer banking services;
- e-books and the software used to read them;
- parts of passenger transport services, such as websites, apps and electronic tickets;
- electronic communications and access to audiovisual media services.
Microenterprises that provide services, those with fewer than 10 staff and an annual turnover or balance sheet of no more than 2 million euros, are exempt. Public sector websites already fall under a separate EU directive.
The Act does not name a feedback widget. It covers the service, and a widget on your checkout or product pages is part of that service. The European standard used to show conformity, EN 301 549, relies on WCAG 2.1 level AA for web content. WCAG 2.2 keeps those requirements and adds a few, such as minimum target size and focus not being hidden, so building to 2.2 AA covers both.
Make it work from the keyboard
Many readers use a keyboard, switch device or voice control instead of a mouse. For them, a widget is only usable if:
- every button, option and text box can be reached with Tab and used with Enter or Space;
- groups of options, such as star ratings or a 0 to 10 scale, work with the arrow keys like a set of radio buttons;
- the focused control has a clearly visible outline;
- focus is not hidden behind a sticky header, a cookie banner or the widget itself;
- a panel or dialog that opens moves focus into it, closes on Escape and gives focus back to the button that opened it;
- a closed drawer cannot be tabbed into by accident.
Give every control a name
Screen reader users hear a widget instead of seeing it, so everything must have a name that makes sense on its own:
- The question is the label of its answers. A screen reader should announce "Did this page answer your question?" with the Yes and No buttons, not just "button, button".
- Buttons say what they do in words. A thumbs icon on its own needs an accessible name such as "Yes" or "Helpful".
- Rating buttons say their value, for example "4 of 5".
- The iframe has a
title, such as "Article feedback", so readers know what it contains before they enter it. - Errors are announced when they happen, and the thank-you message is announced when it appears.
Check contrast, tap size and phone layouts
Widgets often take the brand colour, and brand colours often fail contrast checks. WCAG 2.2 AA asks for:
- a contrast ratio of at least 4.5:1 for normal text, including text on coloured buttons;
- at least 3:1 for the borders of controls, focus outlines and icons people need to see;
- a selected answer shown by more than colour alone, such as a border, a fill or a tick;
- targets of at least 24 by 24 CSS pixels, or enough space around smaller ones. Bigger is easier on a phone;
- content that still works at 320 pixels wide without scrolling sideways.
On phones, the biggest problem is usually placement, not the widget's own markup. A bubble or panel that covers the text, or a close button that sits off-screen, makes the page itself harder to use. A bottom sheet with a visible close button, or an inline widget at the end of the content, avoids both.
Let readers turn motion off
- Respect the reader's "reduce motion" setting. Slide-ins, pops and ripples should be cut back or switched off.
- Nothing should move, blink or scroll for more than five seconds without a way to pause it.
- Don't put a time limit on answering, and don't close the widget automatically while someone is still reading or typing.
- Avoid opening a survey on its own in the middle of the page. It interrupts everyone and can move screen reader focus without warning.
Why an overlay won't fix the widget
Accessibility overlays are scripts you add to a page that promise to repair problems automatically. They can change some things on your own page, such as font size or contrast settings. They cannot fix a feedback widget for three reasons:
- Most widgets run inside an iframe from another domain, and browsers do not let a script on your page change what is inside it.
- A missing label or a broken keyboard flow needs a decision about what the control means. A script guessing that from the page can't be relied on.
- Many screen reader users run their own assistive technology already. An overlay can get in its way.
The fix is in the widget itself and in how you place it on the page. Test both with a keyboard and a screen reader.
Example
Example: an online shop tests its product guides
Say you run an online shop that sells camping gear, with buying guides that end in a short survey. Your shop sells to consumers in the EU and has more than 10 staff, so you treat it as in scope of the Act.
You test the guides with the keyboard only. You can tab into the survey, but the star rating needs a mouse: each star is an image with a click handler, so Tab skips it. On a phone, the survey opens as a bubble that covers the "Add to basket" button until you close it, and the close icon has no name for a screen reader.
The brand orange on the "Send" button also fails the contrast check against its white text. You darken the orange in the widget settings, move the survey inline at the end of each guide, and ask the vendor when the star rating will work from the keyboard. Until then, you switch the question to Yes / No buttons, which work with any input.
What the Asklet widget does, and what is up to you
We aim for WCAG 2.2 AA in the Asklet widget. We don't claim certification or full conformance, so here is what it actually does:
- Each question is the label of its answer group. Yes and No are words on buttons at least 56 pixels tall, other buttons and choice options are at least 44 pixels tall, and star and 0 to 10 buttons are 36 pixels.
- Star ratings and number scales behave as radio groups, with arrow keys and a name for each value. Single and multiple choice questions use native radio buttons and checkboxes.
- Buttons, choice options, star and number buttons and the comment box show a visible focus outline.
- The progress bar has a label, a failed save is announced as an alert, and the thank-you and "already answered" messages are announced as status updates.
- With "reduce motion" on, slides, pops and ripples are switched off, and a Yes or No answer is sent at once. There is no time limit.
- The snippet you copy from the panel has a
titleon the iframe.
Some of it depends on your setup. You choose the header, text and button colours, so check their contrast. Placement is yours too: the placement ideas use native <details> and <dialog> elements, keep closed drawers out of the tab order and turn side panels into bottom sheets on phones, but check them in your own layout. Retest whenever you change the colours or the placement.
Your next steps
-
Answer your survey with the keyboard only
Tab in, answer every question, submit, and close any panel. Note anything you cannot reach or cannot see focus on.
-
Listen to it with a screen reader
VoiceOver on a Mac or iPhone and NVDA on Windows are free. Check that each question is read with its answers.
-
Check the contrast of your colours
Test button text against the button, and borders and focus outlines against the background.
-
Try it on a small phone
Make sure the widget never covers the content you want people to read, and that the close button is always visible.
-
Turn on "reduce motion" and try again
The widget and any panel around it should stop sliding and animating.
-
Ask vendors for their accessibility statement
Ask which standard they build to, how they test, and what known issues remain. Be wary of any claim of "full compliance".
Try these steps on your own site. Asklet adds the questions to every page with one snippet. Free plan, no card needed. Compare the plans.
Start freeCommon questions
Does the European Accessibility Act apply to my website?
It applies to the services it lists, such as e-commerce, banking and passenger transport, offered to consumers in the EU. Microenterprises that provide services are exempt. A blog or a company brochure site is usually outside its scope, but national laws differ, so check with an adviser.
Do I need WCAG 2.1 or WCAG 2.2?
The European standard used under the Act, EN 301 549, relies on WCAG 2.1 AA for web content. WCAG 2.2 AA includes those requirements and adds a few, so building to 2.2 AA covers both.
Can an accessibility overlay make my feedback widget compliant?
No. An overlay runs on your page and cannot change what is inside a widget's iframe. Missing labels, keyboard support and focus handling have to be fixed in the widget itself.
Is this legal advice?
No. It is general information about the European Accessibility Act and WCAG as of October 2026. Ask a lawyer about your own obligations.