[ COMPLIANCE ] // SECTION 508 AUDIT

Section 508 conformance, written by engineers who ship the fixes.

WCAG 2.1 AA audits, VPAT 2.5 / ACR documentation, and remediation for federal agencies and contractors. We test with NVDA, JAWS, and VoiceOver — not just axe-core.

Veteran-Owned SDVOSB
[001 / 005] Field Conditions

Most 508 audits are a PDF of axe warnings and a VPAT no contracting officer believes.

// SITUATION

Teams hand a checklist to a junior dev, run Lighthouse, mark everything 'Supports' on the VPAT, and ship it to the contracting officer. Six weeks later the agency's accessibility office comes back with screen-reader recordings showing the modal traps focus, the data table is unreadable, and the error states aren't announced. Now you're remediating under a deadline, the ACR has to be revised, and the award is at risk. The original audit cost you nothing in dollars and everything in trust.

  • ▸ VPATs marked 'Supports' across the board with no remarks — an immediate red flag to any agency 508 reviewer.
  • ▸ Audits run only with automated tools, missing focus management, ARIA semantics, and dynamic content announcement issues.
  • ▸ Custom React or Angular components built from divs instead of native elements, breaking keyboard and screen-reader behavior.
  • ▸ Accessibility treated as a pre-launch checklist instead of a CI gate, so every release reintroduces regressions.
~30%
of WCAG issues automated tools actually catch
4-8 wks
typical AA remediation on a modern SPA
VPAT 2.5
current ACR format we deliver against
[002 / 005] Operational Approach

Treat accessibility as engineering, not paperwork

  1. STEP-01

    Baseline audit with real assistive tech

    We run axe-core and Lighthouse for the 30% of issues tools catch, then test the rest manually with NVDA, JAWS, VoiceOver, and keyboard-only flows. Output is a triaged backlog mapped to specific WCAG 2.1 AA success criteria, not a PDF of warnings.

  2. STEP-02

    Fix the structural failures first

    Heading order, landmark regions, focus management on route changes, and form labels account for the majority of blockers in SPAs. We fix the design system once so every downstream component inherits correct ARIA, focus traps, and live-region semantics rather than patching screen-by-screen.

  3. STEP-03

    CI gates and component-level tests

    We wire jest-axe or @axe-core/playwright into CI so accessibility regressions fail the build the same way a broken unit test does. Storybook gets the a11y addon. New components ship with keyboard and screen-reader test cases, not just visual snapshots.

  4. STEP-04

    VPAT 2.5 / ACR documentation

    We produce the Accessibility Conformance Report your contracting officer actually wants: per-criterion conformance level, remarks describing tested configurations, assistive tech versions, and known exceptions with remediation timelines. Written by the engineers who did the testing, not a template filler.

  5. STEP-05

    Train the team that inherits it

    Before handoff we run sessions with your developers and designers on semantic HTML, ARIA authoring practices, and how to test with a screen reader in under five minutes. Accessibility decays fast without internal ownership — the goal is no second audit needed.

// TYPESCRIPT PATTERN 
// playwright.config.ts — fail CI on new WCAG 2.1 AA violations
import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

const CRITICAL_ROUTES = [
  '/',
  '/login',
  '/dashboard',
  '/forms/benefits-application',
  '/search',
];

for (const route of CRITICAL_ROUTES) {
    test(`a11y: ${route} has no WCAG 2.1 AA violations`, async ({ page }) => {
    await page.goto(route);
    await page.waitForLoadState('networkidle');

    const results = await new AxeBuilder({ page })
      .withTags(['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa', 'section508'])
      .disableRules(['color-contrast-enhanced']) // AAA, out of scope
      .analyze();

    // Attach full report so CI artifact shows the failure context
    test.info().attach('axe-report.json', {
      body: JSON.stringify(results, null, 2),
      contentType: 'application/json',
    });

    expect(results.violations, JSON.stringify(results.violations, null, 2))
      .toEqual([]);
  });
}

Automated scans only catch ~30% of issues, but they catch regressions cheaply — wire them into CI so a missing label or broken contrast fails the build.

[003 / 005] Common Questions

Field FAQ.

→ What's the actual difference between Section 508 and WCAG 2.1 AA?

Section 508 is the federal procurement law. The 2018 Refresh of 508 incorporates WCAG 2.1 Level A and AA by reference for web content, software, and electronic documents. So in practice, meeting WCAG 2.1 AA gets you most of the way to 508 conformance, but 508 also adds requirements around hardware, support documentation, and interoperability with assistive technology that pure WCAG doesn't cover.

→ Can automated tools like axe or Lighthouse get us to compliance?

No. Automated tools reliably catch 25-40% of WCAG issues — missing alt text, contrast failures, missing form labels, invalid ARIA. They cannot judge whether alt text is meaningful, whether focus order is logical, whether a custom dropdown is announced correctly, or whether dynamic content updates reach a screen reader. You need manual testing with NVDA or JAWS plus keyboard-only walkthroughs to sign off honestly.

→ Why do single-page apps fail accessibility audits so often?

SPAs break two things browsers normally handle for free: focus management on navigation and announcement of page changes. When React or Vue swaps the view, focus stays on whatever was clicked and screen readers don't announce the new context. Custom components built with divs instead of native buttons skip all the built-in keyboard and ARIA behavior. Both are fixable, but require deliberate engineering — not a plugin.

→ What is a VPAT and do we actually need one?

A VPAT (Voluntary Product Accessibility Template) is the form. The completed document is called an Accessibility Conformance Report (ACR). If you're selling software to a federal agency, the contracting officer will ask for one before award, and increasingly state and education buyers do too. Current version is VPAT 2.5 Rev 508. A vague or template-padded ACR will get flagged — agencies have accessibility staff who read these.

→ How long does a Section 508 audit and remediation typically take?

For a mid-sized application — say 40-80 unique screens — initial audit runs 2-3 weeks. Remediation depends entirely on how the app was built. A modern React app with a consistent design system can often hit AA in 4-8 weeks because fixes propagate through shared components. A legacy app with hand-rolled controls on every page is closer to 3-6 months. We scope honestly after seeing the code.

→ Does VooStack's SDVOSB status matter for this work?

It matters if you're a federal agency or a prime looking to meet small-business or SDVOSB subcontracting goals. As a Service-Disabled Veteran-Owned Small Business, we're eligible for set-aside and sole-source awards under FAR 19.14, and our hours can count toward your SDVOSB subcontracting plan. For commercial clients it's irrelevant — you should hire us based on whether the work is good.

→ What are the most common patterns you see fail audits?

Custom dropdowns and comboboxes built without the ARIA Authoring Practices pattern. Modals that don't trap focus or restore it on close. Form errors announced visually but not to assistive tech. Icon-only buttons with no accessible name. Data tables built from divs. Color used as the sole indicator of state. Toast notifications that disappear before a screen reader user can read them. All of these are routine and all are fixable.

→ How do we keep accessibility from regressing after you leave?

Three things. First, axe or pa11y running in CI so violations break the build. Second, an accessible component library so developers reach for the right primitives by default — accessible Button, Modal, Combobox, DataTable. Third, a short internal runbook and a designated owner who reviews PRs touching UI. We document and train on all three during engagement so the team isn't dependent on us afterward.

→ Can you remediate accessibility on a legacy app we can't fully rewrite?

Yes, and this is most of what we see. The approach is different: instead of fixing a design system, we identify the highest-traffic flows, remediate those component by component, and document known exceptions in the ACR with remediation timelines. We've taken jQuery-era apps and ColdFusion frontends to AA without a rewrite. It's less elegant than greenfield but it's what production reality usually requires.

[004 / 005] Adjacent Files

Continue recon.

REL-01

Compliance services

Section 508, FedRAMP-adjacent work, and federal contracting engineering support.

 REL-02

Audit case studies

How we took legacy apps to WCAG 2.1 AA without full rewrites.

 REL-03

Audit packages

Fixed-scope 508 audit and ACR generation engagements with defined deliverables.

 REL-04

Request an audit

Tell us the stack and timeline; we'll scope honestly within a week.
[ NEXT ACTION ]

Need a Section 508 audit that holds up under contracting officer review?

Talk to a VooStack operator. We respond within one business day.

Open a Channel Full Services