Accessible web and mobile applications, audited against WCAG and fixed in the code.

People use your applications with screen readers, magnifiers, voice control, captions and the keyboard alone. We audit web, mobile and SharePoint experiences against the Web Content Accessibility Guidelines (WCAG), fix what we find in the code and content, and build the checks into your releases so new barriers do not creep back in.

Book a strategy call

What we cover

Why it mattersAccessibility is part of quality, and often part of the contract
AuditsAn audit that combines tools with people
RemediationFixing the code, not just reporting it
Keeping it accessibleBuilding the checks into every release

Why it matters

Accessibility is part of quality, and often part of the contract

Many of the people who use your website, portal or app have a disability that affects how they see, hear, move or process information, and almost everyone meets a temporary or situational limit at some point: a broken wrist, a bright screen outdoors, a noisy room. An application that works well with assistive technology works better for all of them.

Accessibility is also increasingly a requirement. Federal agencies and their suppliers work under Section 508, which points to WCAG. The Department of Justice's 2024 ADA rule for state and local governments adopts WCAG 2.1 Level AA for their websites and mobile apps, and many private-sector buyers now ask for an accessibility conformance report before they sign. WCAG 2.2, the current version, adds criteria for keyboard focus, the size of touch targets and accessible sign-in.

Audits

An audit that combines tools with people

Automated scanners are a good start and catch a meaningful share of issues, such as missing text alternatives, low color contrast and unlabeled form fields. Many barriers can only be found by a person: whether the reading order makes sense, whether a screen reader announces a custom control correctly, whether a task can be completed with the keyboard alone.

Our audits combine both. We agree the scope with you, usually the most-used pages and the key tasks such as signing in, searching, applying or paying. Then we test with automated tools, keyboard-only navigation, screen readers such as NVDA, VoiceOver and TalkBack, and zoom and text resizing, on desktop and mobile. Each finding names the WCAG success criterion it fails, shows where it occurs, explains who it affects and suggests a fix, and the findings are ranked by their impact on real tasks.

What we do

A scope built around your key user tasks
Automated scans plus manual testing
Screen reader, keyboard and zoom testing on desktop and mobile
Findings mapped to WCAG success criteria and ranked by impact

Remediation

Fixing the code, not just reporting it

An audit report is only useful if someone fixes what it finds. Because we build web, mobile and hybrid applications ourselves, our developers can do the remediation: semantic HTML, and correct ARIA where custom components need it; focus management in dialogs and single-page apps; accessible names for buttons, links and form fields; captions and transcripts for media; and color and contrast changes agreed with your designers.

We retest each fix against the criterion it addresses and record the result, so the final report shows what was found, what was fixed and what remains open, with a reason for anything deferred.

What we do

Fixes in your code base, through your normal code review
Accessible components for your design system
A retest of every fix
A record of what was found, fixed and still open

Keeping it accessible

Building the checks into every release

Accessibility drifts as new features ship. To keep it, we add automated accessibility checks to your build pipeline so common problems stop a release, add accessibility to the definition of done for new work, and train designers, developers and content editors on the patterns that matter for their role. For teams on SharePoint and Microsoft 365, that includes writing accessible pages and documents with the checking tools Microsoft already builds in.

What we do

Automated checks in the CI/CD pipeline
Accessibility in design reviews and acceptance criteria
Role-based training for designers, developers and editors
Periodic re-audits of key journeys

Questions

Common questions

Which version of WCAG do you test against?

Usually WCAG 2.1 or 2.2 at Level AA, which is what most laws, contracts and procurement teams refer to. We confirm the target with you at the start, because a federal, state or commercial requirement may name a specific version.

Can you certify that our site is compliant?

No one can honestly promise that a site is accessible to every user, and conformance with WCAG is judged page by page. What we provide is a documented audit against named success criteria, fixes for what we find, retesting, and a record you can show to customers, regulators or procurement teams. Legal questions about the ADA belong with your counsel.

Will an accessibility overlay fix our site?

Overlays, the widgets that claim to make a site accessible with one line of code, do not fix the underlying markup, and many disability advocates and accessibility specialists advise against relying on them. Lasting accessibility comes from fixing the code and the content.

Can you help with a VPAT or accessibility conformance report?

Yes. After an audit we can help you complete an accessibility conformance report on the VPAT template, describing how each part of the product supports each WCAG criterion, based on the testing we did.

Do you only audit applications you built?

No. We audit and fix applications built by anyone, including your own team or another vendor, and when we build a new application for you, accessibility is part of the work from the first design.

From the blog