Timely is committed to making the product usable by people with disabilities. This page documents our current WCAG 2.2 conformance status, based on the testing we've actually completed — not a certification, and not a claim of full compliance. Where a criterion hasn't been evaluated, we say so.
Scope of this evaluation
Testing covered the authenticated dashboard application — the screens a signed-in manager or owner uses day to day: Schedule, Timesheets, Team, Requests, Labor, Analytics, Rules, Billing, and every page under Settings/Admin (19 pages total).
Not yet covered by this evaluation: the marketing site (trytimely.com's public pages), this documentation site, onboarding, sign-up/login, the employee-facing SMS/kiosk clock-in flow, and the mobile-optimized schedule view's own interaction patterns. We plan to extend testing to these surfaces over time.
Conformance target: WCAG 2.2 Level AA.
How we evaluated it
Three things, used together:
- Automated testing. We run an automated accessibility scanner against all 19 in-scope pages as part of our regular testing process, checking for color contrast, missing form labels, unnamed interactive controls, and similar programmatically-detectable issues. The scan runs in both light and dark mode. As of this writing, both runs report zero violations across all 19 pages — down from 369 issues found when we started this evaluation, 3 of which were dark-mode-specific contrast failures invisible to a light-mode-only scan.
- Mapping automated checks to specific criteria. Our scanner runs about 70 individual rules under this evaluation's WCAG tag set, and each one maps to a specific success criterion. A clean scan result is evidence for every criterion with at least one rule behind it — not just the categories we happened to be actively fixing — so we went through that mapping directly rather than crediting only the criteria we'd already been looking at. Below, any row citing "automated scan" reflects a rule that actually exists and actually ran clean, not an assumption. Roughly half of the 2.2 A/AA criteria have no automated check at all (things like focus order, error messages, consistent navigation, dragging alternatives) — those needed a different method or stay unevaluated.
- Manual keyboard and code-level testing. Where no automated rule existed, we did what we could: verified tab order and focus visibility across representative pages, checked that dialogs are announced correctly to assistive technology and dismissible with Escape, resized the viewport to 320px on four pages to check for reflow, inspected the page for heading structure, and reviewed source code directly for things like status-message ARIA wiring and whether drag interactions have a non-drag alternative. This is real testing, not a scan, but it's a spot-check, not exhaustive coverage of every control and flow — see "Known limitations" below.
We have not performed a full screen reader test pass (VoiceOver/NVDA/JAWS), and have not tested with real assistive-technology users. Automated tools like the one we use catch roughly a third of WCAG issues; the rest require manual and human testing we haven't yet completed.
Conformance terms
| Term | Meaning |
|---|---|
| Supports | The functionality has been verified to meet the criterion across the evaluated scope. |
| Partially Supports | Some but not all of the functionality meets the criterion, or it meets the criterion only in the specific ways described in Remarks. |
| Does Not Support | A known, unresolved failure exists. |
| Not Evaluated | We have not yet tested against this criterion. This is not a claim that the product fails it — only that we haven't checked. |
| Not Applicable | The criterion does not apply (e.g. no audio/video content exists in the product). |
WCAG 2.2 report
Perceivable
| Criterion | Level | Conformance | Remarks |
|---|---|---|---|
| 1.1.1 Non-text Content | A | Partially Supports | Automated scan checks image alt text and accessible names on ARIA image/meter/progressbar roles; reports zero violations across all 19 pages. Doesn't verify that present alt text is actually meaningful, only that it exists. |
| 1.2.1 Audio-only and Video-only (Prerecorded) | A | Not Applicable | No prerecorded audio/video content in the product. |
| 1.2.2 Captions (Prerecorded) | A | Not Applicable | |
| 1.2.3 Audio Description or Media Alternative | A | Not Applicable | |
| 1.3.1 Info and Relationships | A | Partially Supports | Automated scan found and we fixed missing form-label associations and unnamed <select> elements; automated checks for list, table, and definition-list structure also pass cleanly across all 19 pages. A heading-nesting gap found by manual review (Settings pages skipped from <h1> to <h3> before any <h2>) has been fixed and re-verified live — the settings rail's group labels were visual navigation labels, not real content headings, and are now <p> elements instead of <h3>. |
| 1.3.2 Meaningful Sequence | A | Not Evaluated | |
| 1.3.3 Sensory Characteristics | A | Not Evaluated | |
| 1.4.1 Use of Color | A | Partially Supports | Spot-checked several status/warning indicators we touched during this evaluation — shift overtime flags, SMS opt-in status, rule severity badges — and each pairs color with a text label or icon rather than relying on color alone. Not exhaustively reviewed across every page. |
| 1.4.2 Audio Control | A | Not Applicable | |
| 1.4.4 Resize Text | AA | Partially Supports | Automated scan confirms no page's viewport configuration disables browser pinch-to-zoom, across all 19 pages. Doesn't verify every layout stays usable at 200% zoom specifically. |
| 1.2.4 Captions (Live) | AA | Not Applicable | |
| 1.2.5 Audio Description (Prerecorded) | AA | Not Applicable | |
| 1.3.4 Orientation | AA | Partially Supports | Automated scan (an experimental rule) finds no CSS orientation lock on any of the 19 pages. Not verified on a real rotatable device. |
| 1.3.5 Identify Input Purpose | AA | Partially Supports | Automated scan confirms any autocomplete attributes present are valid values. Doesn't verify autocomplete is added everywhere it should be (e.g. name/email/phone fields) — only that what's there isn't malformed. |
| 1.4.3 Contrast (Minimum) | AA | Partially Supports | Automated scan for text/background contrast across all 19 in-scope pages reports zero violations as of this writing, run separately in light mode and dark mode. Not verified: contrast in every interactive/hover/error state, or on pages outside the evaluated scope. |
| 1.4.5 Images of Text | AA | Not Evaluated | |
| 1.4.10 Reflow | AA | Partially Supports | Manually tested Schedule, Timesheets, Team, and Settings → Locations at a 320px viewport width — no page-level horizontal scrolling on any of them; Schedule switches to a purpose-built single-column mobile layout below a breakpoint rather than shrinking the desktop grid. Not tested on the other 15 pages. Internal scrolling within data-dense grids (which WCAG's reflow exception explicitly permits) wasn't separately audited. |
| 1.4.11 Non-text Contrast | AA | Does Not Support | Focus indicators were observed to render with a visible, non-transparent outline during manual testing, but this was a spot-check, not a full audit. Concretely: our automated scanner's contrast check only evaluates text, not icon-only controls — it reported zero violations while two icon-only toolbar buttons on the Schedule page rendered at roughly 1.6:1 contrast in dark mode, well under the 3:1 minimum for non-text UI components. Found via user report, not automated testing; fixed on discovery. We don't yet have systematic coverage for this category. |
| 1.4.12 Text Spacing | AA | Partially Supports | Automated scan confirms inline text-spacing styles (where present) can be overridden by a user stylesheet, across all 19 pages. Doesn't verify every text block stays readable when a user actually applies WCAG's 1.4.12 spacing values. |
| 1.4.13 Content on Hover or Focus | AA | Not Evaluated |
Operable
| Criterion | Level | Conformance | Remarks |
|---|---|---|---|
| 2.1.1 Keyboard | A | Partially Supports | Manual testing confirmed tab order reaches every interactive element we checked, in a logical sequence, across the main navigation and several representative pages. We were not able to independently confirm keyboard activation (Enter/Space on every button) across the full app in this pass — our browser-automation testing tool doesn't reliably deliver synthetic key events the way a real keyboard does, a tooling limitation rather than something observed to fail. Reordering employee rows in the Schedule grid's Overview view previously had no keyboard path at all; see 2.5.7 for the fix and its verification status. |
| 2.1.2 No Keyboard Trap | A | Not Evaluated | |
| 2.1.4 Character Key Shortcuts | A | Not Evaluated | |
| 2.2.1 Timing Adjustable | A | Not Evaluated | |
| 2.2.2 Pause, Stop, Hide | A | Not Evaluated | |
| 2.3.1 Three Flashes or Below Threshold | A | Not Evaluated | |
| 2.4.1 Bypass Blocks | A | Partially Supports | Automated scan confirms every page exposes <nav> and <main> landmark regions, which satisfies this criterion's requirement for a way to skip repeated navigation — verified across all 19 pages. There's no dedicated "skip to content" link; landmark regions alone are an accepted WCAG technique for this criterion. |
| 2.4.2 Page Titled | A | Supports | Automated scan confirms every one of the 19 pages has a non-empty, descriptive <title>. |
| 2.4.3 Focus Order | A | Partially Supports | Confirmed logical, predictable focus order through primary navigation during manual testing; not exhaustively verified across every page and modal. |
| 2.4.4 Link Purpose (In Context) | A | Partially Supports | Automated scan found and we fixed one case of a link distinguishable from surrounding text by color alone. |
| 2.5.1 Pointer Gestures | A | Not Evaluated | |
| 2.5.2 Pointer Cancellation | A | Not Evaluated | |
| 2.5.3 Label in Name | A | Not Evaluated | |
| 2.5.4 Motion Actuation | A | Not Applicable | No motion-actuated functionality. |
| 3.2.6 Consistent Help | A | Not Evaluated | |
| 3.3.7 Redundant Entry | A | Not Evaluated | |
| 2.4.5 Multiple Ways | AA | Not Evaluated | |
| 2.4.6 Headings and Labels | AA | Not Evaluated | |
| 2.4.7 Focus Visible | AA | Partially Supports | Manual testing observed a visible focus outline (non-transparent, distinct color) on every element tabbed to in the pages checked. |
| 2.4.11 Focus Not Obscured (Minimum) | AA | Not Evaluated | |
| 2.5.7 Dragging Movements | AA | Partially Supports | Found via source-code review: reordering employee rows in the Schedule grid's Overview view had no keyboard path at all — the drag library was configured for pointer input only, and there was no click-based alternative. Fixed by enabling the library's standard keyboard sensor (its documented pattern for exactly this: Tab to the drag handle, Space to pick up, arrow keys to move, Space to drop) rather than building a separate alternative control. Deployed and partially verified: the handle now renders the correct accessible attributes (role="button", aria-roledescription="sortable") that the library only outputs when its keyboard support is properly wired, which is real evidence the fix is implemented correctly. What we could not confirm is the interaction actually completing end-to-end — our browser-automation tool's synthetic key presses didn't register with the library's keyboard handler (its live-region for announcing pickup/move stayed silent), the same tooling limitation noted at 2.1.1, not a sign the fix doesn't work. A real-keyboard manual test is the next step to close this out fully. |
| 2.5.8 Target Size (Minimum) | AA | Partially Supports | Automated scan checks WCAG 2.2's 24×24px minimum touch-target size and reports zero violations across all 19 pages. |
Understandable
| Criterion | Level | Conformance | Remarks |
|---|---|---|---|
| 3.1.1 Language of Page | A | Partially Supports | Automated scan found and we fixed a missing page-language declaration, verified across all 19 in-scope pages. |
| 3.2.1 On Focus | A | Not Evaluated | |
| 3.2.2 On Input | A | Not Evaluated | |
| 3.3.1 Error Identification | A | Not Evaluated | |
| 3.3.2 Labels or Instructions | A | Not Evaluated | |
| 3.2.3 Consistent Navigation | AA | Partially Supports | The primary sidebar navigation rendered in the same order with the same labels on every one of the 19 pages we tested this pass, confirmed during manual keyboard-navigation testing. Not verified on pages outside the evaluated scope. |
| 3.2.4 Consistent Identification | AA | Partially Supports | Repeated UI components — toasts, status badges, form controls — go through a small set of shared components used across every page rather than being reimplemented per page, confirmed via code review while making fixes during this evaluation. Not exhaustively checked against every instance. |
| 3.3.3 Error Suggestion | AA | Not Evaluated | |
| 3.3.4 Error Prevention (Legal, Financial, Data) | AA | Not Evaluated | |
| 3.3.8 Accessible Authentication (Minimum) | AA | Not Evaluated |
Robust
| Criterion | Level | Conformance | Remarks |
|---|---|---|---|
| 4.1.2 Name, Role, Value | A | Partially Supports | Automated scan found and we fixed several unnamed interactive controls (toggle switches, filter dropdowns). Separately, manual testing found that overlay dialogs weren't exposed to assistive technology as dialogs at all — we've since added proper dialog semantics and an Escape-to-close affordance to every overlay modal in the evaluated scope, and re-verified the fix in production. Known gap: these dialogs don't yet implement a JavaScript focus trap, so a sighted keyboard user can still tab past a dialog into page content behind it, even though it's marked aria-modal="true" for assistive technology — that mismatch is on our list to close next. |
| 4.1.3 Status Messages | AA | Supports | The app's toast/notification system is a single shared implementation used exclusively everywhere a status message appears — verified via code review that no page bypasses it. Success/info messages render with role="status" and aria-live="polite"; errors render with role="alert" and aria-live="assertive". |
Known limitations
- No screen reader testing has been performed with real assistive technology (VoiceOver, NVDA, or JAWS).
- Overlay dialogs are marked with dialog semantics but do not yet implement a keyboard focus trap — see the 4.1.2 remark above.
- Automated testing is limited to what a scanner can detect programmatically; it does not verify meaning, reading order, or whether an interaction actually makes sense to someone using assistive technology. Confirmed concretely: our scanner's contrast check only examines text, so icon-only buttons can fail badly (we found and fixed one case at roughly 1.6:1) without ever showing up as a violation.
- Testing scope is the authenticated dashboard application only (see "Scope" above) — the marketing site, documentation, onboarding, and employee-facing SMS/kiosk flows have not yet been evaluated.
- A keyboard path for reordering employee rows in the Schedule grid's Overview view has been added, but the end-to-end interaction isn't yet confirmed working via real-keyboard testing — see the 2.5.7 remark above.
- Roughly half of the WCAG 2.2 A/AA success criteria have no corresponding automated check in our scanner at all — see "How we evaluated it" above for which method (if any) covers each row in the table.
- Our browser-automation testing tool doesn't always deliver synthetic keyboard events the way a real keyboard does — confirmed concretely with the drag-reorder fix above, where the tool's Space/Arrow key presses didn't register with the library's keyboard handler even though the underlying implementation is correctly wired. This means some "verified via testing" claims in this document reflect what our tooling could observe, which is narrower than what a person using a real keyboard would experience.
Report an issue
If you encounter an accessibility barrier anywhere in Timely, email support with the page and what happened. We treat accessibility reports as bugs and prioritize them accordingly.
Last updated: September 2026.