Accessibility Statement

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.

The standard we build the website to is WCAG 2.2 Level AA, the current version, which the W3C published in October 2023. WCAG 2.2 adds six Level A and AA success criteria to 2.1: Focus Not Obscured (Minimum), Dragging Movements, Target Size (Minimum), Consistent Help, Redundant Entry and Accessible Authentication (Minimum). We checked each on the website in October 2026, as set out under "WCAG 2.2: what we checked". Our conformance claim stays at "partially conformant with WCAG 2.1 Level AA" because the manual audit against the 2.1 criteria covers only four tasks; we do not claim conformance to WCAG 2.2 as a whole.

"Partially conformant" means some parts of the service do not yet fully conform. We use this term rather than "fully conformant" because our evidence does not support more. Most of it is automated, and automated tooling detects only a portion of accessibility barriers — commonly estimated at a third to a half of WCAG failures. A manual audit of four of the website's main tasks, described below, found barriers that are not yet fixed, and we have not yet tested with real assistive technology.

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

The checks below are our current evidence. Browser suites run against the real application and seeded identities when they are executed; source and unit gates run locally and fail when their asserted accessibility contract is broken.

Every axe audit in this table other than the WCAG 2.2 row runs axe-core's default rules, which test against WCAG 2.0 and 2.1 Level A and AA, plus axe-core's best-practice rules, and fails on any serious or critical finding. axe-core's one WCAG 2.2 rule, target size, is off by default and those audits do not turn it on. The WCAG 2.2 row turns it on. A clean run is not a conformance claim.

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.
• Compact provider-calendar visit controls used colour as the easiest way to distinguish visit status, and the month view's overflow control was a small text target. Visit controls now include the status in their accessible names, and the overflow control has a named minimum 24-pixel target height.

The manual audit found barriers the automated runs had not caught. They are listed under "Known limitations" below and recorded for fixing.

The Android app

The app has a section of its own because it is checked differently from the website. A person using the Android app finds this statement under Settings → Accessibility, which opens this page in the phone's browser and has a Report a barrier button that writes to accessibility@eznest.ca. A business sees the same section at the foot of its business Settings.

What is checked on the app today, all of it automated and run by our own team:

• An automated check (npm run lint:android-a11y) fails the build when an icon-only button has no spoken name, or when a touch target that can be pressed is set smaller than 48 dp.
• Screen tests drive the app with 200% text size on several screens — Today, messages, appointments, Settings, the provider desk and documents — and fail when the last item or a main control can no longer be reached.
• For a set of screens (not every screen), captures at 100% and 200% text size in English and Canadian French, in light and dark appearance, are compared with recorded references, so a change that clips or overlaps text shows up as a difference.

What has not been tested on the app:

• No manual audit against the WCAG 2.1 Level A and AA checklist. The audit of the four website tasks does not cover the app.
• No full walk with TalkBack, Voice Access or switch access. On 2 November 2026 we ran one partial check on a Pixel 8 with TalkBack on, moving between controls with a keyboard rather than with TalkBack's swipe gestures. It reached only some screens: Find help and one business page in English, the first controls of Find help in Canadian French, and the first fields of the Post a project form. It did not reach signing up or approving a milestone, did not read plain text in TalkBack's reading order, and did not hear French spoken by a French voice. It found barriers that are not yet fixed, so we do not count it as a pass. The automated checks above do not hear what TalkBack says, and cannot judge whether a spoken name is meaningful or whether the reading order makes sense.
• No testing with people who use these tools daily, and no third-party audit.
• The app has not been checked against a phone's own display settings beyond text size, such as colour correction or high-contrast text.

We update this section as each of these is done, and not before.

The iPhone app

We make no conformance claim for the iPhone app. The "partially conformant" status above rests on the manual audit of the website, and nobody has yet audited the iPhone app against the WCAG 2.1 Level AA checklist. This section says what is checked on the iPhone today and what is not, and it changes when a walk of the app lands.

If you meet a barrier in the app, open Settings → Accessibility. In the homeowner app, Settings is under Account settings in the account menu; in the business app, it is Settings. The Accessibility section there opens this statement and writes to the feedback address under "Feedback, and asking for content in another format" below.

What is checked on the iPhone

What has not been tested on the iPhone

• No person has walked the app with VoiceOver, Voice Control or Switch Control. Whether the reading order is sensible, whether a control's name makes sense in context, and whether a result is announced after an action are untested. This is step 2 under "How to improve this statement", and it has not been done for the iPhone.
• No manual audit of the iPhone app against the WCAG 2.1 AA checklist, and no testing with people who use assistive technology on the iPhone.
• The automated audit covers only the screens it names. For the business app that is seven screens, and for the administrator seven; the rest are not in it, and the homeowner run is signed out apart from four screens.
• Contrast and text-size behaviour outside the tests named above are not checked. The audit does not judge them, and the other checks cover only the screens and components they name.
• No physical-device accessibility acceptance is claimed here.

WCAG 2.2: what we checked

WCAG 2.2 Level AA adds six success criteria to the ones in 2.1. This is what we did for each on the website in October 2026, what we found, and what is still open. It was done internally, in Chromium only.

2.4.11 Focus Not Obscured (Minimum)

Checked: a keyboard walk with Tab and Shift+Tab through fourteen public pages (the home page, sign-in, sign-up, support, the homeowner and provider terms, privacy, accessibility, acceptable use, account deletion, subprocessors, work record, and the two business pages under For businesses), in the light and dark themes at 390 and 1440 px, reporting any focused control that a sticky or fixed bar covers completely.

Found: walking backwards up a page could leave a focused control under the page's top bar, because the public pages' bars did not tell the browser to stop short of them. Fixed: those pages now keep room below the bar, and so do the signed-in header when the test-environment banner is shown and the bar of the page where a quote or invoice is written. No covered control is left in the fourteen pages. The same walk, run on the signed-in pages for a homeowner, a business and an administrator on the seeded demo stack (the shell, the pages with a sticky strip, the quote and request forms, the dispatch board, the household lock screen), in both themes at 390 and 1440 px, found no control covered by the header or a bar.

2.5.7 Dragging Movements

Checked: a scan of the website's code for every place a pointer drag or a slider is handled, and a check that each has a way to do the same thing without dragging.

Found: six places. Moving a visit on the dispatch board has Give to and Move buttons on every visit. The three places to drop a file (money import, the document vault, a garage item's documents) each open the file picker from a button. The two debt-payoff sliders each have a number field for the same amount. No failure found. This was read from the code and pinned by a test; we did not try each with a pointing device or switch.

2.5.8 Target Size (Minimum)

Checked: axe-core's target-size rule, switched on, over the same fourteen pages, themes and widths.

Found: no failure on the public pages, and none on the signed-in pages of the three roles (every page in the website's route sweep, light theme, 390 and 1440 px). In the signed-in header's breadcrumb trail, two wrapped links sat closer than the rule allows; fixed by widening the gap. The earlier internal review of the 24 px minimum had already fixed three smaller controls.

3.2.6 Consistent Help

Checked: the signed-in header's Help & support link, for homeowners, businesses and administrators, with the menu loaded and with each way it can fail to load; and the contact line at the foot of each legal page.

Found: the Help & support link is in the same place, after Notifications and before the account menu, for all three roles and in every case tested. Every legal page takes its contact line from one component, so it sits in the same place on all of them. No failure found. The other public pages (the home page, sign-up, the business pages) have no help link or contact line of their own, so there is no help to place inconsistently there.

3.3.7 Redundant Entry

Checked: a read of the website's multi-step forms: the request form (four steps) and the document-sharing steps in the vault.

Found: each keeps what was typed when you go back or forward, and the request form starts the address from the home on your account when we have one. No failure found in those two. Other forms were not read for this criterion, and the identity provider's account form was not tested.

3.3.8 Accessible Authentication (Minimum)

Checked: the website's own code fields and password fields: the signing passcode, the two-step verification code, the household kiosk PIN, and every password field the website draws itself.

Found: the three code fields cut off a pasted code that had a space or a hyphen in it ("123 456" arrived as "123 45") and refused it. Fixed: each now keeps the digits from what was pasted. No field blocks pasting, and every sign-in password field carries the setting a password manager looks for. The sign-in and sign-up pages themselves are supplied by our identity provider; we have not tested them against this criterion. One thing above is not yet done and is recorded for follow-up: a test of the identity provider's sign-in and sign-up pages against 3.3.8.

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.

• The manual audit covers only the four tasks above. The rest of the website has had no manual audit against the WCAG 2.1 AA checklist, and automated rules cannot judge whether alternative text is meaningful, whether focus order is logical, or whether an error message is understandable. Within sign-up, the account form our identity provider supplies, where a new account's details are entered and confirmed, was not part of the audit.
• No full 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. The only such check so far is the partial, keyboard-driven TalkBack check on one phone described under "The Android app", which is not a pass.
• No third-party accessibility audit.
• The Android app is not released, and it has had no manual audit and no TalkBack pass. What is checked on it is listed under "The Android app" above. No screen-reader, voice-control or switch-access acceptance pass on a phone is claimed here.
• WCAG 2.2 on the identity provider's sign-in and sign-up pages. See "WCAG 2.2: what we checked". The signed-in pages were checked in a browser for focus not obscured and target size only; the dark theme was not walked for target size.
• The other public legal pages are not in the automated axe audit. The Acceptable Use Policy, this statement, the provider terms (/terms/providers), the work-record criteria, the subprocessor list, the support page and the account-deletion page have not been through the automated axe audit; they are covered only by the whole-route sweep's mechanical checks.
• Admin pages have no automated axe audit. The signed-in acceptance suite checks only that they render and that their navigation works.
• 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.

The manual audit of October 2026 found these barriers, all but the last in the four tasks it covered. They are not yet fixed:

• In the signed-in header, the small labels that name the icon buttons disappear when the pointer moves onto them and cannot be dismissed with Escape; the search button is announced as "Open command palette" although it shows "Search workspace"; and in the light theme the theme button's icon is too faint.
• Some text fields (the invite-code field, several search fields and two note fields) have a faint outline, and some forms show example text in a colour that is too pale.
• The sign-up page and businesses' public profile pages have a general browser title that does not name the page.
• On a business's public profile, the request-a-quote form's focus outline is hard to see on its green panel, and its consent box shows no focus. If both the phone number and the email are left empty, or the consent box is left unticked, the error is not announced to screen-reader users.
• On the request form, the address fields do not identify themselves to browser autofill; which fields are optional or required is shown visually but not announced; and the minimum length of the title and description is not stated.
• At 400% zoom, a project page's "Open a warranty or deficiency case" button is cut off at the edge of the screen.
• After a milestone is approved, the confirmation appears on the page but is not announced to screen-reader users.
• On this page and the other published legal pages, some longer bulleted points are shown as a short bullet followed by a separate paragraph, so a screen reader reads the rest of the point outside the list.

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 or screen, what you were trying to do, and what got in the way. In the iPhone app, Settings → Accessibility → Report a barrier opens a message to this address. 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.2 AA regardless (2.2 is the current version), 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:

1. A manual WCAG 2.1 AA audit of the highest-traffic flows: sign-up, finding a provider, requesting a quote, approving a milestone. Done for the website on 22 October 2026, except the identity provider's account form within sign-up; the barriers it found are listed under "Known limitations". The six criteria WCAG 2.2 adds were checked on the website in October 2026 (see "WCAG 2.2: what we checked"); the identity provider's pages are still to do.
2. Screen-reader testing of those same flows on at least one desktop and one mobile screen reader.
3. Testing with people who use assistive technology daily.
4. A third-party audit, once 1–3 are done and their findings fixed.

Until step 2 is complete and the barriers step 1 found are fixed, this statement continues to say "partially conformant".

Published 2026-08-30. Last re-verified 2026-10-26, row by row, against the checks named above, except the iPhone rows, which were added on 2026-10-29 and checked against the code on 2026-11-02. Re-verified after material accessibility changes and at least annually, so the next full re-verification is due by 2027-10-26 or when the next audit lands.