Web Accessibility: How to Actually Get Started

I Turned On a Screen Reader and Felt Embarrassed

My interest in accessibility started simply. I stumbled on a presentation by a visually impaired developer, and watching them navigate the web with a screen reader was eye-opening. Curious, I turned on a screen reader on my own blog.

"Button." "Button." "Link." "Image." No indication of what anything actually did. The theme toggle was just "button." Post thumbnails with no alt text were just "image." I was embarrassed. So I started fixing things.

First Things First: Use the Right Tags

80% of accessibility is solved by using the right HTML tags. <button> instead of <div onClick>, <header> instead of <div class="header">, <nav> instead of <div class="nav">.

My blog had 7 clickable elements built with div. I replaced them all with button or a tags. That alone made keyboard navigation work. Tab to move, Enter to click. div doesn't give you this by default. The easiest accessibility improvement is "use the right tags," and the most common accessibility violation is "using the wrong tags."

Adding aria-label to Icon Buttons

Sometimes semantic HTML isn't enough. Icon-only buttons are the classic case. A moon icon for the theme toggle visually conveys meaning, but a screen reader just says "button."

Adding aria-label="Toggle dark mode" makes it read "Toggle dark mode, button." Search icon gets "Open search," close icon gets "Close." Adding aria-labels to all icon buttons took 20 minutes. Twenty minutes. (Which makes you wonder why I hadn't done it until now.)

Focus Was Escaping My Search Modal

Users who can't use a mouse rely on Tab, Enter, and Escape. I found a problem with my search modal: with the modal open, pressing Tab sent focus outside the modal. While a modal is open, focus should stay trapped inside it. That's called a "focus trap."

I implemented the focus trap, made Escape close the modal, and ensured focus returns to its original position when the modal closes. These three things alone dramatically improve the keyboard user's modal experience.

My Color Contrast Was Below Standard

Per WCAG guidelines, regular text needs a contrast ratio of at least 4.5:1 against its background. I checked in Chrome DevTools Color Picker and my gray text (#999999) against a white background had a ratio of 2.85:1. Below standard. Changing to #666666 brought it to 4.48:1 -- passing. A subtle color difference, but for users with low vision, it's the difference between readable and not.

I Ran Automated Testing Tools

I installed the axe DevTools browser extension and ran it. 23 violations. Fixing them one by one took two days. I also set up ESLint's eslint-plugin-jsx-a11y to prevent new violations in future code. But automated tools can't catch everything -- you really need to use a screen reader yourself to see the real problems.

You Don't Have to Be Perfect to Start

Accessibility isn't "do it perfectly or not at all." If you aim for 100%, you'll never start. One alt text today, one aria-label tomorrow. That alone improves someone's experience.

I'm not perfect either. But when a screen reader reads my blog and says "Toggle dark mode button, Open search button, React 19 post link" instead of "button, button, button" -- that's meaningful progress. "Starting is half the battle" is genuinely true here.