Skip to main content
viewmygpx

Accessibility statement

viewmygpx aims to be usable by everyone, including people who use screen readers, keyboard-only navigation, voice control, magnifiers, or reduced-motion preferences. The site targets WCAG 2.1 Level AA and we test against that standard as we build. This page documents what we have done, what we know does not work yet, and how to tell us about problems we have not caught.

Standard we follow

Our reference is the W3C's Web Content Accessibility Guidelines (WCAG) version 2.1, Level AA. WCAG covers four principles: perceivable, operable, understandable, and robust. The Level AA conformance target is what most accessibility law (the European Accessibility Act, the US Section 508, the UK Public Sector Bodies regulations) treats as the practical bar.

We are not certified or audited by an outside body. The statement here describes our practice; we welcome reports if it falls short.

What we have done

Concrete accessibility practices we apply across the site:

  • Semantic HTML. Headings are real <h1>–<h6> elements, lists are <ul>/<ol>, navigation is in <nav>, the main content is in <main>. Screen readers can navigate the document by landmark and by heading.
  • Keyboard support. Every interactive control — dropzone, buttons, accordions, sliders, links — is reachable and operable with the keyboard. The dropzone responds to Enter and Space; range sliders to arrow keys; FAQ accordions to Enter.
  • Visible focus. A clear focus ring appears on every focusable element when navigating by keyboard. The default browser outline is replaced with a 2-pixel trail-green ring with offset, scoped via :focus-visible so it does not appear on mouse clicks.
  • Color contrast. Body text is dark ink on light paper at a measured contrast ratio above 7:1 (WCAG AAA). Muted graphite text on paper is above 4.5:1 (AA). The trail-green accent on paper passes AA for normal text.
  • Alt text and ARIA. Decorative SVGs are marked aria-hidden="true"; informational SVGs (the elevation profile chart) carry role="img" with an aria-label summarizing the data. Inputs have associated labels; the dropzone has aria-labelledby and aria-describedby.
  • Skip link. A visually-hidden "skip to main content" link appears as the first focusable element on every page so keyboard users can bypass the header.
  • Reduced motion. The CSS respects prefers-reduced-motion: animations and transitions are disabled when the system preference is set. Hover lifts and decorations remain functional but do not animate.
  • Screen-reader summaries. The elevation profile and stats panel include text equivalents (in aria-label and visible alternate text) so non-visual users get the same information the visual chart conveys.
  • Page language. The document declares lang="en" so screen readers select the right pronunciation profile.
  • Resilient under zoom. The layout reflows cleanly up to 400% browser zoom without horizontal scrolling on the main content column.

How we test

We rely on a few standard tools and habits during development:

  • Lighthouse automated accessibility audits in Chrome DevTools. We aim for a score of 100 on every page; the score is not a substitute for actual usability, but it catches obvious regressions.
  • Keyboard-only navigation. We tab through every page and every interactive surface to confirm that everything is reachable and that focus order matches reading order.
  • Reduced-motion checks. System preference toggled on to confirm animations and transitions are respected.
  • Browser zoom and reflow. Confirm that the layout works at 200% and 400% zoom without hiding or breaking content.
  • Screen-reader spot checks. VoiceOver on macOS and iOS for sample pages and critical interactions.

Known limitations

We have not solved everything. The areas where the site is weaker:

  • The interactive map. The viewer renders the route on a Leaflet map. Leaflet is a community library that exposes basic ARIA semantics but is not a fully accessible map widget; panning, zooming, and exploring features by keyboard alone is limited. The route polyline is the main affordance — the map is not the only place the route information appears (the elevation profile and the stats panel cover most of the same data).
  • Complex SVG charts. The elevation profile is a single SVG path with axis labels. We provide a summary via aria-label, but a screen-reader user cannot point-by-point trace the chart the way a sighted user can.
  • Color as a signal. Where we use color to indicate state (dropzone hover, sample dragging, error messages), the state is also reflected in text or shape so the page does not rely on color alone.
  • Dynamic announcements. Loading states are announced via aria-live, but the announcement coverage is not exhaustive across every interaction.

How to report an issue

If you hit an accessibility problem on viewmygpx — anything from a focus order that jumps around to a control you cannot reach with the keyboard — please tell us. Email hello@viewmygpx.com with the word "accessibility" in the subject. Helpful details: the URL, what you were trying to do, what assistive technology you were using (browser, screen reader, etc.), and what went wrong.

We are a small group, not an accessibility team, but accessibility regressions are treated as bugs and addressed alongside other functional issues.