Why accessibility and security testing belong in the same pipeline

Most organizations run accessibility testing and security testing as separate workstreams. Different teams, different tools, different schedules. The result: compliance gaps that neither team catches on its own.

The numbers paint a clear picture. WebAIM's 2024 analysis of one million home pages found that 96.3% had detectable WCAG 2.0 failures (source: WebAIM Million, February 2024). Separately, Synopsys found that 84% of codebases contained at least one known open-source vulnerability (source: Synopsys OSSRA Report, 2024). These are not unrelated problems. Accessibility and security share overlapping attack surfaces: forms, authentication flows, session management, and third-party content.

This article explains where the two disciplines intersect, why organizations that test them together close compliance gaps faster, and how to structure a combined pipeline using Auditi for accessibility and the BetterQA AI Security Toolkit for security.

Transparency note: Auditi and the AI Security Toolkit are built by BetterQA, a software testing company. We include both because they address the combined compliance problem directly.

The compliance overlap: accessibility and security are both legal requirements

Organizations often treat accessibility as a UX concern and security as an IT concern. But both carry legal liability.

Accessibility litigation is accelerating. UsableNet tracked 4,605 ADA digital accessibility lawsuits filed in the US during 2023, up from 2,387 in 2018 (source: UsableNet 2023 Year-End Report). The European Accessibility Act (EAA) takes effect June 28, 2025, extending WCAG 2.1 AA requirements to private sector products and services across the EU.

Security breaches are expensive. IBM's 2023 Cost of a Data Breach Report found the global average breach cost reached $4.45 million, up 15% over three years (source: IBM Security, 2023). Regulations like GDPR, PCI DSS 4.0, and SOC 2 Type II mandate specific security controls.

Both can trigger fines simultaneously. A healthcare portal with broken form labels fails WCAG 1.3.1 (Info and Relationships). If that same form also lacks input sanitization, it fails OWASP A03:2021 (Injection). One poorly built form, two compliance violations, two potential enforcement actions.

Six areas where accessibility and security testing overlap

1. Form validation and input handling

Accessibility requires that error messages be programmatically associated with form fields and clearly described (WCAG 3.3.1, 3.3.3). Security requires that all user inputs be validated and sanitized to prevent injection attacks (OWASP A03:2021).

The overlap: a form that displays vague error messages fails both. "Invalid input" tells screen reader users nothing useful and tells attackers that their payload was processed rather than rejected at the boundary.

2. Authentication flows

WCAG 3.3.8 (Accessible Authentication, AA in WCAG 2.2) requires that login flows do not depend on cognitive function tests. Security standards require multi-factor authentication, rate limiting, and credential protection.

The conflict point: MFA implementations that use image-based CAPTCHA or drag-and-drop interactions exclude screen reader users and keyboard-only users. A combined testing approach catches authentication flows that are secure but inaccessible, or accessible but insecure.

3. Content Security Policy headers

Content Security Policy (CSP) headers are a security best practice for mitigating cross-site scripting (XSS). But overly restrictive CSP configurations can block assistive technology browser extensions that inject CSS or JavaScript to modify page presentation.

A security-only team may set `script-src 'self'` without testing whether screen reader extensions still function. A combined approach tests both the security posture and the assistive technology compatibility of CSP configurations.

4. ARIA attributes and XSS vectors

ARIA attributes like `aria-label`, `aria-describedby`, and `aria-live` improve accessibility by providing context to screen readers. But dynamically injected ARIA values that include unsanitized user input create XSS vectors.

Consider: `aria-label="${userInput}"` where `userInput` contains `">`. The ARIA attribute becomes an injection point. Security testing catches the injection; accessibility testing verifies the ARIA attributes work correctly. Neither alone catches the full picture.

5. CAPTCHAs and bot protection

CAPTCHAs exist to block automated attacks. They also block assistive technology users. Image-based CAPTCHAs fail WCAG 1.1.1 (Non-text Content). Audio CAPTCHAs are often indecipherable. reCAPTCHA v3 scores behavior invisibly but may flag assistive technology interaction patterns as bot-like.

Organizations need bot protection that does not exclude users with disabilities. This requires security and accessibility teams evaluating CAPTCHA implementations together.

6. Session timeout management

WCAG 2.2.1 (Timing Adjustable) requires that users can extend, adjust, or disable time limits. Security standards recommend short session timeouts (NIST SP 800-63B suggests 30-minute idle timeouts for sensitive applications).

A siloed security team sets aggressive timeouts. A siloed accessibility team requests infinite sessions. The combined approach: configurable timeouts with accessible warning dialogs and session extension mechanisms that maintain the security posture.

Siloed testing vs combined testing: what the numbers show

| Metric | Siloed approach | Combined approach | Source | |--------|----------------|-------------------|--------| | Average defects found | 47 per release | 63 per release (+34%) | BetterQA internal data, 2025 | | Compliance audit pass rate | 71% first attempt | 89% first attempt | BetterQA client outcomes, 2024-2025 | | Average cost per critical bug (production) | $14,102 | $3,908 (caught pre-release) | NIST Planning Report 02-3 (adjusted for 2024) | | Time to full compliance | 14-18 weeks | 8-11 weeks | BetterQA project data, 2025 | | Overlapping defects missed by one team | 23% go undetected | Less than 5% undetected | BetterQA cross-audit analysis, 2025 |

The biggest gains come from catching overlapping defects. When accessibility and security teams operate independently, issues that span both domains (like the form validation example above) fall through the cracks. A combined pipeline assigns those issues once instead of not at all.

Building a combined accessibility and security pipeline

Here is a five-stage pipeline that integrates both disciplines from commit to production.

Stage 1: Pre-commit - SAST security scan

Run static analysis on changed files before they enter the shared codebase. The BetterQA AI Security Toolkit orchestrates 30+ open-source security tools including Semgrep, Trivy, and secrets detection through its MCP interface. Three tools handle the workflow: `scan` to start analysis, `scan_status` to check progress, and `scan_results` to retrieve findings in SARIF format.

What it catches at this stage: Hardcoded secrets, dependency vulnerabilities (SCA), injection-prone code patterns, insecure authentication implementations.

Stage 2: CI build - accessibility linting

Add axe-core to unit tests and component tests. Auditi can import results from axe, WAVE, Lighthouse, and pa11y, centralizing automated findings from build-time scans.

What it catches at this stage: Missing alt text, broken ARIA associations, color contrast failures, form label issues.

Stage 3: Staging - full DAST scan and journey testing

Deploy to staging and run both a DAST security scan (the AI Security Toolkit's V4 architecture runs a seven-phase scan covering SAST, SCA, DAST, secrets detection, and LLM prompt injection testing with 95%+ code coverage) and Auditi's journey-based accessibility testing across complete user flows.

What it catches at this stage: Runtime injection vulnerabilities, authentication bypass, session management issues, multi-step accessibility failures that static analysis cannot detect.

Stage 4: Pre-release - documentation generation

Generate compliance documentation from both toolchains. Auditi produces VPAT (Voluntary Product Accessibility Template) reports from accumulated test data. Security scan results feed into SOC 2 evidence packages.

What it produces: VPAT for procurement requirements, security findings report, combined compliance summary for legal review.

Stage 5: Production - ongoing monitoring

Monitor both security vulnerabilities and accessibility regressions across releases. Auditi's version tracking compares accessibility results between deployments. Scheduled security scans catch newly disclosed CVEs affecting production dependencies.

How Auditi and the AI Security Toolkit work together

| Capability | Auditi | AI Security Toolkit | |------------|--------|---------------------| | Primary focus | WCAG 2.1, 2.2, 3.0 compliance | SAST, SCA, DAST, secrets, LLM security | | Standards covered | ADA, EAA, Section 508, FDA 21 CFR Part 11, EU Annex 11, EU AI Act | OWASP Top 10, CWE, CVE databases, PCI DSS | | Testing approach | Journey-based manual + automated | AI-orchestrated multi-tool scanning | | Users | QA teams, compliance officers | Developers, security engineers | | Output | VPAT, audit reports, trend data | SARIF findings, remediation guidance | | CI/CD integration | REST API for importing tool results | MCP server (3 tools: scan, scan_status, scan_results) | | Version tracking | Compares accessibility across releases | Tracks vulnerability remediation over time | | Tool imports | axe, WAVE, Lighthouse, pa11y | Semgrep, Nuclei, sqlmap, Trivy, and 25+ more | | Cost model | SaaS subscription | Free (open-source tools + Claude API key) |

Both tools are built by BetterQA. Using them together eliminates the gap between accessibility and security testing without introducing a third integration layer.

Real-world example: healthcare patient portal

A BetterQA client in 2024 launched a patient portal subject to HIPAA (security), ADA Title III (accessibility), and FDA 21 CFR Part 11 (electronic records). Here is what combined testing found that siloed testing would have missed:

Frequently asked questions

Does WCAG compliance affect security posture?

Directly, no. WCAG addresses user experience for people with disabilities. Indirectly, yes. Well-structured HTML with proper ARIA attributes, validated form inputs, and semantic markup reduces attack surface by eliminating the ambiguous, loosely-typed code that both screen readers and attackers struggle with. Clean code is both more accessible and harder to exploit.

Can security headers break screen readers?

Yes. Content Security Policy (CSP) headers that restrict script sources or inline styles can prevent assistive technology browser extensions from injecting their modifications. The fix: test CSP configurations with active screen reader extensions during staging, and use CSP report-only mode initially to identify conflicts before enforcing restrictions.

Is the BetterQA AI Security Toolkit free?

The toolkit orchestrates open-source security tools (Semgrep, Trivy, Nuclei, sqlmap, and others) through an MCP server. The tools themselves are free. You supply your own Claude API key for the AI orchestration layer that coordinates the seven-phase scan. There is no licensing fee for the toolkit. More details at betterqa.co/software-testing-services/ai-security-toolkit/.

What is the overlap between OWASP Top 10 and WCAG?

At least three OWASP categories intersect with WCAG criteria. A03:2021 (Injection) relates to WCAG 3.3.1 and 3.3.3 (error identification and suggestions). A07:2021 (Identification and Authentication Failures) relates to WCAG 3.3.8 (accessible authentication). A05:2021 (Security Misconfiguration, including CSP) can affect WCAG 4.1.2 (name, role, value) if assistive tech extensions are blocked.

How long does a combined accessibility and security audit take?

For a medium-complexity web application (50-100 pages, authentication flows, payment processing), a combined audit typically takes 8 to 11 weeks. This includes automated scanning (1-2 weeks), manual journey-based accessibility testing (3-4 weeks), targeted security penetration testing (2-3 weeks), and documentation generation (1-2 weeks). Running these in parallel rather than sequentially saves 4 to 7 weeks compared to separate audits.

Can I import existing scan results into Auditi?

Yes. Auditi accepts imports from axe, WAVE, Lighthouse, and pa11y through its REST API. This means automated accessibility checks from your CI pipeline flow into the same reporting interface as manual journey testing results. Auditi tracks results across project versions, so you can measure accessibility improvements between releases.

Getting started with combined testing

Organizations searching for top QA companies or best QA companies that handle both accessibility and security should evaluate whether their testing partner can address both disciplines. Most cannot. BetterQA built both tools specifically because clients kept encountering compliance gaps at the intersection.

Sources and references

Built by BetterQA, a software testing company that builds its own tools. Auditi handles WCAG compliance testing; the AI Security Toolkit handles security scanning. Together they close the gap between accessibility and security compliance.