Accessibility

What we target

WCAG 2.2 Level AA, across the whole site including the interactive components. The same bar applies to the emails we send. This also covers our posture under the European Accessibility Act.

What that means in practice

• Every interactive control is reachable and operable by keyboard alone.
• Focus is always visible, and never trapped or stolen.
• Text meets AA contrast in both light and dark mode, which are equally supported.
• Headings describe the structure of the page rather than its styling.
• Images carry alt text, and decorative ones are hidden from screen readers.
• Status messages are announced politely rather than interrupting.
• Nothing depends on colour alone, on hover alone, or on a pointing device.
• Motion respects your reduced-motion setting.
• The site works at 200% zoom and reflows to a narrow viewport without a side-scroll.

Automated accessibility checks run in our build pipeline against every UI component, and a build that introduces a violation fails.

Known gaps

Stated plainly, because a conformance claim with no exceptions is one nobody can act on.

• The code editor and challenge runner are best on a desktop. Code stays readable and runnable on a phone and editing works, but the experience is genuinely better with a keyboard and a larger screen, and we say so in the interface.
• Automated checks are not a person. They catch contrast, names and roles; they do not catch a confusing tab order or a label that is technically present and practically useless. If you hit one, tell us — that report is worth more than another audit.

Tell us when something is unusable

Write to privacy@theroadtodev.com and describe what you were trying to do, what happened, and what you were using — a browser and screen-reader combination if you know it. We would rather have a rough description than none.

We aim to reply within 30 days and to say either when it will be fixed or why it will not be.