Continuously Improving Accessibility Instead of a One-Time Project

1. Why a one-time audit is not enough

Many organizations treat accessibility like a project with a start and end date: an agency is hired, an audit report with a hundred findings comes back, the development team works through the list, and the ticket gets closed. From a management perspective, accessibility is now handled. In reality, an accessibility audit is always just a snapshot of the code at the moment of review, not a permanent property of the application. As soon as the codebase keeps evolving, its WCAG conformance status shifts too, without anyone noticing.

The effect shows up reliably in practice: six months after a successful audit, a new feature on the product detail page reintroduces missing alt text, a broken focus order, or a contrast failure in the new badge design. Without automated protection, nobody notices until a complaint comes in or the next audit is due, often one to two years later. Accessibility behaves structurally like security or performance: a property that decays systematically without ongoing maintenance, not because the team is careless, but because every code change carries a potential regression risk.

2. Establishing accessibility as a process, not a project

The decisive shift in perspective is to understand accessibility not as a project that can be closed, but as an ongoing practice, comparable to security monitoring or performance budgets. A process has no end date, only recurring activities with clear ownership. Three building blocks complement each other here: automated checks in the CI pipeline that catch structural errors on every commit, periodic manual audits that surface interaction and screen reader specific problems, and a feedback channel that makes real-world usage problems visible that no test could have anticipated.

These three building blocks cover different classes of defects and do not replace one another. Automated tools like axe-core reliably detect missing labels, invalid ARIA attributes, and contrast violations, but are blind to poor reading order or confusing screen reader announcements. Manual audits with real assistive technology cover exactly that gap, but are too costly to run on every commit. The feedback channel finally catches edge cases that neither automation nor sample audits cover, such as specific combinations of operating system, screen reader, and browser that never come together in a test lab.

3. Automated checks in the CI pipeline

Automated accessibility tests belong in the same CI pipeline as unit and integration tests, not in a separate, rarely run audit script. Libraries like axe-core can be wired directly into Playwright or Cypress tests and check generated HTML against WCAG 2.2 rules automatically. The decisive advantage over a manual audit: a violation is caught before it is merged into the main branch, not months later at the next external review. For Hyva stores, it makes sense to include the most important templates, such as product detail page, category page, cart, and checkout, in automated testing, since that is where most user interactions happen.

It is important to make the build actually fail on critical violations, not just leave a warning in a log nobody reads. At the same time, the team needs to know that automated tools, by common estimates, can only reliably check about 30 to 50 percent of all WCAG success criteria. Contrast, missing labels, and structural ARIA errors are automatable, while reading order, sensible focus order in complex interactions, and the quality of screen reader announcements remain a job for manual review. CI checks are therefore a necessary safety net against regressions, not a substitute for human review.

// tests/a11y/pdp.spec.ts
// Fails the CI build when axe-core finds critical or serious violations
import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test.describe('Accessibility: product detail page', () => {
  test('has no critical or serious WCAG 2.2 violations', async ({ page }) => {
    await page.goto('/catalog/product/view/id/42');
    await page.waitForSelector('[data-test="product-add-to-cart"]');

    const results = await new AxeBuilder({ page })
      .withTags(['wcag2a', 'wcag2aa', 'wcag22aa'])
      .analyze();

    const blocking = results.violations.filter(
      (violation) => violation.impact === 'critical' || violation.impact === 'serious'
    );

    // Print full detail for debugging, but only fail on blocking severity
    if (blocking.length > 0) {
      console.log(JSON.stringify(blocking, null, 2));
    }

    expect(blocking, 'blocking accessibility violations found').toHaveLength(0);
  });
});

4. Periodic manual audits: screen reader, keyboard, contrast

Manual audits remain indispensable because they surface problems no automated test can detect: a screen reader announcement that is technically correct but confusing in practice, a keyboard trap in an Alpine.js dropdown, or a focus indicator that meets the contrast ratio but is barely perceptible during fast tabbing. A full audit with NVDA, VoiceOver, and keyboard-only navigation across the entire store is costly and therefore not worth doing on every release, but it is worth doing on a fixed cadence, such as quarterly or after major redesigns.

More efficient than a full audit every cycle is a diff-based approach: instead of re-checking the entire store, the audit specifically determines which templates and components have changed since the last review, and only those get manually retested. That cuts the review effort significantly without risking blind spots on new features. A rolling sample helps as well: each month a different area of the store gets a full screen reader test, so that over the course of a year the entire store has been thoroughly checked at least once, without overloading any single sprint.

// scripts/audit-scope.js
// Lists templates changed since the last recorded manual audit,
// so reviewers can focus manual testing on real risk instead of the whole shop
import { execSync } from 'node:child_process';
import fs from 'node:fs';

const lastAudit = JSON.parse(fs.readFileSync('accessibility-debt.json', 'utf8')).lastManualAudit;
const changedFiles = execSync(`git diff --name-only ${lastAudit.commit}..HEAD`)
  .toString()
  .split('\n')
  .filter((file) => file.includes('/templates/') && file.endsWith('.phtml'));

console.log(`Templates changed since last manual audit (${lastAudit.date}):`);
changedFiles.forEach((file) => console.log(` - ${file}`));
console.log(`\nTotal: ${changedFiles.length} template(s) require targeted re-audit.`);

5. A feedback channel for assistive technology users

No audit team and no automated test suite can anticipate every real-world usage situation. A direct feedback channel for accessibility problems closes exactly that gap, provided it is itself accessible and actually monitored. In practice that means a clearly labeled link in the footer, reachable by keyboard and with a correct ARIA label, leading to a simple form or a dedicated email address, not a generic contact form where accessibility reports get lost among return requests.

For the channel to work, it needs a clear process owner and a defined response time, similar to security disclosures. A report about an unusable checkout step should be acknowledged and prioritized within a few business days, not left to sit in a general support inbox. It is also important to feed incoming reports into the accessibility backlog in a structured way, noting the affected WCAG criterion, the assistive technology used, and the severity, so the report does not stay isolated but flows into the same tracking process as issues found through automation and manual review.

<!-- Hyva phtml: accessible footer link for accessibility feedback -->
<div class="border-t border-gray-200 pt-4 mt-4">
  <a
    href="mailto:accessibility@mironsoft.de"
    class="inline-flex items-center gap-2 text-sm text-gray-700 underline hover:text-gray-900 focus-visible:outline focus-visible:outline-2 focus-visible:outline-offset-2"
    aria-label="Report an accessibility issue by email"
  >
    <svg class="w-4 h-4" aria-hidden="true" fill="none" stroke="currentColor" viewBox="0 0 24 24">
      <path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M3 8l7.89 5.26a2 2 0 002.22 0L21 8M5 19h14a2 2 0 002-2V7a2 2 0 00-2-2H5a2 2 0 00-2 2v10a2 2 0 002 2z"/>
    </svg>
    Found a barrier? Report it now
  </a>
</div>

6. Tracking accessibility debt like technical debt

The most effective lever against one-time project thinking is to treat accessibility findings exactly like technical debt: as a living, prioritized backlog, not as a closed audit ticket. Every finding, whether from CI, a manual audit, or the feedback channel, gets an entry with the affected WCAG criterion, severity, affected component, and discovery date. This backlog is regularly prioritized, much like a security backlog, and is not only revisited when the next external audit comes due.

In practice, this backlog can either live in the existing ticket system as its own label, or, for better automatability, as a structured file in the repository that CI scripts can read and update. The advantage of a versioned file: it can be evaluated in reports, visualized in dashboards, and linked to the timestamp of the last manual audit, as already shown in the diff-based audit approach from section four. It is important that an entry only gets closed once an automated or manual test actually confirms the fix, not when the responsible developer simply considers the change done.

{
  "lastManualAudit": {
    "date": "2026-04-15",
    "commit": "a3f9c21",
    "auditor": "external-agency"
  },
  "debtItems": [
    {
      "id": "A11Y-0142",
      "wcagCriterion": "1.4.3 Contrast (Minimum)",
      "severity": "serious",
      "component": "catalog/product/card",
      "source": "ci-axe-core",
      "discovered": "2026-06-02",
      "status": "open",
      "description": "Badge text on sale price uses #ffffff on #f59e0b, ratio 2.1:1"
    },
    {
      "id": "A11Y-0143",
      "wcagCriterion": "2.4.3 Focus Order",
      "severity": "moderate",
      "component": "checkout/shipping-step",
      "source": "manual-audit",
      "discovered": "2026-04-15",
      "status": "in-progress",
      "description": "Tab order jumps from address field to promo code, skipping shipping method"
    }
  ]
}

7. Embedding responsibility and ownership in the team

Processes without ownership decay, because responsibility that is not concretely assigned to anyone belongs to no one in practice. A proven pattern is the role of an accessibility champion per team or squad: not a full-time position, but a named person who triages CI failures first, prioritizes the debt backlog, and serves as the point of contact for questions. This role should rotate, or at least be reviewed regularly, so that knowledge does not get stuck with a single person and get lost when that person leaves the team.

In addition, accessibility criteria belong in the definition of done and in the pull request template, as concrete checkboxes rather than vague expectations. A PR template with items like keyboard operability checked, contrast ratios checked, axe-core check green makes visible what otherwise stays implicit, and prevents accessibility from being treated as optional under time pressure. Code reviews should include at least one reviewer question about accessibility, such as whether interactive elements are reachable by keyboard, so the check becomes part of the normal review flow instead of remaining a separate activity that is often skipped.

8. Regression protection through component tests and design system guards

The most effective regression protection does not operate at the page level but at the component level, because that is where reuse is greatest. An ARIA pattern implemented correctly once in the base dropdown component of the Hyva theme automatically protects every place in the store that uses that component, as long as nobody overrides it locally. Component tests that specifically check focus behavior, ARIA attributes, and keyboard interaction of a single Alpine.js component run noticeably faster than store-wide end-to-end tests and can run on every commit, not just in the nightly build.

Design system guards go a step further: contrast ratios, focus styles, and minimum tap target sizes get defined centrally as design tokens, so a developer cannot easily fall short of them without deliberately overriding the token. A global :focus-visible rule with sufficient contrast, a central skip link, and respected prefers-reduced-motion are examples of protection mechanisms that operate at the CSS level, before any test even needs to run. This combination of component tests and CSS guards prevents most regressions structurally, instead of discovering them later through an audit.

/* tailwind.source.css: design-token-level accessibility guards */
@layer base {
  :focus-visible {
    outline: 2px solid #18181b;
    outline-offset: 2px;
  }

  .skip-link {
    position: absolute;
    left: -9999px;
    top: 0;
    z-index: 100;
    background: #18181b;
    color: #ffffff;
    padding: 0.75rem 1.5rem;
    border-radius: 0 0 0.5rem 0;
  }

  .skip-link:focus {
    left: 0;
  }

  @media (prefers-reduced-motion: reduce) {
    *, *::before, *::after {
      animation-duration: 0.01ms !important;
      animation-iteration-count: 1 !important;
      transition-duration: 0.01ms !important;
      scroll-behavior: auto !important;
    }
  }
}

9. One-time audit vs. continuous process compared

The differences between a one-time audit project and a continuous process show up most clearly when both are compared along the same dimensions: when a problem is detected, who is responsible, and what happens after the first fix.

No single building block of the continuous process fully replaces the others. Only the interplay of automated checks, periodic manual audits, a working feedback channel, and a maintained debt backlog turns a point-in-time audit result into genuinely stable, lasting WCAG conformance that still holds up ten deployments after the last audit.

10. Summary

A one-time accessibility audit describes the state of an application on a single day, not its lasting conformance. Automated CI checks with axe-core catch structural regressions on every commit, periodic manual audits with screen reader and keyboard uncover problems no tool can detect, and a reachable feedback channel closes the remaining gap to real usage situations. Together, these three building blocks replace the one-time project with an ongoing process.

The second decisive building block is organizational: findings belong in a living debt backlog with severity and WCAG criterion, not in a checked-off audit list. A named accessibility champion per team, criteria in the definition of done, and component tests at the design system level ensure that accessibility becomes part of everyday development, instead of remaining a recurring external special assignment.

11. FAQ: Continuously improving accessibility