Accessibility is often treated as a checklist at the very end. Someone runs a tool, finds fifty errors and patches what they can before launch. It's the most expensive way to do it.
Who it's for
People use screen readers, magnification, keyboards or voice control. Some see poorly, some can't tell red from green, some have shaky hands. And everyone has days with sun on the screen, one free hand or a child on their arm.
Look at the same small booking through a few of these lenses in the graphic at the top. Then switch on "Built in from the start" and see what changes.
It's the law
In Norway, websites and apps aimed at the public must be universally designed. Private businesses must meet at least 35 success criteria from WCAG 2.0. The public sector must meet 48 from WCAG 2.1, and publish an accessibility statement. The Norwegian Authority for Universal Design of ICT follows up, and can issue daily fines.
The requirements are a floor. We design for people, not for the regulator.
Five things that matter most
- Text that can be read. Good contrast, and text that survives being enlarged.
- Colour is never alone. Red and green also need words or an icon.
- Everything has a name. Fields have visible labels, buttons have text, images have alt text.
- The keyboard reaches everywhere. Focus is visible, and the order makes sense.
- The structure is real. Headings are headings and lists are lists, so screen readers can jump straight to what matters.
Early is cheap
A bit of hierarchy, a colour or an order is free to change in a sketch. In code it's a ticket in the queue. After launch it's a project. So we bring it in from the first sketch, and into the design system, so no team has to solve it again.
Test with people, not just tools
Automated tools find some of the errors. They can't tell you whether a screen reader user actually gets through the booking. We test with real users, including people who use assistive technology. That's where we learn the most.
Accessibility isn't a separate feature. It's quality.