Accessibility Statement

§1 · Commitment

Our commitment

Accessibility isn't a feature we added — it's the reason WCAGHub exists. WCAGHub Pty Ltd (ABN [TBD], "we", "us") is committed to ensuring that everyone — regardless of disability, age or assistive technology — can use our platform to check, improve and monitor the accessibility of their own digital content.

We measure our product against WCAG 2.2 Level AA and aim for Level AAA where it is sensible and does not compromise clarity. We design and test with real assistive technology (screen readers, switch devices, magnifiers, voice control), not just automated tooling.

We believe accessibility is continuous: this Statement is updated at least every 6 months, open issues are tracked publicly in §5, and we welcome every report — even small ones.

§2 · Scope

Scope of this Statement

This Statement covers:

• The public website at wcaghub.com and all subpages served from that domain.
• The customer dashboard at app.wcaghub.com, including account settings, billing, and scan-history views.
• The three checker apps: Web Accessibility Checker, PDF Accessibility Checker and Document Accessibility Checker, including their report views and interactive fix guides.
• PDF and DOCX reports exported from WCAGHub, which are produced as tagged, structured, accessible documents.

The Statement does not cover:

• Third-party websites linked from our platform.
• Our customers' own content scanned through WCAGHub — we report its accessibility but we do not control it.
• Third-party tools integrated into our workflows (e.g. the Stripe checkout page), which are governed by the vendors' own accessibility statements.

§3 · Conformance

Conformance with WCAG 2.2

WCAGHub aims for WCAG 2.2 Level AA conformance across the entire platform. The current status is partially conformant — i.e. most content meets the standard, but some parts do not yet fully conform. Open gaps are listed in §5.

WCAG 2.2 added nine new success criteria on top of 2.1. Our position on each:

§4 · Built for accessibility

What we've deliberately built for accessibility

Rather than list only the absence of barriers, here's the affirmative work — features built specifically so people with disabilities can use WCAGHub independently.

§5 · Known issues

Known issues & exceptions

We publish open gaps against our own target. We update this section whenever an issue is introduced, planned, or resolved. If you find something else, please report it (§10).

• A11Y-OPEN-01 · Interactive "marker tooltip" close icon is 20×20 px On the Web Checker report, the small (x) button that dismisses a marker tooltip is 20×20 CSS px. This falls below WCAG 2.2 SC 2.5.8 Minimum (24×24). A keyboard equivalent (Esc) and a larger "Close" button in the panel footer are both available — so SC 2.5.8 Exception 1 applies — but we will enlarge the icon in the next UI sprint regardless. Opened 2026-02-10 · Status: fix scheduled 2026-05
• A11Y-OPEN-02 · Colour contrast on muted timestamps in dashboard Muted timestamps ("3 days ago") currently hit 4.3:1 contrast against white — just below the 4.5:1 Level AA threshold for body text. Fix queued: deepen the muted colour by one step. Opened 2026-03-02 · Status: fix scheduled 2026-05
• A11Y-OPEN-03 · Legacy pricing table on blog posts older than 2025-12 A small number of older blog posts still use a pre-2024 pricing table without proper <th scope> attributes. The table is read by screen readers but column relationships are not announced. Opened 2025-12-08 · Status: content rewrite in progress

§6 · Alternatives

Accessible alternatives

If any part of WCAGHub is inaccessible to you in its current form, we provide free accessible alternatives — this is a firm commitment, not a favour.

• Reports by email. We can deliver any scan report as a plain-text email, an accessible tagged PDF, a Word document or a structured CSV — whichever works best for you.
• Human walk-through. Our support team can walk you through any report or dashboard over the phone or video call, in English, and will describe visual elements aloud on request.
• Manual scan submission. If the scan-setup dashboard is unusable for you, email a URL or upload a file via encrypted transfer to info@wcaghub.com and we will run the scan for you and return the results in your preferred format.
• API alternative. Developers using assistive tech can bypass the UI entirely via our REST API, which is documented in a fully accessible way.
• Reasonable adjustments. If none of the above fits, we commit to a bespoke adjustment at no cost. Write to info@wcaghub.com describing what you need.

§7 · Testing methodology

Testing methodology

The platform is tested using a combination of automated, manual, and lived-experience approaches. None of these substitutes for the others — automated tooling can only catch a subset of WCAG failures.

Automated tooling

• axe-core rules run in CI on every pull request that changes front-end code.
• WCAGHub's own Web Checker is run against every deploy as a dogfood exercise.
• Lighthouse a11y audit runs nightly against our marketing site and customer dashboard.
• Pa11y CI acts as a second automated opinion on release branches.
• VeraPDF validates every exported PDF for PDF/UA conformance.

Manual testing

• Keyboard-only walk-through of every critical flow (sign-up, checkout, scan, report, cancel) on each release.
• Screen-reader testing with NVDA (Windows + Chrome/Firefox), JAWS (Windows + Chrome) and VoiceOver (macOS + Safari, iOS + Safari) at least monthly.
• Zoom + reflow test at 400% zoom, 320 CSS-pixel viewport width.
• High-contrast and forced-colors mode on Windows and macOS.
• Voice-control test using Dragon NaturallySpeaking and macOS Voice Control.
• Switch-device test using iOS Switch Control and macOS Switch Control.

User testing

We regularly engage disabled users and accessibility consultants for scheduled feedback rounds — not just as testers, but as collaborators on design. The goal is to ship nothing without someone relying on assistive tech having touched it.

Third-party audit

An annual independent WCAG 2.2 audit by a certified external accessibility consultancy is scheduled for Q3 2026. The audit report will be summarised here and the full findings made available to customers under NDA.

§8 · AT compatibility

Assistive-technology compatibility

WCAGHub is actively tested with the following assistive-tech combinations. Other combinations likely work too, but these are the ones we sign off on each release.

§9 · Regional alignment

Regional alignment

We align our conformance target with the major national and regional accessibility regimes so that the same audit satisfies multiple obligations.

§10 · Report a problem

How to report an accessibility problem

If WCAGHub is not accessible to you in any way, please tell us. We treat accessibility reports as P1 issues and respond faster than standard support.

1. Send us the details.

   Email info@wcaghub.com, or use the in-app "Report accessibility problem" link in any footer. Please tell us: the page URL or screen, what you tried to do, the assistive technology you were using, and what went wrong.

2. Acknowledgement within 2 business days.

   You'll get a reply from a named person with a reference number and our initial assessment of severity.

3. Resolution target: 10 business days.

   For critical barriers we aim to ship a fix within 10 business days. For complex issues we agree a longer timeline with you and give you a workaround or an accessible alternative (§6) in the meantime.

4. Verification with you.

   Once fixed, we don't just close the ticket — we ask you to confirm the fix works for you in your own environment.

5. Published in §5.

   Any material issue that cannot be fixed immediately is added to the "Known issues" list (§5) so other users know we're aware and working on it.

§11 · Enforcement

Enforcement & complaint pathways

If you are not satisfied with our response to an accessibility complaint, you can escalate through a regulator or equality body in your country. Our goal is to resolve issues before that is necessary, but your right to complain is not limited by anything in this Statement.

• European Union. Each EU Member State has a national enforcement body under the Web Accessibility Directive and the EAA. Contact details are collected on the European Commission's accessibility portal.
• United Kingdom. The Equality and Human Rights Commission (EHRC) enforces the Equality Act 2010; public-sector website complaints go to the Equality Advisory and Support Service (EASS).
• United States. Civil Rights Division, US Department of Justice for ADA complaints; the Access Board oversees Section 508.
• Australia. Complaints under the DDA go to the Australian Human Rights Commission.
• Canada. Canadian Human Rights Commission (federal) and provincial commissions under AODA, Code Québec, etc.
• Brazil. Ministério Público and Defensoria Pública under the LBI.

§12 · Changes

Changes to this Statement

This Statement is reviewed and republished at least every 6 months, and immediately whenever a material change to the platform affects conformance. Previous versions are preserved at /legal/accessibility-statement/history/ so you can see how our position has evolved.

This version (3.1) was prepared on 19 April 2026 and takes effect on the same date. Next scheduled review: 19 October 2026.

§13 · Contact

Contact

This Accessibility Statement is published in English. If you need it in a different language or format, contact info@wcaghub.com and we will provide one at no cost.