Accessibility
Building so the site works for people using a keyboard, a screen reader or a phone in bright sunlight — which is a much larger group than most people assume.
Inclusive design
Chosen per project
Maintainable handover
Accessibility is usually discussed as a legal or moral obligation, and it is both. It is also ordinary quality: keyboard navigation, sufficient contrast and clear labels help everyone, including a user on a phone outdoors and an operator who works faster without touching the mouse.
Most of it costs nothing when built in. Correct headings, real buttons, labelled inputs and visible focus are decisions, not features. Retrofitted later, the same outcomes take considerably more work.
What we build with Accessibility
Public-facing sites with a broad audience
Applications used all day by staff, where keyboard operation matters
Tenders and buyers that specify an accessibility standard
Auditing an existing site to find out where it stands
Where it fits — and where it does not
Good fit when
Any public website
Internal tools used intensively by staff
Products sold to institutions with procurement standards
Consider something else when
Overlay widgets that claim instant compliance — they do not deliver it
Treating an automated scan as proof; it finds a minority of real issues
How an accessibility review runs
Automated checks come first because they are cheap, not because they are sufficient.
Automated scan
Catches contrast, labels, alt text — perhaps a third of issues.
Keyboard pass
Every journey without a mouse; focus order and traps.
Screen reader pass
What is actually announced on the key flows.
Prioritised fixes
Ranked by user impact, not by scanner severity.
How we work with Accessibility
Semantics first
Real headings, buttons, lists and landmarks, which resolves a large share of issues before any ARIA is considered.
Keyboard only
Every journey completed without a mouse, with focus always visible and never trapped.
Contrast checked
Text and interface contrast verified against WCAG AA rather than judged by eye.
Tested with a screen reader
Key flows walked through with an actual screen reader, because automated tools miss what matters most.
Our typical Accessibility setup
| Concern | What we use |
|---|---|
| Standard | WCAG 2.2 level AA as the working target |
| Automated | axe and Lighthouse checks run in CI |
| Manual | Keyboard and screen-reader passes on primary journeys |
| Components | Accessible states built into the design system |
| Output | Prioritised findings with the fix, not just the rule reference |
Frequently asked questions
It depends on your market and your buyers. Public-sector and institutional procurement frequently specifies a standard, and some export markets require it. Independently of that, it is a group of customers you would otherwise turn away.
No. Overlays sit on top of the underlying problems, and disabled users generally report they make things worse. The fixes have to be in the markup.
Built in from the start, very little — it is mostly a matter of using the right elements. Retrofitted onto a finished product, considerably more, which is the argument for deciding early.
Topics people search for
Services built with Accessibility
UI/UX Design
Interfaces designed around what people are trying to accomplish, then tested with them before development starts.
Website Development
A website is usually the first thing a prospective customer sees. It should load quickly, say something useful and be findable.
Web Application Development
Applications that run in the browser, handle real workloads and hold up when several departments depend on them at once.
Software Maintenance
Keeping working systems working — including ones built by somebody else.
Tell us what you are trying to build
Describe the problem in plain language and we will tell you what it would take to solve it — the approach, the moving parts and the sensible order to build them in. No obligation either way.