Our accessibility standard

Accessibility is not a layer we can reliably add after the site has already decided what every element is. A clickable div does not become a good button because an ARIA label was added later. A heading hierarchy does not become coherent because the font sizes look right.

A modal does not become keyboard-friendly because it is visually centered. We try to start from the browser's native semantics and add complexity only where the interaction needs it.

Semantic HTML carries a lot of value for free

A link already knows how to be focused and activated. A button already communicates itself as an interactive control. A nav element identifies navigation. A main landmark identifies primary content. A heading gives the document a hierarchy. Using the correct element means the browser and assistive technology begin with more information.

It also means we have less custom behavior to recreate.

Our build checks some document semantics automatically

The connectrader post-build audit inspects generated pages for one primary H1, a main landmark, nonempty headings, and heading levels that do not skip unexpectedly. Those checks do not prove the page is accessible. They do protect basic document structure across a growing route library.

That is a good use of automation because the rules are deterministic.

Keyboard behavior is part of component behavior

Interactive components need to work without a mouse. One of our gallery components listens for arrow-key input. A gated modal listens for Escape so the user can close it. Mobile navigation components need controls that can receive focus and communicate expanded state.

These behaviors belong with the component, not in a separate "accessibility script."

Focus should not disappear

A control can technically be keyboard reachable and still be difficult to use if the focus state is invisible. We avoid removing native focus outlines without replacing them with a clear equivalent. A person navigating by keyboard should be able to tell where they are.

This matters especially in menus, forms, modals, and groups of repeated links.

Motion preferences are real user preferences

Several of our sites include prefers-reduced-motion rules. When reduced motion is requested, decorative reveals and transitions can be disabled while the content remains in its final visible state. That last part matters. Accessibility should not create a version of the page where content remains hidden because the animation that would reveal it was turned off.

Our animation philosophy is covered in Why we reach for browser-native behavior before animation libraries.

Mobile behavior is accessibility behavior

A page that overflows horizontally, clips a button, or puts a modal below unreachable browser chrome is not merely a responsive-design problem. It affects whether the interface can be used. This is why real-device and viewport QA matter. Touch targets need enough space.

Text needs to remain readable. The browser's dynamic viewport needs to be respected. A visually perfect desktop layout is not an accessible mobile experience by default.

Images need meaningful alternatives

Alt text should describe useful information conveyed by the image. It should not be a keyword field. A decorative image can have empty alt text when it adds no information. A project image may need a concise description of what the reader is expected to notice.

A logo can identify the organization when that context is useful. Our generated-page audit checks that rendered image tags include alt attributes. The human still has to decide whether the text is good.

Forms need labels and understandable errors

Placeholder text is not a substitute for a persistent label. Required controls should be identifiable. Consent language should be associated with the relevant input. Errors should be communicated in text and, when appropriate, through alert semantics. A user should not have to infer that a red border means their email failed validation.

Contrast is a design-system responsibility

Color contrast should not be solved one component at a time. Primary text colors, muted text, button states, backgrounds, links, and interactive states should be chosen as a system. This reduces the chance that a later page introduces unreadable combinations because the designer reached for an arbitrary gray.

Accessibility and performance often reinforce each other

Semantic HTML reduces the need for custom JavaScript. Server-rendered content is available earlier. Reduced-motion support can remove unnecessary animation work. Stable layouts help users with zoom and magnification. Simple, predictable interfaces often perform better for everyone.

Automation has limits

A scanner can find missing alt attributes. It cannot always tell whether the alt text is meaningful. It can identify a missing label. It cannot decide whether the form instructions are understandable. It can detect heading order. It cannot decide whether the content hierarchy makes sense.

We use automated checks to protect the obvious floor, then review actual interactions.

The standard is practical

We are not interested in accessibility as a badge. We are interested in whether the site can be perceived, navigated, understood, and operated by more people across real devices and input methods. That is an implementation quality question. It belongs in the engineering process from the start.