You know what’s wild? A lot of developers still use <div>s for everything. Buttons? Divs. Navigation? Divs. Headings? You guessed it—divs with custom classes. That’s like building a house with only bricks and no doors. Sure, it stands. But try getting in or out.
Semantic HTML is your foundation. Use <nav> for navigation. <button> for buttons. <h1> through <h6> for headings. Screen readers rely on this structure. So do keyboard users. And honestly? It makes your code cleaner, too.
Key takeaway: If you can’t navigate your app with just a keyboard, you’ve already failed the accessibility-first test. Start with semantics.
Real-world example: The “Skip to content” link
This little pattern is a lifesaver. It’s a hidden link that appears when you tab to it, letting keyboard users bypass repetitive navigation. Simple, right? But you’d be shocked how many apps skip it. Including it is a no-brainer. It’s like putting a fast-pass lane at an amusement park.
Pattern 2: Color contrast that doesn’t hurt
Let’s talk about color. Not the pretty kind—the functional kind. Accessibility-first means ensuring text has enough contrast against its background. WCAG guidelines recommend a ratio of at least 4.5:1 for normal text. That’s not a suggestion. It’s a rule.
But here’s a quirk: don’t rely solely on color to convey information. Ever seen a form where required fields are marked only in red? That’s a problem for colorblind users. Add an asterisk or a text label. It’s that simple.
Quick tip: Use tools like the WebAIM contrast checker. Or just squint at your screen. If it feels hard to read, it probably is.
When gradients get in the way
Gradients are trendy. I get it. But they can mess with contrast, especially over text. If you’re using a gradient background, test it at multiple points. Better yet, put a solid overlay behind the text. Your users’ eyes will thank you.
Pattern 3: Focus indicators—make them visible
This one drives me nuts. Some designers remove the default focus outline (that blue glow around links) because it looks “ugly.” Then they forget to add a custom one. Suddenly, keyboard users have no idea where they are on the page. It’s like turning off the lights in a maze.
Accessibility-first means designing focus states that are more visible, not less. Use a thick outline, a color change, or even a subtle animation. Just make sure it’s obvious.
Pro tip: Test your focus states by tabbing through your entire app. If you ever lose your place, you’ve got work to do.
Pattern 4: Keyboard navigation that flows
Alright, let’s get tactical. Keyboard navigation isn’t just about tabbing. It’s about logical order. Your tabindex should follow the visual layout—left to right, top to bottom. Don’t jump around. And please, for the love of all things usable, avoid tabindex values above 0 unless you really know what you’re doing.
Here’s a quick table to clarify common keyboard patterns:
| Element | Expected keyboard behavior |
|---|---|
| Links | Enter to activate |
| Buttons | Enter or Space to activate |
| Dropdowns | Arrow keys to navigate, Escape to close |
| Checkboxes | Space to toggle |
| Sliders | Arrow keys to adjust |
See? It’s not rocket science. It’s just… consistency. Users expect certain things to work certain ways. Don’t surprise them.
What about custom widgets?
Custom widgets—like date pickers or drag-and-drop lists—are tricky. They often break keyboard navigation. The fix? Use ARIA roles and properties. For example, role="slider" with aria-valuenow and aria-valuemin. But honestly? If you can use a native HTML element, do it. It’s already accessible.
Pattern 5: Screen reader-friendly content
Screen readers are like picky eaters. They need things served a certain way. Use aria-label for icons without text. Use aria-describedby for extra context. And for images? Alt text should describe the content, not just say “image.”
But here’s a nuance: don’t over-announce. If a button already says “Submit,” you don’t need aria-label="Submit button". That’s redundant. Screen readers will say “Submit, button” on their own. Let them do their job.
Heads up: Live regions are your friend for dynamic content. Use aria-live="polite" for updates that aren’t urgent. It’s like whispering, not shouting.
Pattern 6: Responsive and zoom-friendly layouts
Accessibility isn’t just about screen readers. It’s about how content behaves when you zoom in to 200%. Or when you rotate your phone. Or when you use a tablet with a split screen.
Design with relative units (like rem or em) instead of fixed pixels. That way, text scales properly. And avoid horizontal scrolling at all costs. It’s a nightmare for users with low vision or motor impairments.
Think of it like this: your layout should be like water—it adapts to its container. Not like concrete—which cracks when you try to move it.
Pattern 7: Error messages that actually help
We’ve all seen those error messages: “Invalid input.” Thanks. That tells me nothing. Accessibility-first means error messages that are specific. “Your email address is missing the ‘@’ symbol.” Now that’s helpful.
Also, associate errors with their inputs using aria-describedby. That way, screen readers announce the error when the user tabs to the field. It’s like having a friendly assistant tapping you on the shoulder.
Bonus pattern: Use aria-invalid="true" on form fields with errors. It tells assistive tech that something’s wrong. Simple but powerful.
Pattern 8: Motion and animation with respect
Animations are cool. But they can trigger dizziness or nausea for people with vestibular disorders. Accessibility-first means respecting the prefers-reduced-motion media query. If a user has that setting enabled, tone down the animations. Or remove them entirely.
You know what’s even better? Let users control motion in your app’s settings. Give them a toggle. It’s a small gesture that shows you care.
Putting it all together—a quick checklist
- Use semantic HTML (headings, landmarks, buttons)
- Ensure color contrast meets WCAG AA (at least 4.5:1)
- Design visible focus indicators
- Test keyboard navigation end-to-end
- Write meaningful alt text and ARIA labels
- Use relative units for responsive scaling
- Provide specific, contextual error messages
- Respect user motion preferences
That’s it. No magic
