CitySchedule

Product Information

Applicable Standards / Guidelines

Terms

• Supports — The functionality of the product has at least one method that meets the criterion without known defects, or meets with equivalent facilitation.
• Partially Supports — Some functionality of the product does not meet the criterion.
• Does Not Support — The majority of product functionality does not meet the criterion.
• Not Applicable — The criterion is not relevant to the product.
• Not Evaluated — The product has not been evaluated against the criterion. (Used only for WCAG 2.x Level AAA.)

WCAG 2.1 Report

Conformance level reflects the state of the codebase as of the date above, including the accessibility remediation described in Appendix: Remediation Applied.

Table 1 — Success Criteria, Level A

Table 2 — Success Criteria, Level AA

Revised Section 508 Report

Chapter 3: Functional Performance Criteria (FPC)

Chapter 4: Hardware

Not Applicable (software-only web application).

Chapter 5: Software

Chapter 6: Support Documentation and Services

Appendix: Remediation Applied (2026-06-22)

The following fixes were made during this accessibility pass and are reflected in the conformance levels above:

1. Decorative iconography hidden from assistive tech — emoji icons in the sidebar navigation/account menu, stat cards, empty states, warning banners, the search field, the city-select placeholder, and report engagement rows are now aria-hidden, eliminating screen-reader noise (1.1.1).
2. Charts given a text alternative — each bar/pie chart in Reports now renders a visually-hidden, captioned <table> of the underlying figures, and the decorative SVG is aria-hidden so the data is announced exactly once (1.1.1).
3. Clickable non-native elements made keyboard-operable — the shared Card, inspection-record rows, reservations-table rows, and the desktop schedule appointment blocks now expose role="button", are focusable (tabIndex=0), and activate on Enter/Space, with descriptive aria-labels (2.1.1 / 4.1.2).
4. Input purpose identified — an autoComplete/inputMode prop was added to the shared Input primitive and wired to the account name, booking phone, and service-address fields; auth fields already carried the correct tokens (1.3.5).
5. Color-contrast failures fixed — a deeper gold (#946a22) replaces the brand gold on filled buttons and link text (white-on-gold was 3.22:1); the landing footer text, marketing-page tagline, and auth "or" divider were corrected. The hover state that re-brightened CTAs (dropping them below threshold) was removed (1.4.3).
6. Automated accessibility gate added — @axe-core/playwright scans every unauthenticated page (WCAG 2.1 A/AA) on desktop and mobile in the e2e suite (npm run test:e2e:a11y); it currently reports zero violations and guards against regressions.
7. Authenticated components brought under automated scan — axe-core checks of the reservations table, report charts/data tables, inspection-record rows, and the reservation detail dialog were added to the vitest suite (src/test/a11y/). This surfaced and fixed an unlabeled sort <select> and date filter in the reservations table (4.1.2 / 1.3.1).
8. Per-route page titles — dashboard and authentication routes now set a descriptive document.title from their heading; legal/marketing routes use Next.js metadata (2.4.2).
9. Public Accessibility Statement published — /accessibility documents the conformance target, features, known limitations, supported AT, and a barrier-reporting channel with a 5-business-day response commitment; linked from the site footer (508 §602; ADA Title II program expectation).
10. Notification emails — the email shell now declares lang="en", uses a semantic <h1>, and its gray label/footer/subtitle text was darkened to meet 4.5:1; the Turnstile captcha region carries an accessible group label.
11. Keyboard sweep completed — the remaining mouse-only clickable elements were made keyboard-operable: the admin dashboard appointment cards, the resident and admin inspection-record disclosure headers (now real/role buttons with aria-expanded, with the rename/remove actions kept as separate non-nested controls), and the resident booking and reservation-detail file-upload dropzones. This moves 2.1.1 and FPC 302.7 to full Supports (2.1.1 / 4.1.2).
12. Pointer-only tooltips remediated — denied-reservation reasons now render as persistent wrapping text instead of a clipped title; the inspection-photo upload Retry error and unavailable time-slot reasons are exposed in their control's accessible name. No essential information is conveyed solely through a native title tooltip, moving 1.4.13 to full Supports (1.4.13).
13. Authenticated full-route scan added and run — a Playwright + axe-core suite signs in per role through the real UI (clearing mandatory MFA via a seeded TOTP secret) and scans every dashboard route at the page level (npm run test:e2e:a11y:auth), extending coverage from key components to whole authenticated pages. Running it surfaced and fixed real defects: insufficient contrast of muted secondary text on the cream page background (1.4.3), unlabeled date/time inputs on the booking and calendar screens (1.3.1 / 4.1.2), and a focusable chart surface inside an aria-hidden wrapper on reports (4.1.2). All dashboard routes now scan clean across resident, admin, and super-admin roles. It is gated on seeded test-user credentials so it skips cleanly where they are not configured.
14. Manual screen-reader findings addressed — a keyboard/screen-reader pass of the booking flow and admin dashboard prompted a batch of fixes: the shared Select no longer suppresses its focus ring; the two bespoke portal modals (reservation detail, inspection result) gained full dialog semantics and a focus trap via a shared useModalA11y hook; booking groups/labels (assign inspection records, sub-service type, attach-documents dropzone, download-form actions) were programmatically associated; and icon/ambiguous controls across the admin managers (disclosure toggles, view/remove/edit/reset/delete buttons) and the schedule and reservation list cards received descriptive accessible names (1.3.1 / 2.4.3 / 2.4.7 / 4.1.2).
15. Route-change focus management & residual label sweep — on client-side navigation, keyboard focus is now moved to the main content landmark (which carries tabIndex=-1) so screen-reader and keyboard users land at the start of the newly rendered page instead of remaining on the activated sidebar link, making the page change perceivable (2.4.3). A follow-up sweep added accessible names to the last icon-only controls whose name had been a bare glyph — the department/template/record rename (✎) buttons, the replace/remove (↻/×) actions on submitted-form chips, and the remove-attachment (×) buttons in the reservation-detail and resident reservation views — and an explicit aria-label to the department filter <select>s that had relied on a title tooltip alone (2.4.4 / 2.5.3 / 4.1.2).

Appendix: Recommended Next Steps

• Execute the scripted NVDA/JAWS/VoiceOver bench test (docs/accessibility-at-bench-test.md) to validate the non-visual "Supports" claims and close out FPC 302.1; feed any defects back before flipping it to full Supports.
• Provision per-role seeded test users in the CI environment so the authenticated full-route axe scan (npm run test:e2e:a11y:auth) runs on every build rather than only where credentials are configured.
• Confirm with each city that uploaded/city-supplied blank forms have an accessible alternative format available on request (the platform's barrier-reporting channel already offers this for residents).