Accessibility Statement

We are committed to making Stopwatch.now usable by everyone, including people with disabilities. This statement explains what we've built, what we know needs improvement, and how to reach us if something isn't working for you.

Our Commitment

Stopwatch.now aims to conform to the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA. These internationally recognised guidelines, published by the W3C Web Accessibility Initiative, define how to make web content accessible to people with a wide range of disabilities - including visual, auditory, physical, cognitive, and neurological differences.

We consider accessibility a core product requirement, not an afterthought. Our goal is for every timer, clock, and tool on the site to be operable without a mouse, comprehensible with a screen reader, and perceptible at high zoom levels. Where we fall short, we want to know - see the contact page to report any issues.

This statement was last reviewed in January 2024. We review it whenever we make significant changes to the site and aim to re-audit annually against the WCAG checklist.

Accessibility Features We Have Implemented

The table below summarises the key accessibility features on Stopwatch.now, their current implementation status, and relevant notes. For help using any of these features, visit the Help Centre.

Feature Status Notes
Keyboard navigation Implemented All interactive elements (buttons, links, inputs) are reachable via the Tab key. Logical focus order follows the visual reading flow.
Timer keyboard shortcuts Implemented Space bar starts and pauses timers; R resets; L records a lap split. Shortcuts are documented in the Help Centre.
Visible focus indicators Implemented A high-contrast focus ring (blue outline, 3px minimum width) is visible on all focusable elements. We do not suppress the default focus outline.
ARIA labels and roles Implemented Timer controls carry aria-label attributes. Timer displays use aria-live="polite" so screen readers announce changes without interrupting speech.
Semantic HTML Implemented We use appropriate elements: <button> for actions, <nav> for navigation, <main> for main content, <h1>–<h3> in logical hierarchy. No div-soup.
Colour contrast (text) Implemented All body text meets 4.5:1 contrast ratio against its background. Large text (18pt+ or 14pt+ bold) meets 3:1. Tested in both light and dark modes.
Colour not used alone Implemented Colour is never the only means of conveying information. Status indicators use icons and labels alongside colour.
Text resizing to 200% Implemented The layout reflows correctly when browser font size is increased to 200%. No content is clipped or lost. Tested in Chrome and Firefox.
Reduced motion support Implemented We honour the prefers-reduced-motion media query. All CSS transitions and animations are disabled when the user has chosen "Reduce Motion" in their OS.
Screen reader announcements for timer Implemented Countdown completion is announced via aria-live. The running timer digits update in a live region at a rate that avoids overwhelming screen reader users.
Skip navigation link Implemented A "Skip to main content" link appears as the first focusable element on every page, allowing keyboard and screen reader users to bypass the navigation bar.
Form labels Implemented Every form input has an explicit <label> element associated via the for/id pairing. Placeholder text is not used as a substitute for labels.
Canvas-based timers (visual only) Partial Sand timers and spinner wheels rendered on <canvas> have a text-based equivalent displayed simultaneously. The canvas element carries aria-hidden="true" to avoid confusing screen readers.
Audio alerts Implemented Timer completion alerts are both audible and visual (a flashing border). Volume can be controlled or muted. Visual-only mode is available for users who cannot hear audio.
Touch target sizes Implemented All tap targets are at least 44×44 CSS pixels, meeting WCAG 2.5.5 (AAA). Timer control buttons are larger: 56×56px minimum.

Keyboard Shortcuts Reference

Most timer pages support keyboard control so you can operate them hands-free or without a mouse. Here is the full list of shortcuts available on supported pages:

  • Space - Start or pause the current timer
  • R - Reset the timer to its starting value
  • L - Record a lap (on stopwatch pages)
  • F - Toggle fullscreen mode
  • M - Toggle audio mute
  • + / − - Increase or decrease countdown time by 1 minute (on countdown timer pages)

Keyboard shortcuts do not fire when focus is inside a text input or form field, to avoid accidental interactions.

Known Limitations

We aim for WCAG 2.1 AA compliance, but we are aware of the following limitations and are actively working to resolve them:

Canvas-based visual timers

Some specialty timers - including the sand timer, spinner wheel, and analogue clock face - are rendered on HTML canvas elements. Canvas content is inherently inaccessible to assistive technologies. Our mitigation is to always display a text-based equivalent alongside the canvas (for example, a digital readout next to the sand timer). The canvas itself carries aria-hidden="true" to prevent it from confusing screen readers. We are evaluating SVG-based alternatives that would be more inherently accessible.

Complex spin wheel animations

The spin wheel (random name picker) involves rapid spinning animation that may cause issues for users with vestibular disorders, even with reduced-motion mode enabled. We are working on a "results-only" mode that skips animation entirely and shows the result instantly.

Third-party font loading

On very slow connections, Google Fonts may not load before the page renders, causing a brief flash of system fonts. This is a cosmetic issue only and does not affect functionality or screen reader compatibility.

Compatibility

We test Stopwatch.now for accessibility using the following combinations of assistive technologies and browsers:

  • NVDA + Firefox (Windows) - primary screen reader test environment
  • VoiceOver + Safari (macOS and iOS) - tested for mobile and desktop use
  • JAWS + Chrome (Windows) - tested for enterprise environments
  • TalkBack + Chrome (Android) - tested for mobile Android users
  • Keyboard-only navigation (Chrome, Firefox, Safari) - tested without any pointing device
  • Windows High Contrast Mode - verified that all UI elements remain distinguishable

We use automated checking tools (axe-core and Lighthouse) as part of our development process, but we supplement these with manual testing because automated tools only detect a subset of accessibility issues.

Requesting Accessible Formats

If you need content from Stopwatch.now in an alternative format - for example, a plain-text version of a help article, or a high-contrast version of a specific tool - please contact us with your request. We aim to fulfil reasonable format requests within 10 business days.

For users who need a simplified interface, all timer tools have a "fullscreen" mode that strips away navigation, sidebars, and other page chrome, leaving only the timer display and core controls. This can significantly reduce cognitive load. Access it by pressing F on any timer page.

Reporting Accessibility Issues

If you encounter an accessibility barrier on Stopwatch.now - something you cannot access, navigate, or understand - please tell us. We take every report seriously.

How to report:

  • Use the contact form and select "Accessibility" as the subject.
  • Email [email protected] directly.
  • Include: the URL of the page where you encountered the issue, the assistive technology you are using (if any), your browser and operating system, and a description of what is not working.

We aim to acknowledge all accessibility reports within 2 business days and provide a resolution timeline within 5 business days. For issues that require significant development work, we will explain our planned fix and estimated timeline.

External Resources

The following external resources are useful for learning more about web accessibility:

To learn more about who we are and our values, visit our About page. For help using specific tools, visit the Help Centre.

Accessibility Roadmap

The following improvements are on our accessibility roadmap. We list them here to be transparent about where we are and where we are going.

  • SVG-based visual timers - replacing canvas-based sand timers and spinner wheels with SVG implementations that are natively accessible to screen readers. Estimated: Q3 2024.
  • Results-only mode for spin wheel - an option to skip the spinning animation and display the result immediately, eliminating vestibular risk for users sensitive to motion. Estimated: Q2 2024.
  • Internationalised keyboard shortcut documentation - the Help Centre shortcut guide is currently English-only. We plan to provide it in additional languages as we expand regional support.
  • Enhanced screen reader timer verbosity options - allowing screen reader users to choose how frequently the running timer is announced (e.g. every 10 seconds vs every minute) to reduce audio interruption.
  • Formal third-party WCAG audit - we plan to commission an independent accessibility audit from a specialist firm in 2024 and publish the results publicly.

If any of these planned improvements are particularly important to you, or if you have an accessibility need we have not mentioned, please let us know. User feedback directly influences our prioritisation.

Our Accessibility Testing Process

New features and pages go through the following accessibility checks before they are published:

  1. Automated scan using axe-core (integrated into our development environment) to catch common WCAG violations early.
  2. Keyboard walkthrough - a developer navigates the feature using only Tab, Shift+Tab, Enter, Space, and arrow keys to verify all interactions are reachable and operable.
  3. Screen reader spot-check using NVDA+Firefox on Windows or VoiceOver+Safari on macOS to verify that the semantic structure and announcements make sense.
  4. Colour contrast verification using a contrast checker tool for all new colour combinations.
  5. Zoom test at 200% browser zoom to ensure no content overflows or becomes inaccessible.

This process catches the majority of issues before they reach users. For issues that slip through, our reporting process is always open.