Skip to content
Codexa

Trust

Accessibility

Our aim is for Codexa to be usable by everyone, including people who rely on keyboards, screen readers, or high contrast. This page lists the commitments we build to and the gaps we know about.

Last revised

What we build to

  • Semantic HTML with one h1 per page and a logical heading order.
  • Every form control has a visible label; errors are announced and linked to the field.
  • Keyboard operability: menus, dialogs, accordions, and the mobile navigation can be opened, used, and closed with Tab, Enter, Space, Arrow keys, and Escape.
  • Visible focus indicators and a skip-to-content link on every page.
  • Colour is never the only carrier of meaning; status dots and badges include text.
  • Light and dark themes with contrast targeting WCAG 2.2 AA for body text.
  • Layouts that work down to 360px wide without horizontal scrolling.
  • Reduced-motion preferences are respected for animations.

Known gaps

  • The Monaco code editor has its own accessibility model; some features (for example diff navigation) are harder with a screen reader than in a desktop editor.
  • The live preview iframe shows your application; its accessibility depends on the code in your project.
  • The file explorer tree does not yet implement full type-ahead navigation.
  • We have not yet commissioned a third-party accessibility audit.
  • Not all interface previews on marketing pages have long descriptions.

Tell us about a problem

If something is hard or impossible to use, please report it with the page and the assistive technology you were using, or email support@codexa.app. Accessibility reports are treated as bugs, not feature requests.