json:yaml

Accessibility statement

This accessibility statement covers our WCAG 2.2 level AA target: how the site is tested, what still has rough edges, and how to tell us if something does not work for you.

Effective 1 August 2026. Last updated .

Our commitment

json-yaml.com should be usable by everyone, including people who navigate by keyboard, use a screen reader, magnify the page, or rely on high-contrast or reduced-motion settings. A developer tool that only works for people using a mouse and 20/20 vision is a broken tool.

This statement describes how accessible the site currently is, how we know, and what to do if you hit a barrier.

Conformance status

This site is designed to conform to the Web Content Accessibility Guidelines (WCAG) 2.2 at level AA. Based on our testing, we believe it is fully conformant with WCAG 2.2 level AA, meaning we are not aware of any content that fails to meet it.

"Believe" is doing real work in that sentence. Automated testing catches a meaningful share of failures, not all of them, and we have not yet commissioned an independent audit or user testing with assistive technology. If you find something that does not work, we want to hear about it — see below.

How we test

Every page is checked automatically before release. The build fails if any of these regress:

  • axe-core runs against every page at both mobile and desktop widths, covering the WCAG 2.0, 2.1 and 2.2 A and AA rule sets. Last run returned zero violations.
  • Colour contrast is computed numerically for every text and background pair rather than judged by eye. All body text meets at least 4.5:1; several combinations were darkened after testing showed them at 4.37:1, which looks fine and is not.
  • Target size is measured on every interactive element at ten viewport widths. On touch devices, controls are at least 44 by 44 CSS pixels, which exceeds the 24-pixel minimum WCAG 2.2 requires.
  • Reflow is verified at every width from 320 pixels upward, with a check that no page scrolls horizontally.

We also test manually: navigating each page by keyboard alone, and confirming the converters work with the browser zoomed to 200%.

What we have done

  • Keyboard access throughout. Every control, including the code editors and the horizontally scrollable code samples and tables, is reachable and operable by keyboard. Focus is always visible.
  • A skip link at the top of every page jumps straight to the converter.
  • Semantic structure. One h1 per page, headings in order, real landmarks, and table headers marked up with scope so screen readers announce the right column.
  • Live status announcements. The converter's result area is a live region, so a screen reader announces whether your document was valid and what the error was, without you having to go looking for it.
  • Labelled controls. Both editors carry accessible names, and the scrollable regions announce that they scroll.
  • Errors described in words. Validation results are never conveyed by colour alone — the status text states the problem, and the line and column.
  • Reduced motion respected. If your system asks for less motion, we remove transitions.
  • Reflow to 320 pixels with no horizontal scrolling, and no loss of content when text is enlarged.
  • No time limits, no auto-playing media, and nothing that flashes.

Known limitations

Being honest about the edges matters more than a clean claim.

  • The code editors are plain text areas. They are fully usable by keyboard and screen reader, but they do not provide the structured navigation a dedicated code editor would, such as jumping to a line by number.
  • Long documents are read linearly. A screen reader will read a converted 500-line file from the top; there is no outline navigation within the output pane.
  • Line numbers are visual. They are hidden from screen readers to avoid reading a wall of digits. Error messages state the line number in the text instead, which is the accessible route to the same information.
  • JavaScript is required for the converters. The reference documentation is plain HTML and works without it.
  • No independent audit yet. Our conformance claim rests on our own automated and manual testing.

Feedback and how to report a problem

If you cannot use part of this site, please tell us at contact@json-yaml.com. Include the page, what you were trying to do, and what assistive technology, browser, and operating system you were using if you can. We aim to reply within five working days.

Accessibility reports go to the front of the queue. If something is unusable for you, that is a defect, not a feature request.

If you are not satisfied with our response, you may contact the enforcement body in your jurisdiction. In the United Kingdom that is the Equality Advisory and Support Service; in the European Union, the national authority designated under the European Accessibility Act in your member state.

About this statement

This statement was prepared on 31 August 2026. It is based on automated testing with axe-core across all pages and manual keyboard and zoom testing, both carried out on that date by json-yaml.com.

We re-run the automated tests on every change to the site, and review this statement whenever a result changes.