Web Accessibility Basics: What Every Developer Should Do
A practical intro to web accessibility (a11y): what it is, why it matters, and the concrete things you can do today, semantic HTML, alt text, contrast and keyboard support.
- →Web accessibility (a11y) means building sites everyone can use, including people with disabilities.
- →Most accessibility comes free from semantic HTML, use the right element for the job.
- →Add descriptive alt text to meaningful images, and ensure text has enough color contrast.
- →Everything should work with a keyboard alone, not just a mouse.
- →WCAG is the standard; aim for level AA as a practical target.
Web accessibility, often shortened to a11y, means building websites that everyone can use, including people who navigate with a screen reader, a keyboard, or with low vision. It's the right thing to do, it's often a legal requirement, and it usually improves the experience for everyone. The good news: most of it is straightforward.
What is web accessibility?
Web accessibility is the practice of making websites usable by people with disabilities, visual, motor, auditory and cognitive. In practice that means a screen reader can understand your page, someone can operate everything with a keyboard, text is readable, and content isn't conveyed by color alone. The formal standard is WCAG (Web Content Accessibility Guidelines).
Start with semantic HTML
The single biggest win is using the correct HTML element for the job. Semantic HTML gives screen readers and browsers meaning for free, no extra work. A <button> is announced as a button and is keyboard-operable; a <div> pretending to be a button is neither.
<!-- Bad: a div faking a button -->
<div class="btn" onclick="submit()">Submit</div>
<!-- Good: a real button, accessible for free -->
<button type="submit">Submit</button>- •Use <button> for actions, <a> for navigation, not divs with click handlers.
- •Use headings (<h1>-<h6>) in order to structure the page.
- •Use <nav>, <main>, <header>, <footer> landmarks so screen readers can jump around.
- •Use <label> tied to every form input.
Give images alt text
Screen readers can't see images, they read the alt attribute. Describe what the image conveys. If an image is purely decorative, give it an empty alt (alt="") so it's skipped rather than announced as a filename.
<img src="/chart.png" alt="Revenue grew 40% from 2024 to 2026" />
<img src="/decoration.svg" alt="" />Ensure enough color contrast
Low-contrast text (light gray on white) is hard to read for many people. WCAG asks for a contrast ratio of at least 4.5:1 for normal text. Check yours with a contrast checker, and never rely on color alone to convey meaning (add an icon or label too).
Don't signal errors with red color alone, someone with color blindness may miss it. Pair the color with an icon and text like 'Error: email is required'.
Make everything keyboard-accessible
Many people can't use a mouse. Every interactive element must be reachable and operable with the keyboard alone, Tab to move, Enter/Space to activate. Semantic elements get this for free; custom widgets need care.
- 1.Test by unplugging your mouse and navigating with Tab, Enter and Space.
- 2.Ensure a visible focus outline, never remove it without a replacement.
- 3.Keep a logical tab order that follows the visual flow.
Use ARIA only when you must
ARIA attributes add accessibility information for custom components, but the first rule of ARIA is: don't use ARIA if a native element does the job. Reach for it only for things HTML can't express (like a custom tab panel), and test with a real screen reader.
No ARIA is better than bad ARIA. A plain <button> beats a <div role="button"> with three ARIA attributes almost every time.
How to check your accessibility
- •Run Lighthouse (in Chrome DevTools), it has an accessibility audit.
- •Try axe DevTools or WAVE for detailed issue reports.
- •Navigate your site with only the keyboard.
- •Test with a screen reader (VoiceOver on Mac, NVDA on Windows).
The short version
Web accessibility means everyone can use your site. Get most of the way there with semantic HTML, descriptive alt text, sufficient color contrast, and full keyboard support. Use ARIA sparingly, aim for WCAG level AA, and test with real tools. It's good practice, often a legal requirement, and it improves the experience for all users.
Frequently asked questions
What is web accessibility?+
Web accessibility (a11y) is the practice of building websites that people with disabilities can use, including those who rely on screen readers, keyboard navigation, or have low vision. It means your content is perceivable, operable and understandable for everyone, and it's measured against the WCAG standard.
How do I make a website accessible?+
Start with semantic HTML (use <button>, <a>, headings and landmarks correctly), add descriptive alt text to meaningful images, ensure text has enough color contrast, and make everything operable by keyboard alone. Use ARIA only when native HTML can't do the job, and test with tools like Lighthouse and a screen reader.
What is WCAG?+
WCAG stands for Web Content Accessibility Guidelines, the international standard for web accessibility. It defines success criteria at three levels: A, AA and AAA. For most sites, WCAG level AA is the practical target and is what many accessibility laws reference.
Why is semantic HTML important for accessibility?+
Semantic HTML gives elements built-in meaning that screen readers and browsers understand for free. A real <button> is announced as a button and works with the keyboard automatically, while a <div> styled as a button is neither. Using the right element is the single biggest accessibility win.
When should I use ARIA?+
Use ARIA only when native HTML can't express what you need, such as a custom tab panel or a live region. The first rule of ARIA is to prefer a native element if one exists, because incorrect ARIA can make things worse. Always test ARIA with a real screen reader.
I build fast, SEO-ready sites and rank them on Google and AI search.