Our commitment
Eznest is a home-services marketplace. People use it to decide who they will let into their home, and to approve money. Those are exactly the decisions where an inaccessible interface stops being an inconvenience and starts excluding someone from the transaction entirely. We treat accessibility as part of whether a feature works, not as a later pass over it.
This statement describes what we have actually tested and what we have not. It deliberately does not claim full conformance, because we have not done the testing that would justify that claim.
Conformance status
Partially conformant with WCAG 2.1 Level AA.
"Partially conformant" means some parts of the service do not yet fully conform. We use this term rather than "fully conformant" for one honest reason: our conformance evidence is automated, and automated tooling detects only a portion of accessibility barriers — commonly estimated at a third to a half of WCAG failures. The rest require manual testing with real assistive technology, which we have not yet completed.
Claiming AA conformance on the strength of a green automated run would be a claim our evidence does not support.
What we have actually tested
Every check below runs against the real application, not a mock, and fails the build when it fails.
| Surface | Coverage | How |
|---|---|---|
| Public pages (landing, sign-in, sign-up, legal pages, public provider profiles, prospect claim pages) | Automated axe audit in both light and dark themes | apps/web/e2e/public-a11y.spec.ts |
| Signed-in homeowner, provider and admin pages — 131 routes, of which 25 are admin | Automated axe audit against real seeded data | apps/web/e2e/role-acceptance.spec.ts |
| Colour tokens across the web app | Dark-mode and contrast token gate | npm run lint:theme |
| iOS app | Accessibility gate over SwiftUI surfaces | npm run lint:ios-a11y |
Real defects this has already caught and fixed, rather than theoretical ones:
- A provider rating badge used a hardcoded colour that failed contrast in both themes on the public
provider profile — the page a homeowner reads when deciding whom to trust.
- Information text on public prospect pages used a token reserved for hints and disabled text, which
fails contrast when used for content.
What we have not tested
We state these plainly because a reader deciding whether they can use this service deserves to know where our evidence stops.
- No manual audit against the full WCAG 2.1 AA checklist. Automated rules cannot judge whether alternative
text is meaningful, whether focus order is logical, or whether an error message is understandable.
- No testing with real assistive technology — screen readers (NVDA, JAWS, VoiceOver, TalkBack), voice
control, or switch access — and no testing with users who rely on them.
- No third-party accessibility audit.
- The Android app is not covered. It is not released, and it has no accessibility gate yet.
- Automated coverage is route-level. A barrier that appears only after a specific interaction — inside a
modal, mid-form, or after an error — may not be exercised by the audit.
Known limitations
- Some data-dense administrative tables scroll horizontally on small viewports. They are usable, but the
experience is worse on a narrow screen than on a wide one.
- Some interactive components have been verified for contrast and labelling by automated rules but not for
screen-reader announcement order.
Feedback, and asking for content in another format
If you meet an accessibility barrier here — or need something we publish in a different format — tell us and we will provide it. Under the Accessibility for Ontarians with Disabilities Act, we will supply accessible formats and communication supports on request, in a timely way and at no additional cost.
Email: accessibility@eznest.ca
Tell us the page, what you were trying to do, and what got in the way. We aim to acknowledge within 5 business days. Where we cannot fix something quickly, we will say so and tell you the workaround.
If our response does not resolve the issue, you may contact the Accessibility Directorate of Ontario.
Legal obligations we track
Thresholds and filing years can change. We re-check them at each hiring milestone and before any required filing.
- Accessible formats and feedback process — applies to us now, regardless of headcount. Addressed by the
process above.
- WCAG 2.0 Level AA for websites — under the Integrated Accessibility Standards Regulation this obligation
attaches to private organizations at a headcount threshold we are currently below. We are building to WCAG 2.1 AA regardless, because the obligation arrives with growth and retrofitting is dearer than building.
- Accessibility compliance report — organizations at or above the reporting threshold must file with the
Province in designated years. Eznest is below that threshold today (see docs/corporate/ENTITY.md), so no report is currently due. This is re-checked at every hiring milestone and before each designated filing year.
How to improve this statement
The honest path from "partially conformant" to a stronger claim is, in order:
- A manual WCAG 2.1 AA audit of the highest-traffic flows: sign-up, finding a provider, requesting a quote, approving a milestone.
- Screen-reader testing of those same flows on at least one desktop and one mobile screen reader.
- Testing with people who use assistive technology daily.
- A third-party audit, once 1–3 are done and their findings fixed.
Until at least steps 1 and 2 are complete, this statement should continue to say "partially conformant".
Published 2026-08-30. Re-verified after material accessibility changes and at least annually.