WizCountsAccessibility statement
WizCart Technologies Inc. builds WizCounts to be usable by people who work with a keyboard, a screen reader, a magnified screen, or simply with eyes that are tired at the end of a filing week. This page says what we target, what we actually test, what we know is not right yet, and how to tell us when we have got it wrong.
The standard we target
We build to WCAG 2.1 Level AA, and our automated gate additionally enforces the WCAG 2.2 AA rules that axe-core can check. One target covers every regime that can reach this product: Ontario's AODA (which requires WCAG 2.0 AA), the Accessible Canada Act by way of EN 301 549, and the United States' ADA and Section 508 practice — all of which resolve at or below WCAG 2.1 AA.
On our own initiative we go beyond the letter of the standard in two places: body text and numerals are held at 7:1 contrast — that is the AAA threshold, not the 4.5:1 AA one — and every piece of functional text is at least 12px, which WCAG does not require at all.
Conformance status: partially conformant with WCAG 2.1 Level AA. “Partially conformant” means most of the product meets the standard, and some parts do not yet. The parts we know about are listed below rather than left for you to find.
What we actually test
Accessibility claims are easy to make and easy to let rot, so ours is tied to a test that runs on every build and fails it.
- Automated scanning. axe-core runs with the WCAG 2.0 / 2.1 A and AA and the WCAG 2.2 AA rule sets over the public landing page, the features page, our security-disclosure page, this accessibility statement, the dashboard, sales invoices, the Smart Inbox (its pile, its review queue and its learned rules), the expenses screen, the three document editors — new estimate, new sales order and new purchase order — the published legal documents (the privacy policy page and, once terms are in force, the agreement screen shown before you continue), the privacy and retention screen, the legal publishing screen and the customer list with its address book open. Every one of those is scanned at both a 390px phone viewport and a 1280px desktop one. Any serious or critical violation fails the build, so a version that ships has none on those screens.
- Contrast. A separate check measures our colour tokens rather than sampling a page: 116 foreground/background pairs across every surface in both the light and dark themes, held at 7:1 for body text and numerals, 4.5:1 for secondary text and 3:1 for non-text elements such as borders and icons.
- Reflow at phone width. The same run asserts that at 390px there is no page-level horizontal scrolling on any of the screens it covers, with no exceptions. The one screen that used to be excepted — the expenses screen, whose line-entry grid was about 595px of columns — now lays each line out as a stacked card below 768px, with the same fields, the same labels and the same checks as the wide grid it replaces on a phone.
- Touch targets. The mobile navigation dock is measured tab by tab and every one must be at least 44 × 44px, which is above the 24px minimum WCAG 2.2 sets.
- Reduced motion. Scans run with
prefers-reduced-motionset, because that is the stable presentation and the one a motion-sensitive visitor receives. Both the public pages and the app honour that setting by disabling their animations. - Keyboard and screen-reader passes are done by hand as part of our review process — see the limitations below for what that does and does not amount to.
What that has produced
| Area | What is in place |
|---|---|
| Text size | 12px floor for every piece of functional text; body text 13–15px. Pinch-zoom is never disabled. |
| Colour | Contrast is never the only signal: the active item in a list is marked by an accent border and a tint, not by fading the others. |
| Phone layout | Below 768px the fixed sidebar is replaced by a compact top bar and a five-tab bottom dock, with labels always visible, the current tab marked with aria-current, and padding for the iPhone home indicator. |
| Tables | Data tables scroll inside their own focusable, labelled region instead of pushing the page sideways. |
| Structure | Named navigation landmarks, route changes announced through a live region, dialog and menu roles on the mobile More sheet, decorative icons hidden from assistive technology, and a visible focus ring from the shared token system. |
What is not right yet
These are the gaps we know about. If you hit something that is not on this list, it is not a known issue — please tell us.
- Automated testing covers roughly half of WCAG. No scanner can judge whether a label makes sense, whether a reading order is logical, or whether an error message tells you what to do. Our keyboard and screen-reader passes are part of a review habit, not a scheduled programme with published results.
- No independent audit. Nothing here has been verified by a third party. We do not publish a VPAT or an Accessibility Conformance Report. If you need one as a condition of purchase, ask us — a paid external audit is planned work, not finished work.
- The gate covers the screens listed above, not every screen. The product is larger than its automated coverage, and the less-travelled screens have had less scrutiny.
- Two lines of brand text sit at 11px — the “by WizCart Technologies Inc.” lockup — below our own 12px floor. They are decorative and repeat information given elsewhere on the page, but they are below our stated floor and are named here rather than quietly excepted.
Tell us about a problem
If part of WizCounts is hard or impossible for you to use, we want the report. It is worth more to us than a scanner result: tell us what you were trying to do, what got in the way, and what you use to browse — the browser, and any screen reader, magnifier or other assistive technology.
Write to the address published in /.well-known/security.txt and put Accessibility at the start of the subject line. We have one published inbox rather than several half-watched ones, which is why an accessibility report goes to the same place as a security report.
If that file is not reachable, this deployment has not published a contact address yet — in that case, ask the person or firm who set up your WizCounts account to pass your report to WizCart Technologies Inc.
We do not publish a guaranteed response time. We will read it, reply, and tell you honestly whether and when we expect to fix it.
Related
Our security disclosure policy covers reporting a vulnerability. The engineering record behind this statement — the conformance targets, the measures and the standing gate — is maintained internally as our accessibility and responsive conformance document, dated 26 July 2026; this page is the published summary of it.