Accessibility & WCAG

Accessibility work should find barriers real users can hit and fix them in the interface.

We audit and remediate websites and web applications using WCAG as a technical reference, then verify important interactions manually. The goal is not a perfect automated score. It is a site that is easier to navigate, understand, and operate with keyboards, screen readers, zoom, and other assistive technology.

Discuss an accessibility audit See accessibility remediation work

What we test

Follow the tasks people need to complete, not just the violations a scanner can count.

Automated tools are useful for finding certain patterns quickly, but many accessibility failures only appear when someone actually navigates and operates the interface.

Can someone navigate without a mouse?

Links, menus, dialogs, carousels, forms, and controls should be reachable in a logical order with focus that is visible and never trapped unexpectedly.

Does the page structure make sense to assistive technology?

Headings, landmarks, labels, names, descriptions, tables, buttons, and links should communicate their purpose without depending only on visual placement.

Can someone complete forms and recover from errors?

Instructions, required fields, validation, error messages, success states, and dynamic updates should be understandable and announced where needed.

Does the interface remain usable when vision or motion needs differ?

Contrast, zoom, text resizing, touch targets, responsive reflow, motion, and content visibility matter when users do not interact with the page exactly as the design mockup assumes.

What we can work on

Accessibility remediation in plain language.

The most valuable fixes usually live in shared templates and components because one source-level improvement can remove the same barrier across many pages.

Audit representative pages and reusable components instead of relying on a single automated scoreTest keyboard navigation, focus order, visible focus states, menus, modals, and interactive controlsImprove semantic HTML, headings, landmarks, labels, names, descriptions, and ARIA only where it is neededFix form labels, instructions, validation, error messages, status updates, and other task-critical interactionsReview color contrast, text resizing, responsive zoom, touch targets, motion, and layout behaviorWrite meaningful alternative text where images communicate information and leave decorative images out of the reading experienceTest common screen-reader and manual interaction paths after source-level fixes are implementedDocument unresolved items, retesting evidence, regression checks, and an ongoing monitoring process

Automated vs. manual

A scanner can find some problems. It cannot prove the whole experience is accessible.

Automated tools are good at repeatable checks such as some missing names, contrast failures, invalid attributes, and structural patterns. Manual testing is still needed for focus order, control behavior, instructions, context, keyboard paths, screen-reader output, and whether a task can actually be completed.

Use automated scans to cover many pages and catch repeatable issues quicklyUse keyboard testing to verify navigation order, focus visibility, traps, and interactive behaviorUse screen-reader testing on representative journeys where names, state, and context matterRetest after remediation because a code change can fix one barrier and create anotherKeep evidence and unresolved items documented instead of treating accessibility as a one-time badge

Related work

From remediation tickets to a documented accessibility monitoring program.

See a client-anonymous accessibility case study covering source-level fixes, automated and manual retesting, dated evidence, unresolved follow-up items, and a repeatable monitoring workflow.

Read the accessibility remediation case study

Need to understand where your site is difficult to use?

Talk through an accessibility review

Delivery standards

Quality is part of the implementation.

Responsive by default

Layouts are checked across mobile, tablet, and desktop rather than treated as a desktop-only handoff.

Accessible interactions

Semantic structure, keyboard use, focus states, and readable contrast are considered during implementation.

Search-ready structure

Crawlable links, metadata, structured information, and performance are built into the page system where relevant.

Maintainable delivery

The goal is a system that can be reviewed, changed, and extended without rebuilding the whole thing each time.