10 things that affect accessibility before the first line of code

Accessibility is often discussed at the code level: semantic HTML, ARIA attributes, keyboard navigation.

Many of the decisions that define whether a product is accessible happen much earlier. Before the first component is built or the first line of CSS is written, the team has already made choices that will support or compromise accessibility for every user of that product.

Here are 10 of those decisions, and why they matter before a developer opens their editor.

1. Color palette
   Contrast ratios are a design decision. When a palette is chosen without accessibility in mind, developers inherit a system that fails WCAG 1.4.3 from the start. If the palette defines minimum contrast ratios, every component built from it starts out accessible.

2. Typography scale
   Minimum font size, line-height and letter-spacing affect readability for users with low vision and cognitive disabilities. Setting these values up front avoids text that's legible on a designer's monitor but fails at real reading distances or with browser zoom.

3. Information hierarchy
   The heading structure of a page (h1, h2, h3) reflects the information architecture, which is defined at the wireframe stage. When the design leaves that structure unclear, developers guess, and screen reader users get a page that's hard or impossible to navigate by heading.

4. Interaction patterns
   Choosing between a modal, a dropdown, an accordion or an inline expansion has accessibility consequences. Each pattern has its own keyboard interaction requirements, focus management expectations and ARIA roles. Pick one without considering these and the implementation will be inaccessible or need heavy rework.

5. Error message content
   WCAG 3.3.1 requires errors to be identified and described in text, and WCAG 3.3.3 recommends suggesting how to correct them. Both depend on what the error message says, so they're content decisions. Writing error messages during design and content work, instead of leaving them for the code, makes compliance much easier.

6. Focus order
   A keyboard user should move through a page in a logical, predictable sequence. The layout sets that sequence, not CSS or JavaScript. When a design places elements in a visual order that doesn't match the content order, fixing focus order means restructuring the layout.

7. Minimum target size
   WCAG 2.5.8 (Target Size (Minimum), Level AA) requires interactive targets to be at least 24×24 CSS pixels, with exceptions for spacing and inline elements. Sizing is decided in the design, and adding it later in CSS usually disturbs the surrounding layout. Making minimum target size a design constraint prevents this whole class of failures before implementation begins.

8. Form labels and instructions
   Every form field needs a visible, meaningful label. Fields that rely only on placeholder text fail WCAG 1.3.1 and 3.3.2, because placeholder text disappears on focus and screen readers don't announce it consistently. When labels and instructions are written as part of the form design, they say something specific instead of something generic.

9. Link and button labels
   "Click here", "Read more" or "Submit" without context are accessible name failures. WCAG 2.4.6 and 2.4.9 require links and controls to have descriptive names, and those names come from content decisions: what does this button do, and where does this link go? When the design and content phase answers those questions, the implementation reflects the intent. When developers have to infer the answers, the result is often a generic label that tells a screen reader user nothing.

10. Component roles and semantics
    What a component is (a button, a navigation, a list, a dialog) determines which HTML element and ARIA role it should use. That's an architectural decision. When components are designed without a clear semantic role, developers must choose between the wrong element and complex ARIA that tries to compensate. Getting the role right starts with a clear design intent.

Accessibility doesn't belong to any one discipline. These decisions happen across design, content and architecture, and the earlier they're made with accessibility in mind, the cheaper they are to get right.

So, at what stage does accessibility enter the conversation on your projects?