Trust
Accessibility
This site is designed and tested to the Web Content Accessibility Guidelines (WCAG) 2.2 Level AA. We treat accessibility as a test a piece of work must pass before we hand it over, and we do not leave it for a repair job after launch.
Commitment
Accessibility is a test the work has to pass
Some of the people who use what we build rely on screen readers, magnification, speech input, switch access or a keyboard alone. A system they cannot operate does not go live, whatever its evaluation scores say.
We treat accessibility the way we treat security: we design it in at the start and test it with a check that passes or fails. This website targets conformance with WCAG 2.2 Level AA. The same standard goes into the acceptance criteria for the software we build, and the statement of work scopes and prices its evaluation up front.
Note
What we do not claim
No third party has audited this site for accessibility, and we hold no accessibility certification. This page is our own statement of what we built, how we tested it and what is still imperfect.
This site
The specific measures taken on this site
You can check each measure below. If one fails on a page, that is a defect, and we want to hear about it.
Structure and reading order
- Semantic landmarks (a real header, nav, main and footer) so assistive technology can jump between regions.
- Exactly one top-level heading (H1) per page, with headings in logical order and no skipped levels.
- A skip link to main content as the first focusable element on every page.
- Real tables with a caption and scoped header cells, not a grid of styled divs.
- Page language declared, and descriptive, unique page titles.
Operation and input
- Everything operable by keyboard alone, in a sensible order, with no focus traps.
- Focus indicators that are visible and not obscured by sticky headers or other content.
- Interactive targets meeting the 24 by 24 Cascading Style Sheets (CSS) pixel minimum, with adequate spacing.
- Forms with visible, persistent labels, programmatic purpose on personal fields, and error messages that name the field and say how to fix it, never colour or shape alone.
- Consistent navigation and consistent naming across the site.
Presentation
- Text contrast meeting or exceeding the AA thresholds, including on the navy sections.
- Non-text contrast for focus rings, borders, form controls and diagram elements.
- Support for 200% text zoom and 400% reflow without loss of content or horizontal scrolling.
- Reduced-motion support: where a transition exists, it is removed when the operating system requests reduced motion. Nothing on this site auto-plays, flashes or moves without user action.
- Information never conveyed by colour alone.
Content and resilience
- A text alternative for every diagram, plus an adjacent description in the page text, so the argument survives whether or not the image renders.
- Descriptive link text. No “learn more” and no “click here”.
- Content and core functionality work with JavaScript unavailable: routing, tables, pricing information and the contact form are all present in the server-rendered HyperText Markup Language (HTML).
- Plain language, expanded acronyms on first use, and short sentences.
Source
Standard applied: Web Content Accessibility Guidelines (WCAG) 2.2, Level AA, World Wide Web Consortium (W3C) Recommendation, including the 24×24 CSS pixel target minimum and the non-obscured focus requirements introduced in 2.2.
Testing
How this is tested
How do you know this site meets the standard?
Two layers run at every release. Automated checks run in the build against every route, and a violation fails the release. They catch contrast, landmark, label, heading-order and name-role-value problems. They cannot judge reading order, focus behaviour, link text quality or whether a diagram description helps. So a person walks the site by keyboard alone and then with a screen reader. Both layers must pass before a change ships.
| Check | Covers | When |
|---|---|---|
| Automated rule scan | Contrast, labels, landmarks, heading order, name-role-value, duplicate identifiers | Every build, on every route; blocking |
| Manual keyboard pass | Tab order, focus visibility, focus not obscured, no traps, skip link, target size | Every release |
| Screen-reader review | Reading order, link and heading quality, table semantics, diagram descriptions, form errors | Every release |
| Zoom and reflow | 200% text zoom, 400% reflow, small-viewport layout | Every release |
| No-JavaScript pass | Navigation, content, tables and the contact form with scripting unavailable | Every release |
Honesty
Known limitations
These are the areas we are still working on:
- Long comparison tables
- These scroll sideways on narrow screens. The scrolling is announced and works by keyboard. We are testing a stacked layout.
- Language
- This site is published in English and French. We write the French edition against an imposed terminology glossary instead of machine-translating it, and Alexander Leslie, a co-founder and native speaker of both languages, reviews it before it goes live. He also leads French-language engagements for client systems, and we do not offer machine translation in place of French service. We test both editions against the same criteria. Bilingual evaluation of delivered systems is a separate matter, described below.
- Third-party embeds
- We avoid them. If we ever add one, we test it to the same standard or it does not ship.
If you hit something not on this list, it is a defect we have not found yet. Please tell us.
Feedback
Report a barrier and get a timeline
Email info@whiteglovelabs.ai with “accessibility” in the subject line. Include the page address, what you were trying to do, and the assistive technology, browser and operating system you used. A one-line report is welcome too, and we will ask for any detail we still need.
If a page is unusable for you, ask. We will give you the content in another format or walk you through it directly.
Note
What we commit to
- Acknowledge within two business days, from a person, not an autoresponder.
- State a fix timeline once we have reproduced the issue. If the fix is bigger than a patch, we say so and give you a workaround for the meantime.
- Confirm when it is fixed, or add it to the limitations list above if it is not.
Context
The Canadian legal and standards context
The Accessible Canada Act commits federally regulated organizations to identifying, removing and preventing barriers, including in information and communication technologies, and to reporting publicly on progress. Federal institutions are expected to meet accessibility requirements in what they publish and in what they buy. Those expectations follow the European standard EN 301 549, which builds in WCAG for web content. So a procurement will normally reference WCAG Level AA, and an evaluator will ask you to demonstrate it rather than assert it.
That is the standard we build to. The known limitations of this site are listed above.