Standards (WCAG 2.1 AA)
Dirty Laundry Co. targets WCAG 2.1 Level AA for the public site, aligned with AODA expectations for Ontario. The site uses semantic landmarks, labelled forms, visible focus, skip-to-content links, text alternatives for meaningful images, keyboard-operable controls, and form status messages that do not rely on colour alone.
The public site is designed for mobile from the first pass. Interactive controls are intended to meet the 44 by 44 pixel touch target rule on small viewports. Text contrast is checked against the shared design token system, and the public site uses light mode only so customers see a predictable, readable surface.
Accessibility is treated as part of the service promise. A visitor should be able to understand the service area, compare pricing, read policies, start a booking draft, request a quote, and contact support without depending on a mouse, large screen, animation, or visual-only signal.
Conformance Self-Assessment
The public-site work includes automated axe checks, keyboard smoke tests, and visual evidence. The current statement reflects the public site implementation state on May 9, 2026. Evidence is generated against the static build, not only against the development server, because customers receive static HTML from the deployed public site.
Automated checks cannot prove every accessibility requirement. They are paired with manual review expectations: keyboard tab order, visible focus, responsive layout, no incoherent overlap, text overflow checks, image framing checks, and form state review. These checks should be repeated before production cutover and after material design changes.
The booking, quote, and contact flows are reviewed at the frontend layer because labels, field grouping, status messages, file controls, and step announcements are user-facing. Backend validation adds another layer, but it does not replace frontend accessibility.
Known Limitations
Some behaviours, such as account verification, payment authorization, quote acceptance, file upload storage, and backend validation, require their own accessibility review when those paths change.
French content is scaffolded but not fully translated. The language switcher is disabled with a tooltip so visitors are not sent to unfinished translated content. This is a known limitation and should be resolved only when a real French copy pass is opened.
Blog posts, customer reviews, and visual assets should be reviewed before production for descriptive headings, useful link text, meaningful alt text, plain language, and reading order.
Feedback Process
Accessibility feedback can be sent through the contact page or by email at hello@dirtylaundry.local. Please include the page, browser, device, and assistive technology if relevant. A short description of what you expected, what happened, and what blocked you is enough to start the review.
Support response target is within 48 business hours. Accessibility feedback is handled through that same service path during MVP. If the issue prevents use of the booking, quote, service-area lookup, or contact flow, please say that clearly so it can be prioritized before less blocking visual issues.
Dirty Laundry Co. may ask for more detail if the report cannot be reproduced. You do not need to share private medical information or personal documents to report an accessibility issue. The goal is to understand the barrier and fix the experience.
AODA Compliance Statement
Dirty Laundry Co. intends to maintain an accessible customer-facing service and review issues before production cutover. The project target is WCAG 2.1 Level AA, which is the accessibility target named in the project goals. This statement does not claim that every future backend or authenticated app feature has already been reviewed.
AODA-related work is not a one-time checklist. It affects design tokens, copy, navigation, form behaviour, keyboard access, error messages, evidence capture, and support response. Customer app, admin console, email template, and deploy work must keep accessibility in their own task evidence.
If a barrier is found, the operator should decide whether it can be fixed immediately, scheduled before production cutover, or documented as a known issue with a practical workaround. Known issues should not be ignored simply because automated tests pass.
Review Schedule
Last reviewed: May 9, 2026. This statement should be reviewed again before production cutover and after any major public-site change. Major changes include new forms, new navigation patterns, new media, new language support, new analytics or security widgets, or a change to production APIs.
The review should include automated axe results, keyboard navigation, mobile layout, reduced-motion behaviour, image alt text, heading structure, policy readability, and form error recovery. It should also check that evidence files are current and that any known false positive entry is specific, dated, capped, and justified.
Accessibility evidence belongs in the project evidence folder so future agents and reviewers can see what was tested. If the evidence cannot be generated, the blocker should be recorded rather than silently marking the work complete.
