Make accessibility an operational capability (not an afterthought): a buyer’s guide
Accessibility isn’t a “nice-to-have” layer you add at the end. For modern websites and mobile apps, it’s an operational capability: something you define, test, and maintain-release after release.
When accessibility goes wrong, it’s rarely because a team didn’t care. The most common failure mode is drift: you launch with decent accessibility, then a stream of small design tweaks, new components, and content updates quietly breaks keyboard navigation, labels, contrast, or screen-reader flows.
This guide is written for buyers and product owners who want a clear way to request, verify, and sustain accessibility-without needing to become an expert in every technical detail.
1) Define measurable acceptance criteria (so “done” is unambiguous)
Start by setting the target standard. For many organizations that means WCAG 2.2 AA (or the specific level your industry/regulators require). Then translate that into checks a team can validate during QA.
Examples of buyer-friendly acceptance criteria:
- Keyboard support: Every interactive element is reachable via keyboard, focus is always visible, and there are no keyboard traps.
- Forms: Inputs have programmatic labels, required fields are clear, and errors are announced in a way assistive technologies can understand.
- Contrast: Text and essential UI controls meet minimum contrast ratios, including hover/focus/disabled states.
- Images: Meaningful images have helpful alt text; decorative images are ignored by screen readers.
- Dynamic UI: Modals, toasts, and live updates announce changes appropriately (and don’t disorient users).
Tip: ask your vendor to provide a one-page checklist per page template (e.g., marketing pages, product pages, checkout, dashboards) so you can sign off consistently.
2) Ask for evidence, not promises
Accessibility commitments sound great in proposals, but you need proof. Require a short evidence pack as part of delivery:
- An audit report listing findings, severity, and the remediation performed.
- An assistive-tech (AT) test matrix: which browsers + screen readers were tested (for example, VoiceOver/Safari on macOS and NVDA/Chrome on Windows).
- Critical journey validation: notes or short recordings showing successful completion of key flows (sign-up, purchase, booking, core tasks).
For mobile apps, also ask how accessibility was checked on iOS and Android (VoiceOver and TalkBack), especially for custom components.
3) Put automated accessibility checks into CI (to prevent regressions)
Automation won’t catch everything (especially usability nuance), but it is excellent at preventing common breakage from slipping into production.
Request that accessibility checks become part of the build pipeline:
- Linting for basic semantic and ARIA issues.
- Automated UI tests (often axe-based) on critical pages and common UI states.
- Build gates that fail the build if “critical” accessibility issues are introduced.
This turns accessibility from an occasional audit into a continuous practice.
4) Make accessibility deliverables explicit in contracts and SOWs
If it’s not written down, it’s hard to enforce. Your statement of work should include accessibility deliverables as first-class outputs, such as:
- Accessibility acceptance criteria per template or feature.
- Remediation included for issues discovered during QA and UAT (with a clear process and timelines).
- Documentation for designers and developers: component do/don’t rules, content guidance (alt text patterns, heading structure), and design tokens for contrast.
- Post-launch re-audit time allocation (for example, at 60–90 days, or quarterly for fast-moving products).
A small contractual detail that helps: define how accessibility issues are triaged (blocker/major/minor) and what “acceptable” means before go-live.
5) Add lightweight governance so accessibility doesn’t drift after launch
You don’t need bureaucracy-you need ownership and a repeatable routine:
- Name an accessibility owner on the product side and a technical owner on the delivery side.
- Include accessibility in your definition of done (design review, QA, and release checks).
- Run a quarterly review of your highest-traffic flows and any new components introduced since the last release.
Good accessibility is rarely a single “project.” It’s the result of consistent decisions and repeatable checks.
At Jensen Technologies, we’ve been building and maintaining websites and mobile apps for years, and we’ve seen the difference between “we’ll try to be accessible” and “accessibility is part of how we ship.” The second approach reduces risk, improves usability for everyone, and often increases conversion and retention.
If you’d like to discuss accessibility requirements for an upcoming build, review a vendor’s proposal, or set up practical testing and governance for an existing product, get in touch-we’re happy to help you make accessibility a reliable capability in your business.