Designing for Accessibility: Practical Tips

Accessibility Is Design Quality

Accessibility is not a separate checklist you tackle at the end of a project. It is a dimension of design quality, like visual polish or interaction fluidity. When I design with accessibility in mind from the start, the result is better for everyone — not just users with disabilities.

Here are the practices I have integrated into my daily design workflow.

Color Contrast

Color contrast is the most visible accessibility requirement and one of the easiest to get right.

The Rules

• Normal text (under 18px or 14px bold): minimum contrast ratio of 4.5:1 against its background (WCAG AA)
• Large text (18px+ or 14px+ bold): minimum ratio of 3:1
• UI components and graphical objects: minimum ratio of 3:1 against adjacent colors

How I Apply This

I check contrast as I design, not after. The Stark plugin in Figma gives me instant contrast ratios when I select a text layer. If a color combination fails, I adjust it immediately rather than flagging it for later.

A common trap is designing with gray placeholder text that passes contrast on a white background but fails on the light gray card backgrounds used elsewhere in the product. I check every text/background combination that actually occurs in the UI, not just the ideal case.

For dark mode, contrast requirements still apply — and they are harder to meet because designers tend to use low-contrast color combinations for aesthetic subtlety. I have learned that a dark theme that looks moody in Figma can be genuinely unreadable on a low-quality laptop screen in a bright room.

Beyond Compliance

Meeting WCAG minimums is the floor, not the ceiling. I aim for AAA compliance (7:1 for normal text) for body copy and primary content. Users with moderately low vision, older adults, and anyone reading on a phone in sunlight benefit from the extra contrast headroom.

Typography Sizing

Minimum Sizes

• Body text: never smaller than 16px. This is the browser default for a reason. Going smaller forces users to zoom, which can break layouts.
• Secondary text: 14px minimum, and only for supporting content like captions, timestamps, or metadata.
• Interactive labels: buttons, links, and form labels stay at 14px or above.

Line Height and Line Length

Readable typography is not just about size:

• Line height: 1.5 for body text, 1.3 for headings. Tight line height causes lines to visually merge for users with dyslexia or cognitive disabilities.
• Line length: 50-75 characters per line. I set max-width on text containers to enforce this. Long lines cause readers to lose their place when scanning back to the start of the next line.
• Paragraph spacing: at least 1.5 times the font size between paragraphs. Walls of text with no visual breathing room are hostile to everyone.

Allowing User Customization

I design layouts that accommodate browser zoom up to 200% without horizontal scrolling or content overlap. This means using relative units (rem, em) instead of fixed pixels and building flexible layouts that reflow gracefully.

Focus States

Focus states are the visual indicator that tells keyboard users where they are on the page. Removing or hiding them is one of the most common — and most harmful — accessibility mistakes.

Design Principles for Focus

• Make focus visible on every interactive element. Buttons, links, inputs, checkboxes, dropdowns, tabs — if it is clickable or tappable, it needs a clear focus indicator.
• Use a 2px or 3px offset outline. The outline should have enough contrast against both the element and the background. I typically use a solid ring with a slight offset: outline: 2px solid #2563EB; outline-offset: 2px;
• Do not use only color change. A button that turns slightly darker on focus is insufficient. The focus indicator must be visible to users who cannot perceive color differences.
• Test in both light and dark themes. A blue focus ring that works on a white background may be invisible on a dark blue header.

Focus Order

The tab order should follow the visual reading order: left to right, top to bottom. When elements are positioned with CSS in a different order than they appear in the DOM, keyboard users will experience a confusing jump sequence. I flag DOM-order mismatches during design reviews.

Screen Reader Considerations

Designing for screen readers means thinking about the non-visual experience of your interface.

Headings as Structure

Screen reader users navigate by headings the way sighted users scan visually. I ensure every page has:

• One h1 that describes the page purpose
• Logical heading hierarchy — no skipping from h2 to h4
• Descriptive heading text — "Account Settings" not "Settings" when there are multiple settings sections

Meaningful Labels

Every form input needs a visible label. Placeholder text is not a label — it disappears when the user starts typing and is not reliably announced by screen readers.

For icon-only buttons (like a close button or hamburger menu), I specify an aria-label in the design annotation: "Close dialog" or "Open navigation menu." The icon is not enough.

Image Alt Text

I write alt text suggestions in my design annotations for any meaningful image. The guideline I follow:

• Decorative images: empty alt (alt="") — do not describe them; they add noise
• Informational images: describe the content, not the appearance. "Revenue chart showing 23% growth in Q3" not "A bar chart with blue bars"
• Functional images (linked logos, image buttons): describe the action. "Homepage" for a linked logo

WCAG as a Framework

I design against WCAG 2.2 AA as the baseline. The guidelines are organized around four principles that I find genuinely useful as a design thinking tool:

• Perceivable: Can users perceive the information? (contrast, alt text, captions)
• Operable: Can users operate the interface? (keyboard access, timing, seizure prevention)
• Understandable: Can users understand the content and interface behavior? (consistent navigation, error identification, readable text)
• Robust: Does the interface work with assistive technologies? (valid markup, ARIA usage)

When I am evaluating a design decision, I run through these four questions. They catch issues that I might miss by focusing only on visual design.

Making It Stick

The biggest challenge with accessibility is consistency. It is easy to check contrast on one screen and forget on the next. I have built accessibility checks into my design process at three points:

1. During design: using Stark and checking focus states as I build components
2. During review: running a heuristic evaluation against WCAG criteria before handoff
3. During QA: testing with keyboard navigation and VoiceOver before sign-off

Accessibility is not extra work — it is the work. A product that only works for some users is an incomplete product.