Skip to main content
Web Accessibility Audits

Comprehensive accessibility audits to identify barriers and improve usability.

We conduct full WCAG 2.2 audits to ensure your web services meet all relevant legal accessibility requirements. Using industry standard testing methods, we provide everything you need to achieve and demonstrate full compliance.

Our audit process includes:

Expert manual testing against WCAG 2.2
Automated scanning for common and systemic issues
Assistive technology testing including keyboard accessibility, screen reader compatibility, and Dragon NaturallySpeaking interactivity
Visual and interaction testing (contrast, focus, forms, responsive behaviour)
Clear, prioritised remediation guidance mapped to WCAG success criteria
Optional remediation packages available following the audit
Get In Touch

Want to find out more about our Audits?

Get in touch for fast, friendly and personalised accessibility guidance today.

Our Blog

Latest from our blog

Cover image for Design Systems: Your Secret Weapon for Accessibility at Scale

Design Systems: Your Secret Weapon for Accessibility at Scale

Bria Stone

By Bria Stone

Accessibility feels overwhelming when every component, every page, every feature needs individual attention. There's a better way.Design systems let you bake accessibility into reusable components once, then use them everywhere. Fix an issue in the button component, and every button across your product gets better. Update focus styles in your system, and they propagate to hundreds of interfaces.This is how organisations scale accessibility without scaling effort. Let's look at how to build it right.Start with accessible foundationsYour design system is only as accessible as its base components. Get the fundamentals right from the beginning, or you'll be fixing the same issues across dozens of implementations.Build your colour palette with contrast in mind. Every text and background combination should meet WCAG standards. Document which combinations work together and why. Make it impossible to accidentally create low contrast pairings.Define focus states once. Make them prominent, consistent, and work across all components. Your developers shouldn't need to think about focus indicators. They should just work.Component-level accessibilityEach component should handle its own accessibility requirements. A button component manages keyboard interaction and ARIA attributes. A modal component implements focus trapping. A form component handles error announcements.Document the accessibility features built into each component. Developers using your system need to know what's handled automatically and what requires their attention. Make it clear, make it visible, make it hard to miss.When you discover an accessibility issue in a component, you fix it once and the fix propagates everywhere that component is used. This is the real power of design systems.Testing at the system levelEvery component in your design system should have accessibility tests. Automated tests catch regressions. Manual tests verify the experience actually works for users.Test keyboard navigation. Test screen reader behaviour. Test with different zoom levels. Test in high contrast mode. Build these tests into your component development workflow, not as an afterthought.Document test results alongside components. When developers pick a component from your system, they should know exactly how it behaves for all users, including those using assistive technologies.Governance and evolutionDesign systems aren't static. They evolve as your product grows and accessibility standards improve. Someone needs to own that evolution.Establish clear governance around accessibility updates. When WCAG releases new guidelines, who evaluates their impact on your system? When a component accessibility issue is discovered, who prioritises the fix?Make accessibility a required checklist item for any new component or significant update. Don't let inaccessible patterns enter your system in the first place.Documentation that actually helpsYour design system documentation should include specific accessibility guidance. Not generic statements about following WCAG, but concrete examples of how to use components accessibly.Show good and bad examples. Explain why certain patterns work and others don't. Include code snippets demonstrating proper implementation. Make it easier to do the right thing than to get it wrong.Document keyboard shortcuts, ARIA usage, and expected screen reader behaviour for complex components. Your developers shouldn't need to reverse engineer how accessibility works.The compound effectDesign systems create a compound effect for accessibility. Every improvement you make gets multiplied across every implementation. The effort you invest upfront pays dividends across your entire product portfolio.Compare this to the alternative: every team implementing their own components, making their own accessibility decisions, fixing their own issues. The duplication is massive. The inconsistency is confusing. The maintenance burden never ends.A well built design system doesn't just make accessibility easier. It makes it sustainable. That's how you build inclusive products at scale without burning out your team.

Read more
Cover image for Keyboard Navigation: The Complete Guide for Developers

Keyboard Navigation: The Complete Guide for Developers

Bria Stone

By Bria Stone

If you can't use your product with a keyboard alone, it's not accessible. Full stop.Keyboard navigation affects more users than you might think. People with motor disabilities, repetitive strain injuries, or those who simply prefer keyboard shortcuts. It's not a niche concern.Yet we consistently see products where critical features are completely unreachable via keyboard. Custom dropdowns that trap focus. Modal dialogs you can't escape from. Buttons that require a mouse click.Let's fix that. Here's everything you need to know about implementing proper keyboard navigation.The tab order mattersUsers navigate through your interface using the Tab key. The order they encounter elements should follow a logical, predictable path. Typically, that means left to right, top to bottom, matching the visual layout.Don't mess with the natural tab order using tabindex values greater than 0. It creates confusion and makes your site harder to navigate. If your tab order feels wrong, the solution is usually to restructure your HTML, not force a different order.Only interactive elements should be in the tab order. That means links, buttons, form inputs, and custom interactive widgets. Regular text and decorative images should be skipped.Focus management in single page appsTraditional websites handle focus automatically when you navigate to a new page. Single page applications don't work that way. Route changes happen without a page refresh, and focus often stays wherever it was.When your app navigates to a new view, move focus to a logical starting point. Usually that's the main heading of the new page. This tells keyboard and screen reader users that the content has changed and where they are now.Skip links deserve a mention here too. They let users jump past repetitive navigation directly to main content. Essential for keyboard users who don't want to tab through your entire header on every page.Building accessible custom widgetsStandard HTML controls work with keyboards out of the box. Native buttons, links, and form inputs all behave correctly without extra work. Problems start when you build custom components.If you're creating a custom dropdown, modal, or any interactive widget, you need to handle keyboard interaction yourself. That means implementing proper ARIA roles, managing focus, and responding to the right keyboard events.Arrow keys should navigate within components like menus and tabs. Escape should close dialogs and cancel operations. Space and Enter should activate buttons. These patterns are established conventions. Follow them.Focus traps and modal dialogsWhen a modal opens, focus should move to it and stay there until it's closed. Users shouldn't be able to tab out and interact with the page behind it. That's what we call a focus trap, and in this case, it's exactly what you want.Implement this by moving focus to the first focusable element in the modal when it opens. When users press Tab at the last focusable element, cycle back to the first. When they press Escape or close the modal, return focus to whatever triggered it.Get this wrong and users can find themselves lost, tabbing through invisible elements or unable to interact with your modal at all.Testing your keyboard navigationAutomated tests catch some keyboard issues, but you need to test manually. Unplug your mouse. Navigate through your entire application using only the keyboard.Can you reach every interactive element? Can you see where focus is at all times? Does the tab order make sense? Can you complete core tasks without touching your mouse?If you get stuck, frustrated, or confused during this test, your users will too. Take notes on pain points and fix them.Making it part of your processKeyboard accessibility isn't something to add at the end. Build it in from the start. Use semantic HTML. Test as you develop. Make keyboard navigation a requirement in code reviews.The patterns we've covered form the foundation. Master these basics and you're well on your way to building truly accessible interfaces. Your keyboard users will notice the difference immediately.

Read more