Accessibility Conformance Report

How to read this report

Read the conformance tables looking for the rows that are not “Supports”. Each of them will name what fails, who it affects and the date it is planned to be fixed, and each will link to the published remediation plan.

Zero non-supporting entries is a red flag, not a green one. That sentence is from our own rubric for reviewing a vendor’s VPAT — the rubric this product asks customers to apply to their agenda portal and their payment vendor. A report claiming full support across all 50 criteria has almost always been produced without testing, and a reviewer who has read a few can tell.

The honest version is also the durable one. A conformance claim published for a criterion that was tested only by an automated engine is the kind of overclaim that drew a $1,000,000 FTC action against a company in this category. We never publish one.

Evaluation methods

Methodology

WCAG-EM (Website Accessibility Conformance Evaluation Methodology), applied to the 8 flows named below rather than to “the application”.

Automated engines

The 3 engines named in the footer of this page, run with the rule tags wcag2a, wcag2aa, wcag21a and wcag21aa. 1 of the 3 runs today.

Manual evaluation

A guided test run inside BarrierOps, on the BarrierOps asset. The run id and its completion date are published with the report.

Assistive technology

The 10 configurations below, each recorded with its software version and the date it was last run.

Sample and its rationale

8 page templates across the application and the marketing site, selected by the clustering model as the structurally distinct set, plus the 2 highest-traffic instances of each. A sample chosen by traffic alone would miss the templates a disabled employee uses most and a visitor never sees.

Scope

A report reflects the state of the product at its evaluation date. It does not certify ongoing conformance, and it is revised rather than extended.

Automated testing detects roughly 30–40% of real barriers. Manual testing covers the rest. Every conformance value in this report derives from manual evaluation. Automated results inform the remarks and never determine the value.

The assistive-technology matrix

None of the 10 configurations below has been run against any of the 8 flows. The list is the matrix a report is produced from, published here as a commitment rather than as a record — when it runs, each row gains the software version it was run with and the date it was last run, including the runs that found something.

• NVDA with Firefox
• NVDA with Chrome
• JAWS with Chrome
• VoiceOver with Safari on macOS
• VoiceOver with Safari on iOS
• Narrator with Edge
• Dragon, on two of the eight flows
• Keyboard only
• 400% zoom in a 320 px viewport
• Windows High Contrast Mode

Full matrix twice a year and before any revision of our conformance report. Keyboard-only and 400% zoom on every release.

Dragon covers flows 3 and 4 only. We do not claim speech-input coverage of the other 6, and the gap is published on our accessibility statement.

TalkBack with Chrome on Android is not on a schedule. That is a gap in the programme rather than a criterion, and it is published on our accessibility statement.

The test scope

1. Sign-in, including multi-factor authentication
2. Asset creation and ownership verification
3. The issue list, with filtering and sorting
4. Issue detail and a status change
5. Evidence export and chain verification
6. Report download
7. A manual test run, executed end to end
8. The public barrier-report form

We did not test “the whole application”, and this report does not claim we did. A report whose scope is “the product” is a report whose scope was never defined.

The conformance tables

Both tables appear here when the evaluation is complete, and there is nothing to show in the meantime — the state of this report says why. What follows is how they are drawn, which is decided and does not wait for the evaluation.

• Both tables carry the 3 columns the Information Technology Industry Council (ITI) puts in its own template, in ITI’s order — Criteria, Conformance Level, Remarks and Explanations — so a reviewer comparing this report against another vendor’s reads the same 3 headings in the same places.
• The 4 conformance values are never coloured. Each is its own words plus a distinct shape, all 4 in the same ink at the same weight. Colour would rank them, a ranked conformance report is the thing this product refuses to publish, and it makes the honest rows look like failures.
• Every row carries a remark, including a row whose value is “Supports”, and no remark is ever shortened, clipped or hidden behind a control — at any window size, and on paper.
• There is no sorting, no filtering and no “show only failures”. Every row is in the page in criterion order, so the printed form and the screen form are the same document and Ctrl-F finds the row you are looking for.
• Every criterion has a stable address of its own, so a row can be linked to from a bid response or an email.
• The report is summarised as counts, and never as a percentage, a proportion of the standard or a chart, here or in the Word version. A percentage of the WCAG standard satisfied is a claim this company does not make, and it is the number a reviewer would have to explain to their own counsel.

Downloads

The report as a Word document (.docx)

VPAT 2.5Rev structure, generated in the same build as this page and compared against it cell by cell. The format a bid response attaches.

The report as OpenACR (YAML)

The machine-readable edition, for a procurement system that ingests one.

Neither file is published, because neither has anything to contain. Both are generated in the same build as this page and are compared against it before they ship, so they cannot disagree with what you are reading.

Editions

WCAG

The canonical edition, and the one published here.

Section 508

Generated from the same evaluation, and available on request once that evaluation is complete.

EU (EN 301 549) and International

Not published. We do not sell into the EU, and an edition nobody has asked for is an edition nobody checks.

The OpenACR YAML is offered as a convenience. Its schema is built on VPAT 2.4Rev508 and WCAG 2.0 — two revisions behind — and our claim targets 2.5Rev against WCAG 2.1. Where the two disagree, this page is authoritative.

Versions

• A finalised report is immutable. A correction creates a new version and marks the previous one superseded, and both stay retrievable.
• A superseded version keeps its own address, carries a notice saying it was superseded and when, and is kept out of search results so the current report is the one people find.
• This page always serves the current version. The path never carries a version number, so a link in a procurement file from eighteen months ago still lands on something true.

How this report is generated

The report is generated from a completed manual test run inside BarrierOps, on the BarrierOps asset. It is not written by hand.

Generation is impossible without a completed manual run — the product refuses, and explains why. An unresolved “Cannot tell” on any criterion blocks the whole report until it is resolved, which is the single rule that separates this from a VPAT produced by guesswork.

A release touching any of the 8 flows requires a written answer, in the pull request, on whether this report is still accurate. When it is not, the report is revised before the release ships, or the release does not ship.

The gaps in our own testing programme, each with what we know and what we do not, are on our accessibility statement, and the dated plan for fixing them is our remediation plan.