Shifting Accessibility Left: How to Empower Developers, QA and Designers Together

Tanveer KhanLast Updated on November 13, 2026

11-12 Min Read TimeAdd as preferred on Google

Key Takeaways

Teams cut late accessibility rework by training designers, developers and QA together, auditing real components jointly, and writing accessibility into acceptance criteria from the first sprint.

• Late accessibility fixes are costly because designs are approved and markup is built; a missing focus state is a one-line token change in Figma but a multi-screen change after release.
• Each role owns specific checks: design owns interactive states and handoff annotations, development owns semantics and keyboard behavior, and QA owns screen reader and keyboard verification.
• A shared audit of one real component, timeboxed to 60 to 90 minutes, ends in one issue list recording the element, WCAG 2.2 criterion, finder and suggested owner.
• Triaging audit issues by root cause sends each fix to its source, such as a design token or shared component, so the same defect does not return on the next screen.
• Handoff gaps turn into defects: an undefined focus state, a clickable div instead of a button, or an informative chart given an empty alt.
• Automated checks such as axe or Lighthouse can run on every pull request, but they do not replace manual screen reader and keyboard testing before release.

Start with one shared audit on a single high-traffic component this sprint, then let the results set the next step.

Accessibility bugs found the night before a release are expensive to fix, because the design is already approved and the markup is already built. Shifting accessibility left means building accessibility checks into design reviews, code implementation and QA test planning from the first sprint. In practice, that comes down to training designers, developers and QA together, running shared audits on real components, and writing accessibility into acceptance criteria.

Why Late Accessibility Fixes Cause Rework

In many teams, accessibility is still checked too late in the development cycle, and each role adds to the problem:

• Design handoffs are finalized without accessibility details for interactive states or visual hierarchy.
• Developers build UI components without semantic structure or support for accessible user interactions.
• QA teams find accessibility issues only during final testing, when fixes are complex, time-consuming or deprioritized.

This fragmented approach leads to inconsistent user experiences, technical debt and costly rework when accessibility isn't built in from the start. A typical case is a custom dropdown that has to be rebuilt after release because nobody made it keyboard operable.

Why Shift Accessibility Left?

Shifting accessibility left means checking for accessibility during design reviews, code implementation and QA test planning from day one, so defects are fixed while they are still cheap to change. Take a missing focus state. Fixed in a Figma component, it is a one-line token change. Found after release, it means changing every screen that uses that component.

• Delivery is faster because issues caught in design or code review don't turn into last-minute release blockers.
• Collaboration improves because each role sees what the others check and why.
• Product quality rises because keyboard, screen reader and contrast problems are solved once in shared components.
• Costs drop because a fix made at the source doesn't have to be repeated screen by screen.

Does Every Product Need Accessibility From the First Sprint?

Most products used by customers, students or the public do, and the exceptions are narrower than many teams assume. An internal tool for a small team where nobody uses assistive technology can reasonably put full conformance lower on the backlog. The risk is making that assumption without checking it. Clients, contractors and new hires often start using internal systems over time, and a tool built without semantic markup then has to be retrofitted at release-stage cost.

Procurement is the other test. Many US clients and government buyers ask for accessibility documentation, such as a VPAT (Voluntary Product Accessibility Template), an accessibility audit report, or conformance documentation against WCAG 2.0 or 2.2 or the European standard EN 301 549. A team that runs shared audits every sprint already has records to draw on when that request arrives.

An Arbisoft audit of a learning platform shows how small the fixes can be when they are made at the source. None of the form fields had an associated label or aria-label, and screen reader users could not tell what to enter in fields such as "Email" or "Password." The team linked each visible label to its input with matching for and id attributes, as in <label for="email">Email</label> paired with <input id="email" type="email">. Icon-only fields got descriptive aria-labels.

Form usability improved without a major redesign, the team met WCAG 2.2 level AA checkpoints, and onboarding became smoother for NVDA and VoiceOver users. A label requirement in the design handoff annotations would have kept the gap out of the build in the first place.

Why Accessibility Pressure on Product Teams Keeps Rising

Legal and regulatory exposure has grown in both the US and the EU. UsableNet's 2025 year-end report counted 5,114 ADA digital accessibility lawsuits filed between January 1 and December 15, 2025, and 1,427 of them targeted companies that had already been sued. In the EU, the European Accessibility Act has applied since 28 June 2025 to a range of products and services, including websites and mobile applications.

The repeat-defendant figure is the one with a delivery lesson. It suggests that fixing only the pages named in one complaint leaves the same defects elsewhere in the product. A fix made in the shared component or design token reaches every screen that uses it, which is the practical case for moving the checks earlier. Which obligations apply to a specific product is a question for legal counsel.

Is Accessibility a Skill Every Designer, Developer and QA Engineer Needs?

Anyone who designs, builds or tests UI needs it. Forms, dropdowns, modals and error messages all have accessibility behavior that design has to specify and development and QA have to get right. The skill extends what each role already does: a designer specifies focus states and reading order, a developer knows when a native element works better than an ARIA role, and a QA engineer can run a full flow with a screen reader.

For an engineering leader, this argues for training the existing team over relying on one specialist. A lone specialist who reviews finished work becomes the late checkpoint that shifting left is meant to remove. The skill also gives individual engineers and designers a growth path, because people who have it can lead shared audits and write the team's accessibility acceptance criteria.

How to Educate Designers, Developers, and QA Together

1. Run Joint Training Sessions

Training works best when designers, developers and QA learn in the same room (or call) instead of in silos. Cover these topics together:

• WCAG 2.2 success criteria basics. The W3C's WCAG 2 Overview says WCAG 2.2 was published in October 2023 and updated in December 2024, while WCAG 3 is still an early draft, so WCAG 2.2 is the version to train on.
• Keyboard-only testing.
• How screen readers interact with your UI.
• Demos of tools like axe, Lighthouse, VoiceOver and TalkBack.

The sessions stick when they are hands-on: a designer runs through a screen with TalkBack (the screen reader built into Android devices), a developer checks contrast in Figma, and QA completes a full user flow using only the keyboard.

Recording these sessions gives new team members accessibility onboarding from their first day.

2. Encourage Shadowing & Pair Work

Some of the best learning happens when people see the work from another role's point of view.

• When QA shadows a developer, they see how ARIA roles, semantic elements and tabindex are applied.
• When a developer shadows QA, they learn how screen reader testing works and why keyboard traps matter.
• When a designer joins a developer, they see how a mockup becomes a component and how small design changes affect accessibility.

The payoff shows up in bug reports. QA learns why a bug occurred and can file it against the right component, and developers start catching keyboard traps before a build reaches testing.

3. Create and Share Unified Resources

Shared assets prevent duplicated effort and leave fewer gaps between roles:

• Accessibility checklists for design, dev and QA.
• Bug templates that reference specific WCAG criteria.
• Test cases mapped to accessibility acceptance criteria.
• A design handoff annotation template that records focus states, reading and tab order, heading levels, and whether each image is decorative or informative (with its alt text).

Host these in a central location (like Confluence, Notion or GitHub wiki) and keep them versioned.

A shared Slack channel or Teams space also helps, because anyone can drop in questions, tips or bugs without waiting for the next meeting.

4. Use Common Tools Across Roles

Make sure everyone has access to and training on basic accessibility tools:

Using the same tools creates consistency in what's being checked and a shared language for problem-solving.

An automated accessibility check, such as the Lighthouse accessibility audit or axe, can run on every pull request so regressions are caught before a build reaches QA. Our view is that automated checks do not replace screen reader and keyboard testing, because a tool cannot judge whether an announcement or a focus order makes sense to a person.

How to Run a Shared Accessibility Audit

A shared audit works when the team picks one real component, gives each role a defined set of checks, and finishes with one shared issue list.

1. Choose a real page or component, such as a login form or product card, and timebox the session, for example to 60 to 90 minutes.
2. Designers check color contrast, font sizes, and focus and hover states.
3. Developers check semantic structure (heading levels, ARIA roles) and keyboard interactions (Tab, Shift+Tab, Enter, Escape).
4. QA tests screen reader announcements, tab flow and logical focus order, and hidden or visually hidden elements.
5. Record each issue in one shared list with the affected element, the WCAG 2.2 success criterion, who found it and a suggested owner.

What Happens After the Audit?

After the shared audit, QA logs the issues and the three roles triage them together by root cause. QA can lead the logging, but input from developers and designers keeps each issue accurate and gives it a clear owner.

• Design-related issues, such as missing states, layout inconsistency or unclear interaction cues.
• Development-related issues, such as incorrect markup, missing roles or broken interaction handling.
• Testing or content edge cases, such as behavior that changes at runtime, ARIA misconfigurations or screen reader feedback no one checked.

Triage by root cause sends each fix to its source, for example the design token or the shared component, so the same defect does not come back on the next screen.

Three Examples of Accessibility Handoff Gaps Between Design, Dev and QA

Small misunderstandings between roles often turn into accessibility defects later. Each example below shows what QA saw, the root cause and the fix.

A Button With No Designed Focus State

QA reports "Button not accessible." The developer responds "It looks fine." The root cause is that the designer never defined a focus state, so keyboard users can't see where they are. The fix is to add focus styles to the design tokens and describe component behavior in the handoff.

A Clickable div Instead of a Native Button

A developer uses <div> instead of <button> for a clickable item, and QA flags it as keyboard-inaccessible. The root cause is that the team has no shared rule on when to use native elements. The fix is team-wide guidance on when and how to use semantic elements and ARIA roles.

An Informative Image Given an Empty Alt

The W3C's Decorative Images tutorial says decorative images should get a null (empty) alt text so assistive technologies can ignore them. In this case, a chart that carried meaning was never marked as informative in the design. The developer treated it as decorative and gave it an empty alt, and QA passed it because the empty alt looked deliberate, so screen reader users got nothing. The fix is handoff annotations that mark each image as decorative or informative and supply alt text for the informative ones.

Sprint Habits That Keep Accessibility Early

These habits keep accessibility in the workflow sprint after sprint, listed in the order most teams should adopt them:

• Make accessibility part of your acceptance criteria. A criterion such as "All interactive elements are reachable and operable with the keyboard, show a visible focus state, and have an accessible name" belongs in both the definition of ready and the definition of done.
• Review mockups for accessibility before development starts.
• Include accessibility checkpoints in every sprint.
• Assign an accessibility champion in each role to advocate and support others.
• Celebrate small wins, such as the first accessible modal or a passed audit.

Start with One Shared Audit

The most practical first step is one shared audit on a single high-traffic component this sprint, such as a sign-up form or a checkout flow. Shifting accessibility left reduces late findings, but manual screen reader and keyboard testing before release still has to happen.

The audit results should set the next step. If most issues trace back to design, start with handoff annotations and design tokens. If most trace back to markup, the priority is component semantics and an automated pull request check. For more detail on test methods, see our guide to accessibility testing.

Teams that want an outside view can ask Arbisoft for a rapid audit of up to three priority pages or user flows, or a workshop for designers, developers and QA.

Frequently Asked Questions About Shifting Accessibility Left

Can automated accessibility tools replace manual testing?

No. Tools such as axe and Lighthouse catch markup-level issues early and fit well into pull request checks. People still need to judge whether screen reader announcements make sense, whether the focus order follows the task, and whether alt text describes what an image actually conveys to the user.

Who should own accessibility on a product team?

All three roles share it. Design owns interactive states and handoff annotations, development owns semantics and keyboard behavior, and QA owns verification with screen readers and keyboard testing. An accessibility champion in each role coordinates the work, answers questions and keeps accessibility in the acceptance criteria.

Which WCAG version should our team work to?

WCAG 2.2. It was published in October 2023 and updated in December 2024, and as of October 2026 WCAG 3 is still an early draft. Training, bug templates and acceptance criteria should all reference WCAG 2.2 success criteria so every role works from the same standard.

How do we know if shifting accessibility left is working?

Track accessibility defects by the phase where they were found: design review, code review, QA or production. Also count how many reach users after release. When the practice is working, the share found in design and code review rises over a few sprints, and fewer issues turn up in final testing.