All articles
Delivery14 min read

Accessibility QA Playbook for Content and Compliance Teams

A QA playbook for content teams to validate document structure, readability, and assistive technology compatibility before publishing. Covers QA scope definition, pre-publish checklists, automated and manual testing, regression monitoring, and team training.

Published February 13, 20266 sections

Define QA scope by severity

Not all accessibility issues carry the same weight. A missing page language declaration is a technical failure that affects automated testing scores but rarely causes a real user barrier. A broken heading hierarchy that destroys reading order and navigation for screen reader users is a critical failure that prevents document comprehension. Your QA process must distinguish between severity levels to allocate review effort where it matters most.

Define three severity tiers for QA findings. Critical: the issue prevents users from accessing, navigating, or understanding content. Screen reader reading order failures, missing alt text on informational images, and empty heading or link elements fall into this category. Critical issues block publication until resolved.

Major: the issue degrades the user experience but does not prevent access. Examples include inconsistent heading levels that complicate navigation, table structures missing scope attributes, and missing landmark regions. Major issues should be resolved before publication when feasible and tracked for resolution within a defined timeframe when not.

Minor: the issue affects conformance scoring or best practice alignment but has minimal user impact. Examples include redundant ARIA attributes, non-optimal but functional heading levels, and presentation-only spacing issues. Minor issues are logged for future improvement but do not block publication.

Apply severity consistently across all reviewers. Write a severity classification guide with examples for each level and review it during QA team onboarding. Inconsistent severity classification creates unpredictable publication decisions and undermines reviewer credibility.

Automated testing: what it catches and what it misses

Automated accessibility testing tools can evaluate a substantial portion of WCAG success criteria without human judgment. They reliably detect missing alt attributes, empty headings, duplicate IDs, missing language declarations, invalid ARIA references, broken link targets, and malformed table structures. For these checks, automated testing is faster, more consistent, and more thorough than manual review.

However, automated tools cannot evaluate whether alt text accurately describes the image content, whether heading text meaningfully represents the section it introduces, whether reading order matches the intended content flow, or whether the document structure conveys the same meaning visually and programmatically. These semantic checks require human judgment.

Use automated testing as the first quality gate in your QA pipeline. Run automated checks on every document immediately after conversion and again after any editing changes. Automated gate failure should block advancement to manual review, since fixing structural issues caught by automation before human review saves reviewer time and improves the quality of the manual review itself.

Select automated testing tools that map results to specific WCAG success criteria and severity levels. Generic pass/fail results without criterion mapping are difficult to prioritize and track. Tools that produce criterion-level results integrate better with defect tracking, trend analysis, and conformance reporting.

Manual testing: the checks that require human judgment

Manual accessibility testing focuses on the semantic and experiential aspects that automated tools cannot evaluate. The core manual checks for document accessibility are: reading order verification, heading accuracy, alt text quality, table relationship accuracy, and overall content comprehension through assistive technology.

Reading order verification requires navigating the document using only a screen reader and confirming that content is presented in a logical sequence that matches the intended reading flow. Pay particular attention to multi-column layouts, sidebar content, figures with captions, and header/footer elements that may be read out of context.

Alt text quality review verifies that each image description serves its functional purpose. Decorative images should have empty alt text. Informational images should have descriptions that convey the same information the image provides visually. Complex images like charts or diagrams may need extended descriptions in addition to brief alt text.

Table relationship testing confirms that data cells are correctly associated with their header cells through scope attributes or header/id associations. Navigate tables cell by cell with a screen reader to verify that each cell announces its row and column context correctly. Table structure errors are among the most common and most user-impacting accessibility defects in document content.

Perform manual testing on at least one assistive technology combination for every document. NVDA with Firefox and VoiceOver with Safari are the two most representative combinations for broad coverage. For critical public-facing documents, test with both.

Pre-publish checklist

Before any document is published or delivered, run through a standardized pre-publish checklist that covers both automated and manual verification results. This checklist is the final quality gate and should be completed by a reviewer who did not perform the conversion work, providing an independent quality perspective.

The pre-publish checklist should verify: all automated accessibility checks pass with zero critical issues, manual reading order verification completed, heading structure is hierarchical and accurate, all images have appropriate alt text, all tables have correct header associations, all links are functional and descriptive, language declaration is present, and no empty or whitespace-only elements exist.

For documents that include interactive elements (forms, expandable sections, embedded media), additional checks apply: keyboard accessibility for all interactive controls, visible focus indicators, form label associations, error messaging for required fields, and media alternatives (captions, transcripts) for audio and video content.

Document the pre-publish review decision (approved, revision required, or rejected) with the reviewer name, date, and any noted issues. This creates the audit trail that governance and compliance reviews require.

Post-publish monitoring and regression detection

Publication is not the end of the QA lifecycle. Post-publish monitoring detects regressions introduced by content edits, platform updates, and environmental changes that affect document accessibility. Without monitoring, quality degrades silently until a user complaint or audit finding reveals the problem.

Set up automated monitoring for published documents that checks key accessibility indicators on a regular schedule (weekly for high-traffic documents, monthly for lower-priority content). Monitor for: heading structure changes, alt text removal, new empty elements, link breakage, and accessibility score changes.

Track support ticket inflow and issue patterns after each major document update. A spike in support tickets after an update is a strong signal that the update introduced accessibility regressions. Investigate and resolve regression sources before the next publication cycle.

Use regression data to improve upstream processes. If a specific type of edit consistently introduces regressions (table modifications, image replacements, structural reorganization), add targeted validation for that edit type to the editing workflow. Preventing regressions at the editing stage is far more efficient than detecting and fixing them post-publication.

Build QA competency across the team

Accessibility QA is a skill that improves with practice and deteriorates without reinforcement. Invest in ongoing training for everyone involved in the document lifecycle, not just designated QA reviewers. Content authors who understand accessibility principles create better source documents. Editors who understand structural requirements make fewer destructive edits. Support staff who understand common issues provide better user assistance.

Conduct quarterly QA calibration sessions where reviewers independently evaluate the same document and compare findings. Calibration reveals inconsistencies in severity classification, missed issue types, and interpretation differences that training alone does not surface.

Maintain a living QA knowledge base with examples of common issues, correct and incorrect implementations, and decision guides for ambiguous cases. Reference this knowledge base during onboarding, calibration sessions, and when resolving reviewer disagreements.

Track QA performance metrics per reviewer: defect detection rate (issues found vs. issues that escaped to post-publish), false positive rate (issues flagged that were not actual defects), and review throughput. These metrics identify training needs and ensure consistent quality across the review team.


Frequently asked questions

Is automated testing enough for QA?

No. Automated testing catches approximately 30 to 40% of WCAG issues, primarily structural and syntactic checks. The remaining 60 to 70% require human judgment: alt text quality, reading order accuracy, heading semantics, table relationship correctness, and overall content comprehension through assistive technology. Both automated and manual testing are required for thorough QA.

Who should sign off before publication?

At minimum, a content owner (responsible for accuracy) and an accessibility reviewer (responsible for conformance) should both approve before publication. For high-impact public-facing documents, add a third sign-off from a compliance or legal reviewer. The sign-off chain should be defined per document class based on risk and audience.

How often should we run regression monitoring?

Weekly automated monitoring for high-traffic, public-facing documents. Monthly for lower-priority internal content. Additionally, run targeted monitoring after every content update to detect regressions introduced by edits. The monitoring frequency should match the document's update frequency and audience impact.

What should we do when QA finds issues that are not fixable before the publication deadline?

Document the known issues, assess their severity, and make a risk-based publication decision. Critical issues that prevent user access should block publication regardless of deadline. Major and minor issues can be published with a documented remediation plan and timeline. Record the decision, the rationale, and the responsible owner for post-publication remediation.

How do we handle QA for documents authored by external parties?

Apply the same QA standards regardless of authorship origin. External content entering your publication pipeline should pass through the same quality gates as internally authored content. If external content consistently fails QA, provide authoring guidance to external contributors and consider requiring accessibility-ready source documents as a submission condition.


Sources and references

  1. ADA.gov Web Guidance
  2. Section508.gov Laws and Policies
  3. W3C WCAG 2.2 Recommendation
  4. W3C WAI Easy Checks
  5. Deque Axe Accessibility Testing

Need help applying this to your workflow?

Start a conversion request or contact our team for an implementation plan mapped to your document profile.

Continue reading