Accessibility · Compliance
Accessible design reaches more people and reduces risk. Here is what it involves and how to build it in from the start.
Accessibility means making your website or app usable by as many people as possible, including those with visual, hearing, motor or cognitive disabilities, and those using assistive technology such as screen readers or keyboards instead of a mouse. It is good design, good business and, increasingly, a legal expectation in many places.
It is also commonly misunderstood, or left until it is too late to build in cheaply. This guide explains why it matters now, what the core requirements look like in practice and how to approach it without turning it into a huge project. It is general information, not legal advice.
Why it matters
- People. A large share of any audience has some form of disability, temporary or permanent, and many more benefit from clearer, simpler design.
- Law and regulation. Requirements differ by country and sector. In the European Union, accessibility rules covering certain digital products and services have applied since mid-2025, with exemptions that include some very small businesses. In the US, website accessibility is the subject of frequent legal claims. In the UK, equality law applies to service providers. Check what applies to you.
- Customers and contracts. Larger clients and public bodies increasingly ask suppliers about accessibility.
- Everyone benefits. Clear structure, readable text and keyboard support help all users, including those on phones in bright sunlight.
The standard most people use
The most widely referenced guidance is the Web Content Accessibility Guidelines, usually shortened to WCAG, with level AA the common target. It is organised around four ideas: content should be perceivable, operable, understandable and robust.
A practical checklist
| Area | What to do |
|---|---|
| Colour contrast | Make sure text stands out clearly from its background. A common AA guideline is a contrast ratio of at least 4.5 to 1 for normal text |
| Keyboard use | Every action should work without a mouse, with a visible focus indicator showing where you are |
| Text alternatives | Give meaningful images a short description, and mark decorative ones as such |
| Headings and structure | Use headings in a logical order so screen reader users can navigate |
| Forms | Label every field clearly, and make error messages specific and easy to find |
| Link and button text | Say what happens, not “click here” |
| Zoom and reflow | Content should remain usable when text is enlarged or the screen is small |
| Media | Provide captions for video and transcripts for audio |
| Motion | Avoid flashing content, and let users pause or stop moving elements |
| Language and consistency | Use plain language and keep navigation consistent |
Accessibility in web apps
Apps add extra challenges: dynamic content, pop-ups, data tables and custom controls. Test that dialogs can be opened and closed with a keyboard, that status changes are announced and that tables are understandable without sight. Choosing components and plugins with accessibility in mind helps, because custom-built widgets often lack the support users rely on.
How to approach it without overwhelm
- Decide your target, typically WCAG AA, and write it into the project requirements.
- Design for it from the start. Colours, type sizes and layouts are far cheaper to get right in the design than to fix later.
- Test with keyboard only. Try to use the key flows without a mouse.
- Use automated checkers, which catch many issues but not all.
- Test with real assistive technology, or with disabled users where possible.
- Publish an accessibility statement and a way to report problems.
- Review regularly, especially after design changes.
Build it into the plan
Accessibility belongs in your PRD and your design, not as a late patch. For product builds, a Discovery Sprint is the place to set the target. For websites, email us your page list and the standard you need, and we will include it in a scoped quote. Related reading: our security guide and what to cut before you build.
Frequently asked questions
Does accessibility make a site ugly?
No. Accessible sites can be beautiful. It limits a few choices, such as very low-contrast text, and often improves clarity.
Is it expensive?
Building it in from the start adds little. Retrofitting an inaccessible site costs far more.
Do small businesses need to worry?
Requirements vary, and some very small businesses are exempt in some places. It is still good practice and can be a selling point.
Can an overlay plugin fix everything?
No. Quick-fix overlays do not replace properly built, tested accessibility and are widely criticised by accessibility experts.
Want your site or app built to be accessible?
Email us what you are building and where your users are. We will include accessibility in the plan from day one.
Athar Ahmad, Certified Bubble.io Developer and Tech Architect, Simple Automation Solutions
