ACCESIBILIDAD ≠ OVERLAY · 29

Website accessibility does not depend on a floating button

📅 28 October 2026   ·   ⏱ 9 min read

A floating button can change the appearance of a page. But when someone cannot complete a form, navigate a menu with a keyboard or understand an error, accessibility depends on the website itself.

01. Accessibility cannot be installed at the end

Overlays commonly offer contrast, font-size or spacing adjustments. Such preferences may help some users, but they do not automatically repair underlying components.

Accessibility belongs in research, design, development, content and ongoing maintenance. The important question is whether people can complete real tasks.

02. Look beneath the visual layer

An icon-only button needs an accessible name. An email field needs an associated label. Headings need a meaningful hierarchy so people can explore content efficiently.

Changing colours or typography does not automatically communicate missing semantics to screen readers.

03. A checkout that cannot be completed

Imagine an online shop with an accessibility widget. A customer adds an item to the basket, but when a confirmation dialog opens, keyboard focus remains behind it.

Increasing text size does not solve this. Developers must manage focus, keyboard controls and the dialog’s closing behaviour correctly.

04. Content can create barriers

Informative images need appropriate text alternatives. Links such as ‘click here’ can be meaningless out of context. Error messages should explain what happened and how to recover.

Clear language, sensible instructions and readable structure are essential parts of accessibility.

05. Keyboard and assistive technology

Try navigating with Tab and Shift+Tab. Check that focus is visible, controls activate with Enter or Space, and menus do not trap the keyboard.

Then test forms and feedback with a screen reader. Consider magnification, mobile devices and alternative interaction methods too.

06. What an overlay cannot guarantee

A floating widget does not demonstrate WCAG conformance or replace an accessibility audit. Automated checks catch some issues but cannot fully assess comprehension and real-world usability.

Accessibility also needs ongoing attention: new forms, templates and updates can introduce fresh barriers.

07. A practical five-minute check

Choose a common task such as contacting the organisation or completing a purchase. Put the mouse aside and try the entire process using only the keyboard.

Note invisible focus, missing labels, confusing errors and blocked steps. Repeat with assistive technology and prioritise fixes at source.

08. Building accessibility that lasts

Use semantic HTML, accessible components and clear information architecture. Provide visible focus, understandable control names, helpful errors and usable forms.

Use WCAG 2.2 as a reference, combine automated checks with manual testing, and make accessibility part of routine maintenance. Accessibility is built, not added by a button.