Skip to content

WCAG Compliance

OpenScouter tests against the Web Content Accessibility Guidelines (WCAG) 2.1, the internationally recognised standard for digital accessibility. Every finding in your report maps to a specific success criterion, so your team knows exactly what to fix and why it matters.

What WCAG 2.1 Covers

WCAG 2.1 is organised around four principles. Content must be Perceivable, Operable, Understandable, and Robust. These are known as the POUR principles.

Perceivable

Users must be able to perceive all information and interface components. OpenScouter tests include:

  • 1.1.1 Non-text Content - Images, icons, and controls have meaningful text alternatives
  • 1.3.1 Info and Relationships - Structure and relationships conveyed through presentation are also available programmatically
  • 1.3.3 Sensory Characteristics - Instructions do not rely solely on shape, colour, size, or position
  • 1.4.1 Use of Colour - Colour is not the only visual means of conveying information
  • 1.4.3 Contrast (Minimum) - Text has a contrast ratio of at least 4.5:1 against its background
  • 1.4.4 Resize Text - Text can be resized up to 200% without loss of content or functionality
  • 1.4.10 Reflow - Content reflows at 320 CSS pixels wide without horizontal scrolling
  • 1.4.11 Non-text Contrast - UI components and graphical objects meet a 3:1 contrast ratio

Operable

Users must be able to operate all interface components and navigation. OpenScouter tests include:

  • 2.1.1 Keyboard - All functionality is available from a keyboard
  • 2.1.2 No Keyboard Trap - Keyboard focus is never locked or constrained in a way the user cannot escape
  • 2.4.1 Bypass Blocks - A mechanism exists to skip repeated navigation
  • 2.4.2 Page Titled - Pages have descriptive titles
  • 2.4.3 Focus Order - Focusable components receive focus in a sequence that preserves meaning
  • 2.4.4 Link Purpose - The purpose of each link is clear from its label or context
  • 2.4.7 Focus Visible - Any keyboard operable interface has a visible focus indicator
  • 2.5.3 Label in Name - Interactive components with visible labels include that text in their accessible name

Understandable

Users must be able to understand the information and operation of the interface. OpenScouter tests include:

  • 3.1.1 Language of Page - The default human language of each page is programmatically determinable
  • 3.2.1 On Focus - Receiving focus does not trigger unexpected context changes
  • 3.2.2 On Input - Changing a setting does not cause unexpected context changes unless the user is informed
  • 3.3.1 Error Identification - Input errors are identified and described to the user in text
  • 3.3.2 Labels or Instructions - Labels or instructions are provided for user input
  • 3.3.3 Error Suggestion - If an input error is detected, suggestions for correction are provided where possible
  • 3.3.4 Error Prevention - For legal, financial, or data transactions, submissions are reversible, checked, or confirmed

Robust

Content must be robust enough to be interpreted by a wide range of technologies. OpenScouter tests include:

  • 4.1.1 Parsing - HTML is well-formed with complete start and end tags and correct nesting
  • 4.1.2 Name, Role, Value - All UI components have a name and role that can be programmatically determined, and states and values can be set programmatically
  • 4.1.3 Status Messages - Status messages can be programmatically determined so assistive technology can announce them without focus

How Findings Map to Criteria

Every issue in your OpenScouter report includes a direct WCAG reference. This removes ambiguity for your development team and simplifies documentation for regulators.

FindingWCAG CriterionLevel
Missing form label1.3.1 Info and RelationshipsA
Image with no alt text1.1.1 Non-text ContentA
Insufficient colour contrast1.4.3 Contrast (Minimum)AA
Button with no accessible name4.1.2 Name, Role, ValueA
Keyboard trap in modal2.1.2 No Keyboard TrapA
Error message not linked to field3.3.1 Error IdentificationA
Focus indicator removed2.4.7 Focus VisibleAA
Link text says “click here”2.4.4 Link Purpose (In Context)A

Your report groups findings by severity and WCAG level. Level A issues are the most critical. Level AA issues are required for most regulatory and legal compliance targets.

Compliance Documentation for Regulators

OpenScouter generates documentation you can share directly with regulators, legal teams, or procurement partners.

Each compliance report includes:

  • A summary of the WCAG 2.1 conformance level tested (typically AA)
  • A full list of success criteria evaluated, with pass or fail status
  • Detailed findings with criterion references and evidence
  • Tester notes explaining the user impact of each issue
  • A remediation priority order based on severity and user impact

Reports are dated and signed by the lead tester. You can use them to demonstrate due diligence, support accessibility statements, and respond to formal complaints or regulatory enquiries.

If you need a specific report format to satisfy a procurement requirement or regulator request, contact your account manager.

FCA Consumer Duty Mapping

For UK financial services firms, WCAG compliance supports your obligations under the FCA Consumer Duty (PS22/9), which came into force in July 2023.

Consumer Duty requires firms to deliver good outcomes for retail customers. The Duty covers four outcomes: products and services, price and value, consumer understanding, and consumer support.

Accessibility barriers directly affect three of these outcomes.

Consumer Understanding requires that communications are clear and support customers in making informed decisions. Screen reader incompatibility, missing error messages, and unclear form labels all undermine this outcome. OpenScouter maps findings such as 3.3.1 (Error Identification), 3.3.2 (Labels or Instructions), and 1.3.1 (Info and Relationships) to this obligation.

Consumer Support requires that firms provide support enabling customers to realise the value of products and services. Navigation barriers, keyboard traps, and inaccessible live chat widgets prevent customers from accessing support. OpenScouter tests 2.1.1 (Keyboard), 2.4.1 (Bypass Blocks), and 4.1.2 (Name, Role, Value) are directly relevant here.

Products and Services requires that products are designed to meet the needs of customers, including those with characteristics of vulnerability. WCAG AA conformance is a baseline expectation. Findings across Perceivable and Operable criteria directly affect whether vulnerable customers can use your products.

OpenScouter reports include a Consumer Duty mapping table on request. This shows each WCAG finding alongside the relevant Consumer Duty outcome, giving your compliance team a clear audit trail.

Automated vs Human-Tested Compliance

Automated accessibility scanners are fast and consistent. They catch a specific category of issues reliably: missing attributes, insufficient colour ratios, invalid HTML structure. These tools are useful as part of a development workflow.

However, automated tools can only evaluate what is programmatically determinable. They cannot assess whether navigation makes sense, whether an error message is actually helpful, or whether a multi-step process is possible to complete without becoming lost.

Research consistently shows that automated tools detect between 30 and 40 percent of real-world accessibility barriers. The remainder require human judgement.

OpenScouter testers use assistive technology in their daily lives. They complete real tasks on your product: applying for an account, reading a statement, contacting support. They encounter the friction that automated tools never see.

The comparison matters for compliance purposes too. A product that passes an automated scan can still fail WCAG and exclude real users. A product tested by disabled people is more likely to be genuinely usable, and more likely to hold up under scrutiny from regulators or legal challenge.

OpenScouter reports document both what was tested and how it was tested. Where a finding required human judgement rather than automated detection, this is noted. This transparency supports robust compliance documentation and demonstrates that your accessibility programme goes beyond checkbox compliance.