Why This Page Exists
PayCal is used for time, pay, and account tasks that people repeat often. When a page is hard to read, hard to navigate, or hard to operate without a mouse, it slows real work down.
We publish this page so users can see the standard we are using, the accessibility changes we have already shipped, and the areas we are still improving.
Our Working Standard
We use WCAG 2.1 Level AA as our working standard for product accessibility. We also adopt selected AAA ideas when they clearly improve usability, but we do not claim AAA conformance.
We do not claim that every route is perfect at all times. We do commit to fixing verified barriers, documenting changes, and keeping accessibility work in the normal engineering workflow.
Verification Metadata
Route Metadata
- Route:
/transparency/accessibility/ - Last verified:
- Next review due:
- Verification scope: strict WCAG route scans, reflow/text-spacing checks, keyboard smoke checks, and manual VoiceOver route review.
Known Limitations
- Manual screen-reader pass across core routes has not yet produced route-by-route VoiceOver notes and per-defect tracking (WCAG-015, in progress).
- Announcement wording (clarity and conciseness) in high-feedback flows is the remaining focus after live-region structure separation was completed.
- Third-party dependency review may identify component-specific constraints or upgrade restrictions as external libraries receive major updates.
This metadata is updated as part of the quarterly audit close-out so users can see what was verified, what still has limits, and when the next formal review is due.
Assistive Technology Support Policy
We publish support expectations based on the combinations we verify directly and the combinations we review during scheduled audits. This is a support matrix, not a claim that every browser and assistive technology pairing behaves identically.
| Platform | Browser | Assistive technology | Support expectation | Verification model |
|---|---|---|---|---|
| macOS | Safari | VoiceOver | Primary verified combination | Manual route review in regular WCAG checks and quarterly audits |
| Windows | Firefox | NVDA | Supported audit combination | Scheduled manual validation during quarterly audits |
| Windows | Chrome | JAWS | Supported audit combination | Scheduled manual validation during quarterly audits |
| Other combinations | Current major browsers | Other AT or voice control tools | Best-effort support | Issues triaged through the accessibility defect process |
When users report a barrier on a best-effort combination, we still investigate it. If the issue affects core semantics, keyboard behavior, or shared components, we treat it as a product defect even when the exact pairing is not in the primary verified set.
Deprecation and Change Policy
- We do not intentionally drop support for a verified browser and assistive technology combination without publishing the change on this page first.
- When a verified combination becomes impractical to support because of vendor, platform, or security constraints, we target at least one quarterly-cycle notice before it moves to best-effort status.
- Any deprecation notice should include the affected combination, why it changed, the effective date, and the nearest supported alternative.
If a reported barrier affects a combination we currently verify directly, the issue is triaged against that support expectation and not treated as optional.
Third-Party Dependency Accessibility Review
Most audited PayCal interactions use first-party UI code. Where third-party browser-side code exists, we track its accessibility impact separately so upgrades do not bypass keyboard, semantics, or CSP expectations.
| Dependency | Usage | Accessibility status | Notes |
|---|---|---|---|
pdf-lib |
Client-side earnings PDF export | Approved | Non-widget export library. Does not add keyboard UI, but generated output still depends on first-party labeling and content quality. |
tweetnacl |
Client-side cryptography helpers | Approved | Non-visual utility library. Accessibility impact is indirect and limited to keeping first-party flows responsive and stable. |
- Approved: allowed for current use, with accessibility impact understood and documented.
- Conditional: allowed only in limited scope while review, replacement, or containment work remains open.
- Blocked: not allowed for new UI use until accessibility requirements are met.
Any new browser-side dependency that adds UI, focus handling, dialog behavior, embedded media, or custom widgets should be reviewed before adoption and re-reviewed before major version upgrades.
What Is In Place Now
- Core navigation supports keyboard use, skip links, and documented single-key shortcuts for major destinations.
- Single-key shortcuts (C, R, S, E, A, H, N, P, ?) are documented for the main application routes.
- Shortcuts do not fire while typing in inputs or when dialogs are open.
- Help and transparency routes provide more than one way to navigate, including breadcrumbs where that adds useful context.
- Audited routes use semantic landmarks, clear headings, direct labels, and status messaging where the interaction needs feedback.
- Contrast and focus token checks are automated across the current theme catalog, and the published matrix is tracked in our accessibility backlog workflow.
- Settings include a dyslexia-friendly typography preference with accessible spacing and fallback stack support.
- Accessibility reports can now start from this page and continue into the secure contact flow with the key details prefilled.
We prefer semantic HTML first and use ARIA where it helps expose names, relationships, or live status changes more clearly.
Quick access keys
PayCal publishes single-key shortcuts for major destinations so frequent routes remain reachable without repetitive pointer travel. The current documented set covers calendar, organizations, settings, earnings, admin, help, notes, pay periods, and keyboard shortcut help.
These shortcuts are part of the accessibility contract only when they are predictable, documented, and safe to ignore. Users can keep navigating with standard links, buttons, skip links, and landmarks without relying on shortcut memorization.
Focus Safety
Focus safety rules prevent shortcut handlers and scripted UI from stealing focus while someone is typing or working inside a modal. Shortcuts do not fire inside editable controls, and dialog interactions keep focus scoped until the dialog closes.
This policy reduces accidental navigation, protects form entry, and keeps keyboard behavior consistent with the route-level regression coverage we run in Playwright and Lightpanda.
What We Actively Verify
- Route-level WCAG scans run against core pages, including strict route sweeps for violations and stricter contrast checks.
- Heading and form regressions are checked so landmark structure, labels, and recovery messaging do not silently drift.
- Reflow and text-spacing coverage checks core routes at compact viewport widths to catch horizontal overflow and spacing failures.
- Navigation-path and shortcut regression tests verify breadcrumbs, alternate paths, feedback handoff, shortcut safety behavior, and keyboard shortcut policy coverage.
- Suite-level checks combine Playwright, PHPUnit, and browser-matrix coverage so accessibility claims remain test-backed.
This means our public accessibility statements are tied to actual regression coverage, not just intent.
Recent Improvements
- 2026-03-23: Applied 30+ design tokens for status bars, verification banners, countdown timers, and form/dialog spacing components, removing all direct color coupling from shared styles and extending the contrast matrix to cover the new token pairs (WCAG-020).
- 2026-03-23: Added verification metadata (last-verified date, next-review date, scope, and known limitations) to all four active transparency sub-pages: accessibility, metrics, taxes, and verification-governance (WCAG-021).
- 2026-03-23: Simplified 31 error and status strings across auth, calendar, and organizations flows: removed technical jargon (nonce references), made field-empty messages actionable, and standardized organization error messages to a consistent "Couldn't X. Please try again." pattern (WCAG-024).
- 2026-03-23: Published component-level accessibility standards covering dialogs, tabs, datagrids, and forms with keyboard/ARIA contracts and do/don't examples; cross-linked from PR template and regression workflow (WCAG-025).
- 2026-03-23: Separated assertive error announcements from polite progress announcements on /auth/ and /settings/ to remove duplicate live-region output (WCAG-017).
- 2026-03-23: Published accessibility defect SLA table with acknowledge windows, fix targets, owners, and escalation paths (WCAG-019).
- 2026-03-23: Published a formal remaining-work checklist and a quarterly accessibility audit playbook with owners, route coverage, and evidence requirements.
- 2026-03-23: Added an accessibility feedback intake path from this page into the secure contact form.
- 2026-03-23: Added breadcrumbs and regression coverage for multiple navigation paths on key public routes.
- 2026-03-23: Resolved strict contrast blockers on core public routes and kept those checks in the WCAG route suite.
- 2026-03-23: Added dyslexia-friendly typography preference coverage in settings, with accessible font stack and spacing behavior.
- 2026-03-22: Added route-level reflow and text-spacing coverage for core pages at compact viewport widths.
- 2026-03-20: Added documented application-style shortcuts with protections so they do not fire while typing or while dialogs are open.
- 2026-04-12: Added aria-label to the read-only current email input in change-email dialogs on settings and profile pages; replaced four hardcoded English labels in the Data Portability section with i18n-backed strings.
What We Are Still Improving
- External audit readiness package: pre-packaging issue history, remediation logs, and policy evidence so a complete audit package can be produced within one business day (WCAG-026).
Current Open Work
- WCAG-026: External audit readiness package — pre-packaging issue history, remediation logs, evidence artifacts, and policy docs so an audit evidence package can be produced within one business day.
This is the active item in our WCAG execution backlog. Design tokens, transparency metadata, live-region contracts, PR governance, and plain-language copy work have been completed and are covered by regression suites to reduce backslide risk.
Audit Cadence
Accessibility audits run on a quarterly cadence. Each audit window includes strict automated route checks, manual keyboard checks, and manual VoiceOver verification on core routes.
Each cycle results in tracked defects (when found), severity labels, owners, and a short summary of remaining risks.
Accessibility Defect Response Windows
Every verified accessibility defect is filed with a severity, owner, WCAG criterion, and due date at creation so the work stays operational rather than informal.
| Severity | Definition | Acknowledge | Fix or mitigation target | Owner | Escalation path |
|---|---|---|---|---|---|
| P0 | Release blocker or core task failure for keyboard or screen-reader use. | Same business day | 48 hours | Frontend Lead | Escalate to Engineering Lead if unresolved after 24 hours. |
| P1 | Major usability friction on important flows or important ARIA contract failure. | 1 business day | 10 business days | Accessibility Owner | Escalate to Frontend Lead if unresolved after 7 business days. |
| P2 | Localized issue, hardening work, or governance improvement. | 3 business days | Next planned cycle | Assigned at triage | Flag for quarterly audit close-out if deferred past two cycles. |
Key Accessibility Expectations
- Keyboard operation: Core tasks should be reachable without requiring a mouse.
- Clear structure: Headings, landmarks, labels, and status messages should make page behavior understandable.
- Readable presentation: Core audited routes should hold together under larger text sizes and tighter viewport widths.
- Safe navigation behavior: Productivity shortcuts should never interrupt active text entry or open dialogs.
- Direct feedback path: Users should be able to report barriers without hunting for the right channel.
How We Use ARIA
We do not treat ARIA as a replacement for semantic HTML. We use ARIA to clarify control names, relationships, descriptions, and status changes when native HTML alone is not enough.
That means our accessibility work is broader than ARIA usage alone. Keyboard behavior, headings, focus handling, contrast, reflow, and error recovery matter just as much.
Report Accessibility Issues
If something is hard to use or inaccessible, use the form below or go directly to the contact page. The form opens the secure contact flow with your summary and details carried over.
Helpful details include:
- What page or feature you were using
- What device, browser, or screen reader you were using
- What barrier you encountered and how it prevented you from completing your task
- How we can help you use PayCal
You can also use the general contact page if you prefer not to start from this form.
Standards and Guidelines
Our accessibility work is primarily guided by WCAG 2.1 and related legal standards that reference Level AA expectations.
- WCAG 2.1 (W3C Web Content Accessibility Guidelines) — International standard for web accessibility
- Section 508 (US Federal law) — Aligns with WCAG 2.0 Level AA
- EN 301 549 (European standard) — Aligns with WCAG 2.1 Level AA
- AODA (Accessibility for Ontarians with Disabilities Act) — References WCAG-aligned accessibility expectations in Canada
Continuous Practice
Accessibility is not a one-time cleanup. We treat it as part of normal product quality, the same way we treat correctness, security, and reliability.
As more routes are audited and covered, we keep updating this page with shipped changes, open work, and verification approach so it stays useful rather than generic.