Accessibility isn't just about compliance. It's about building software that works for everyone. Here are the changes that have the biggest impact.
Web accessibility (a11y) has a reputation for being complicated and expensive. In practice, 80% of accessibility issues can be fixed with a handful of straightforward changes. And the benefits extend beyond compliance - accessible software is usually more usable for everyone.
The highest-impact changes
- Semantic HTML: use button for buttons, a for links, heading tags for headings. Most screen reader issues come from divs pretending to be interactive elements
- Alt text on images: describe what the image shows, not what it is ("Graph showing 40% growth" not "chart.png")
- Keyboard navigation: every interactive element should be reachable and usable with a keyboard alone
- Color contrast: text should have a contrast ratio of at least 4.5:1 against its background
- Form labels: every input needs a visible label element associated with it via htmlFor
Testing accessibility
Install the axe browser extension and run it on your pages. It catches the most common issues automatically. Then tab through your interface with the keyboard - can you reach everything? Can you see where focus is? Finally, try your app with a screen reader (VoiceOver on Mac, NVDA on Windows) for five minutes. You'll find issues you never noticed.
Don't add ARIA unless you need it
The first rule of ARIA is: don't use ARIA if native HTML does the job. A native button element is accessible by default. A div with role="button" needs additional keyboard handling, focus management, and ARIA attributes. Use semantic HTML first, ARIA only to fill gaps.
Ben Arledge
CEO & CTO, CloudOwlHave a project in mind?
No sales pitch, just an honest conversation about what you're building.