Accessibility Statement

Our commitment

Accessibility matters to us, and we want Formatiq's tools to be usable by as many people as possible, including people using screen readers, keyboard-only navigation, or a preference for reduced motion. That said, we want to be upfront: this is an ongoing effort, not a finished state. We are not claiming full WCAG 2.1 AA or AAA compliance, and this page has not been through a formal accessibility audit or certification. What follows is an honest account of what's actually in place today and what isn't yet, so you know what to expect rather than reading aspirational marketing copy.

What's implemented so far

Based on what's actually in the codebase today:

  • Visible keyboard focus indicators are applied site-wide via a global :focus-visible style, so tabbing through the site shows a clear outline around the focused element.
  • Reduced motion is respected: a prefers-reduced-motion media query disables and shortens animations and transitions for users who've set that preference in their OS or browser.
  • Images that appear in tool output (like the image preview in the Base64 Image Converter) include descriptive alt text rather than being left blank.
  • Icon-only controls we've specifically checked - the theme toggle and the cookie consent dismiss button - have explicit aria-labels describing their action, not just a bare icon.

Known limitations

We'd rather list these plainly than let you discover them yourself:

  • Many of the calculator and generator tools (date pickers, number inputs, range sliders) use a visually-adjacent <label> next to the input rather than a programmatically associated label (via htmlFor/id or aria-label). Sighted mouse users see the label; screen reader users focusing the input directly may not hear it announced. This affects a meaningful number of tools and is the most significant gap we're aware of right now.
  • A few tools use hardcoded text colors for status indicators - for example, the Password Generator's strength label - that were chosen against the dark theme and haven't been individually verified for contrast against the light theme's white background. Most of the site's colors come from a shared token system that was checked across both themes, but these specific hardcoded values were not part of that system and may need adjusting.
  • No formal accessibility audit (automated tooling like axe, or manual screen reader testing) has been performed across the site's 50+ tools. What's listed above reflects a direct code review, not comprehensive testing, so there are likely other gaps we haven't found yet.

How to get help or report an issue

If you run into an accessibility barrier using any tool on this site, please get in touch - mentioning which tool (its category and slug from the URL) and what assistive technology or browser you were using helps us track it down faster.

Changes to this statement

As gaps are fixed or new ones are found, we'll update this page to reflect the current state rather than leaving outdated claims in place.

Last updated: August 6, 2026