Skip to main content
WCAGrules
Quick navigation

Services · By framework

A Vue Accessibility Audit Makes the Same Promises, the Vue Way

For the Vue or Nuxt team that wants component-level findings and framework-aware fixes, not generic advice translated badly.

What We Keep Finding

Vue's ergonomics make custom components quick to write, which means the classic gaps arrive just as quickly. Click handlers on divs. Toggled content that changes on screen and announces nothing, because showing an element has never announced anything by itself. Labels sitting next to inputs they were never wired to, which passes the rule about having a label and fails the rule about the label being connected to the field. That second pair catches people out, because on screen it looks finished.

Route changes are the one where Nuxt has a specific answer almost nobody has heard of. Nuxt ships a route announcer component, added in v3.12, that puts the page title into a hidden live region when the route changes. It is optional. You add it to your app shell or a layout yourself, and a default Nuxt app that never added it is silent. That is a one-component fix, which is a nicer answer than most frameworks offer, and it politely announces where Next.js announces assertively. Worth knowing which one your users are getting.

Transitions are the other Vue-shaped question, and the level depends on who started the motion. Motion the page starts on its own has to be pausable, and that is a Level A obligation. Motion the user triggered by clicking or navigating is a different rule at Level AAA, which most sites are not being asked to meet. Getting those two the wrong way round is expensive in both directions, so we say which one each finding is. Either way, every operating system ships a reduced-motion setting, and a Vue transition ignores it until somebody wires it up.

What We Check

  • Test custom components for roles, names, states, and a keyboard path
  • Check whether the Nuxt route announcer is present at all, then whether it says something different per route
  • Verify toggled and transitioned content actually reaches assistive technology
  • Check the label wiring on every field, not just that a label is visible next to it
  • Run forms and validation with a screen reader, errors included
  • Separate page-started motion from user-triggered motion, and test the reduced-motion setting

What You Get

Every service on this site runs the same three-pass engine: an automated scan, an expert review of all 55 WCAG 2.2 A and AA rules, and a hands-on session with a professional blind screen-reader user. You get one report with every finding screenshotted, ranked by user impact, and linked to its fix. Your team fixes, we verify: the re-audit is half price within 3 months.

The format is not a mystery either. Read the sample report before you spend anything.

The Honest Limit

One honest limit. We test the built app your users get, on first load and on client navigation both, rather than reading your components in the repo. Source-level mapping stays with your team, made quick by findings that name what they saw and where. Our automated pass never navigates at all, so route behavior, transitions and validation are all human-pass work here, which is most of what this page is about.

What It Costs

Rapid Audit: $499, up to 10 pages you pick, report in 5 business days. Standard Audit: $1,499, up to 25 pages in 10 business days. Flat rates, no discovery calls, and a real blind screen-reader user on every engagement. Pick your pages. We bring the humans.

Worth Reading Next

Related on this site

Guides, checklists, tools, and terms that go with this service.

More in By framework

Go somewhere useful

Find tools, resources and your workspace.

29 destinations