Our approach
The tools aim to satisfy WCAG 2.1 level AA in design and implementation: perceivable, operable, understandable and robust. Accessibility is treated as part of correctness: a timer you cannot hear finish, or a result a screen reader never announces, is a broken tool.
What the site does
- Keyboard operability: every control is reachable and usable by keyboard, with a visible focus style; timer keyboard shortcuts ignore keystrokes while you are typing in a field.
- Screen-reader announcements: results and timer state changes are announced through a polite live region; ticking displays are hidden from assistive tech (they would be noise), with an explicit “Announce…” button instead.
- Labels and structure: every input has a programmatic label; headings, landmarks and breadcrumb navigation give the pages a predictable shape.
- Contrast and themes: light and dark themes both meet contrast targets, and the theme follows your system preference.
- Reduced motion: progress-bar animation is disabled when your system requests reduced motion.
- Text zoom: layouts reflow to 200% zoom without loss of content or function.
Known limitations
-
Ticking clocks update once per second by design; they are marked
aria-hiddenso they do not spam screen readers. The trade-off is that the current time is available only through the “Announce current time” buttons; if you would prefer an always-live region, that is a legitimate accessibility consideration worth raising. - Audio chimes on timers are optional and off by default; completion is always announced as text as well.
- Long city lists in the current-time-by-city tool are tables; navigation within them relies on your screen reader’s table navigation.
Testing
Pages are checked for heading order, label coverage, focus visibility and live-region behavior during development. Accessibility issues found after launch are treated as bugs and fixed promptly. See About for how the project is run.