Accessibility Conformance Statement
Last reviewed: August 3, 2026 · Audit performed July 18, 2026
iVenza is committed to being usable by every athlete and coach, including those who use screen readers, keyboard navigation, magnification, or other assistive technology. This statement records what we audited, what we claim, and - just as importantly - the exceptions we know about.
Why this matters for public institutions
ADA Title II applies to public entities, including public school districts and public colleges and universities. The Department of Justice's 2024 final rule sets WCAG 2.1 Level AA as the technical standard. An interim final rule published in April 2026 extended the compliance dates by roughly a year:
| Public entity | Compliance date |
|---|---|
| Population of 50,000 or more | April 26, 2027 |
| Population under 50,000, and special district governments | April 26, 2028 |
The obligation runs to the institution, but an institution can only meet it if its vendors conform. We treat this as a requirement, not a nice-to-have.
Standard and scope
| Standard | WCAG 2.2 Level AA - a superset of the WCAG 2.1 Level AA that ADA Title II requires |
|---|---|
| Scope | The iVenza mobile apps for iOS and Android, the web app at my.ivenza.app, and this marketing site |
| Audit date | July 18, 2026 |
| Method | Internal audit with remediation in the same pass, combined with automated accessibility linting in the build pipeline |
| Formal VPAT | Not produced - we do not hold a VPAT 2.5 document. This statement contains the same substance |
Conformance claim
Substantially conformant with WCAG 2.2 Level AA, with the documented exceptions below.
We deliberately do not claim full conformance, because the three exceptions listed are real and we know about them. "Substantially conformant with documented exceptions" is something an institution's accessibility office can actually work with; an unqualified claim that later fails a review helps nobody.
What the audit changed
- Color and contrast. Color tokens were reworked so text and interface components meet contrast minimums in both light and dark themes. Dark-mode text on primary buttons was changed to near-black, because no shade of our brand red passes AA both as a button fill under white text and as text on the dark background. Light-theme success and warning colors were darkened.
- Runtime contrast for dynamic colors. Chip and badge text color is now computed from the fill it sits on, so a colored surface can never produce failing contrast.
- Keyboard and structure. Skip links added to the web app and this site; focus visibility, form labeling, and landmark structure corrected.
Known exceptions
| Issue | Criterion | Where | Status |
|---|---|---|---|
| The PDF field placer, used by staff to position signature boxes on an uploaded document, requires pointer input. Placement is not achievable with a keyboard alone. | 2.5.7 Dragging Movements | Web app, staff only | Open. Not on a student path |
| Some bright accent colors fall below AA when used as small statistic text on light surfaces. | 1.4.3 Contrast (Minimum) | Mobile | Open. Affects a subset of numeric readouts |
| Two marketing forms do not set a per-field invalid state on a validation error. Errors are announced, but not attributed to the specific field. | 3.3.1 Error Identification | This marketing site | Open |
None of the three sit on a student's core path through the product, and all three are tracked.
How this is maintained
- Accessibility lint rules run in the build pipeline. In the web app they currently run as warnings rather than build-failing errors.
- We re-audit on major interface releases. This is a standing trigger in our compliance review process, not an ad hoc decision.
Report a barrier
If any part of iVenza is difficult or impossible for you to use, tell us at help@susos.co. We aim to acknowledge within 3 business days and will describe either a fix or a workaround.