SaaS Feedback Widget Accessibility Checklist

Before you publish a website feedback widget, check that its controls have clear labels, work with a keyboard, remain readable at different contrast settings, fit on mobile, and respond appropriately to reduced-motion and colour-scheme preferences. Then test the widget on your live site with a keyboard and a screen reader. A widget can be usable while the page around it still creates barriers, so check both.

Start with this pre-launch checklist

1. Check labels and instructions. The launcher, feedback-type choices, message field and submit button should each have a clear name. Visitors should be able to tell what information to enter and what will happen when they submit.

2. Use the widget without a mouse. Tab through the launcher and form controls, use the keyboard to select a feedback type, enter a message and submit it. Check that focus stays visible and moves in a sensible order, with no point where keyboard users get stuck.

3. Check text and control contrast. Test the closed launcher and the open form against their backgrounds. Pay particular attention to small text, placeholder text, borders and focus indicators. For a useful reference, W3C guidance describes minimum contrast ratios for text.

4. Open it on a phone. Make sure the launcher does not cover navigation or an important action. Open the form and check that its fields and submit button fit on screen and remain usable at a narrow width, including when text is enlarged.

5. Test light and dark colour schemes. Check that text, controls and focus indicators stay clear in each theme. Colour should not be the only way to distinguish an error, selected option or other important state.

6. Check reduced motion. Turn on the device or browser’s reduced-motion preference, then open and close the widget. Look for unnecessary movement or transitions that remain active. W3C explains how interaction-triggered animation can be made avoidable for people who prefer less motion.

Test with a keyboard and screen reader

A visual check can catch low contrast or overlapping controls, but it will not tell you whether a screen reader announces the controls clearly. Ask an editor to test the live widget before publication using a keyboard and a screen reader. They should be able to find and open the launcher, identify each feedback option and field, enter a message, submit it, and understand the success message. W3C’s keyboard guidance also gives a useful basis for checking that the interface can be operated without a pointer.

Use the editor’s live preview to inspect the open and closed states, and capture a screenshot of the actual widget configuration you plan to publish. The preview helps you review appearance and wording; it does not replace testing the installed widget on your own pages. If the live test exposes a problem, record the page, device and steps needed to reproduce it, then test again after making a change.

Separate widget checks from site checks

A widget provider can supply labelled controls and theme options, but you are responsible for checking how the widget behaves within your site. Your page layout, fixed navigation, cookie notices, colour choices and other overlays can affect whether people can see or reach it. Test it on the pages where visitors are likely to need it, not only on a blank test page.

Feedback Bubble provides accessible labels and controls, plus Auto, Light and Dark theme settings. Auto follows the visitor’s colour preference. Its submission context can also include the visitor’s colour-scheme and reduced-motion preferences. Those details are not proof that every interaction behaves as intended: verify the current live widget with your own keyboard and screen-reader tests. The available product information does not establish formal WCAG conformance, so do not describe the widget or your site as conformant without an appropriate audit.

Make the check part of your release

Keep a short record of the browser, device, assistive technology and page you tested, along with any issues you found. Repeat the check after changing the widget’s wording or design, or after a site update that affects its position or surrounding controls. This gives a small team a practical way to catch regressions without treating one successful test as a guarantee for every visitor.

If you use Feedback Bubble, open the bubble editor’s live preview, then test the installed widget on your site before publishing it.