LiveInternetSpeed

Trust & legal

Accessibility

We want anyone to be able to run a speed test and understand their results, regardless of how they browse the web.

Our commitment

Live Internet Speed is built to align with the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA across the site. That means every page — the speed test itself, your saved history, and every guide and legal page — is designed and built with keyboard access, screen readers, and low-vision users in mind from the start, not bolted on afterward.

Accessibility is a practice, not a one-time checkbox. We review new features against these guidelines before shipping them, and we treat accessibility bugs with the same priority as functional bugs.

What we've implemented

Concretely, today the site includes:

  • Full keyboard navigation. Every control — starting the test, viewing history, clearing history, navigating between pages — can be reached and operated using only a keyboard, in a logical focus order.
  • Visible focus indicators. Interactive elements show a clear, high-contrast focus outline so keyboard users always know where they are on the page.
  • Semantic headings and landmarks. Pages use proper heading hierarchy (h1/h2/h3) and landmark regions (header, main, nav, footer) so screen reader users can jump directly to the content they need.
  • Labeled buttons and forms. Every button, link, and form field has an accessible name — either visible text or an aria-label — so it makes sense out of visual context.
  • Throttled status announcements. While a test is running, we announce the current phase (for example, moving from download to upload) to screen readers via a polite live region. We deliberately throttle these announcements rather than reading out every rapidly changing Mbps number, which would otherwise flood a screen reader with noise and make the page unusable.
  • Text alternatives for meaningful graphics. Charts, gauges, and icons that convey information have text equivalents (labels, captions, or aria-describedby text) alongside them.
  • Sufficient color contrast. Text and interactive elements meet WCAG AA contrast ratios against their backgrounds, in both light and dark themes.
  • Results distinguishable without color alone. Speed classifications (for example, whether a connection is good enough for streaming or gaming) are conveyed with text and icons, not color alone, so they remain clear for colorblind users.
  • Respects reduced-motion preferences. If your operating system is set to prefers-reduced-motion, we scale back or remove non-essential animation, including gauge and progress animations during a test.
  • Adequate touch target sizes. Buttons and links are sized and spaced to be comfortably tappable on touchscreens, following WCAG 2.2's target-size guidance.
  • Responsive layout from 320px width up. The site remains usable and readable on small screens, down to a 320px viewport, without horizontal scrolling or lost content.
  • No keyboard traps. Focus always moves in and out of dialogs, menus, and other components predictably; you are never stuck unable to tab away from an element.
  • An accessible confirm dialog for clearing history. Clearing your saved test history opens a proper dialog with focus trapped inside it while open, a clear heading describing the action, and keyboard-operable confirm/cancel controls — so a destructive action is never triggered accidentally and is always clearly announced.

Known limitations

Accessibility work here is ongoing, and we don't claim perfection. Some parts of the experience — particularly the underlying browser-based measurement library that actually drives the download/upload transfers during a test — are third-party code rendered inside the page and are outside our direct control in terms of markup and behavior. We wrap and label these components as best we can from the outside, but we cannot guarantee they meet the same standard as code we author ourselves.

If you encounter a page, control, or result that doesn't work well with your assistive technology, we want to know about it and will prioritize fixing it — see our methodology page for how the test itself works, which can help clarify whether an issue is a display bug or an expected part of how measurement works.

Feedback

If you run into an accessibility barrier anywhere on Live Internet Speed, please tell us. Use the contact page or email hello@example-placeholder.com with a description of the issue, the page it occurred on, and the assistive technology or browser you were using. We read every report and use it to prioritize fixes.