Accessibility gets treated as an advanced topic. It appears in “advanced web development” courses, as an afterthought in design systems, or as a compliance requirement for enterprise clients. This is backwards. Accessibility is basic web development. If your website doesn’t work for people using assistive technology, you’ve built it wrong.

The good news is that basic accessibility is straightforward. You don’t need to be an expert to build interfaces that work for everyone. You need to know a few principles, follow some simple rules, and test your work. Here’s what every developer should know.

Semantic HTML Is 80% of Accessibility

Most accessibility problems come from developers fighting HTML instead of using it correctly. Semantic HTML provides structure and meaning that assistive technology understands. Use the right elements and you get accessibility almost for free.

Buttons should be buttons. Not <div onclick="...">. Not <a href="#" onclick="...">. If it triggers an action, it’s a button: <button>. Buttons get keyboard focus automatically. They respond to Enter key presses. Screen readers announce them as buttons. Divs do none of this.

Links should be links. If it navigates somewhere, it’s a link: <a href="...">. Links and buttons are not interchangeable. They have different semantics and different keyboard interactions. Links navigate. Buttons act.

Headings should be headings. Not <div class="big-text">. Headings (<h1> through <h6>) create document structure that screen readers use for navigation. Users can jump between headings, building a mental model of page structure. Heading levels should be hierarchical—don’t skip from <h2> to <h5>.

Forms need proper markup. Every input needs a label: <label for="email">Email</label><input id="email" ...>. Related inputs should be in a <fieldset> with a <legend>. Required fields should be marked required. Error messages should be associated with their inputs using aria-describedby.

Lists should be lists. If you’re marking up a list of items, use <ul> or <ol>. Screen readers announce list length and current position, helping users understand structure. Navigation menus are lists. Article collections are lists. Sidebar links are lists.

The pattern is clear: HTML has elements for specific purposes. Use them. The alternative—generic divs and spans with classes—throws away all the accessibility information HTML provides.

Alt Text Is Required, Not Optional

Every image needs alt text. Not most images. Every image. The alt attribute is required in HTML for a reason.

Good alt text describes the image’s purpose in context:

• Informational images need descriptions: alt="Bar chart showing 40% revenue growth in Q4"
• Decorative images need empty alt: alt="" (this tells screen readers to skip the image)
• Functional images (logos that link, icons in buttons) need descriptions of function: alt="Home" or alt="Search"
• Complex images (charts, diagrams) need both alt text and longer descriptions, either in surrounding text or using aria-describedby

What doesn’t work:

• Missing alt text (image breaks accessibility)
• Alt text that just repeats the filename: alt="IMG_1234.jpg"
• Alt text that says “image of…” (screen readers already announce it’s an image)
• Alt text that’s a novel—keep it concise, under 150 characters if possible

Writing good alt text is a skill. You’re balancing between too little information and too much. Think about what’s essential for understanding the content, not describing every visual detail.

Keyboard Navigation Must Work

Many people navigate websites using only a keyboard. Some because they use assistive technology. Some because they find it faster. Some because of motor impairments that make mouse use difficult. Your site must work without a mouse.

Tab order should make sense. Pressing Tab moves through interactive elements in a logical order. This happens automatically if your HTML structure is logical. It breaks when you use CSS to reorder visual presentation or when you add tabindex incorrectly.

Focus indicators must be visible. That outline that appears when you Tab to an element? That’s the focus indicator. Never do this: *:focus { outline: none; }. If you don’t like the default indicator, style it differently, but it must be visible.

Keyboard shortcuts need to be discoverable and not conflict. If your app uses keyboard shortcuts, document them and ensure they don’t override browser shortcuts. Many screen reader users rely on specific keys—don’t break their tools.

Modal dialogs must trap focus. When a modal opens, focus should move into it and Tab should cycle through elements within the modal, not jump back to the page behind it. When the modal closes, focus returns to where it was.

Test this: Can you use your entire website using only Tab, Shift+Tab, Enter, and arrow keys? If not, something’s wrong.

Color Is Not Information

Never use color as the only way to convey information. Color blindness affects roughly 8% of men and 0.5% of women. Many people use high-contrast modes that remove color entirely. Your interface must work without color.

Bad examples:

• Required fields marked only with red asterisks
• Error states shown only with red text
• Success/failure indicated only with green/red background colors
• Charts where different data series are distinguished only by color

Good examples:

• Required fields marked with both color and an asterisk, with “required” in the label
• Errors shown with color, an icon, and error text
• Success states using color, checkmarks, and text confirmation
• Charts using color plus patterns, shapes, or labels

The principle extends to contrast. Text must have sufficient contrast against its background—4.5:1 for normal text, 3:1 for large text. There are contrast checking tools that verify this. Use them.

Screen Readers Exist, So Test With One

You don’t need to be a screen reader expert to do basic testing. Both Windows and macOS include screen readers:

• NVDA (Windows, free, most commonly used)
• JAWS (Windows, commercial, used in enterprise)
• VoiceOver (macOS/iOS, built-in)

Basic screen reader testing reveals obvious problems:

• Can you navigate the page using only screen reader commands?
• Do headings make sense when listed?
• Are images described appropriately?
• Do form fields have clear labels?
• Does interactive functionality work without seeing the screen?

You don’t need to test with every screen reader. Pick one, learn basic navigation, and verify your site works. The problems you find are usually obvious—missing labels, wrong element types, broken keyboard navigation.

ARIA Is a Last Resort, Not a First Choice

ARIA (Accessible Rich Internet Applications) attributes add accessibility information to HTML. They’re powerful but often misused.

The first rule of ARIA: don’t use ARIA unless HTML can’t do what you need. If semantic HTML solves the problem, use semantic HTML.

When you do need ARIA:

• role defines what an element is: role="button" makes a div behave like a button (but just use <button>)
• aria-label provides a label when visual text doesn’t work: <button aria-label="Close">X</button>
• aria-describedby links an element to its description: <input aria-describedby="error-message">
• aria-live announces dynamic content changes: <div aria-live="polite">Items updated</div>

ARIA is for complex interactions that HTML doesn’t support natively—custom dropdown menus, tree views, dynamic content updates. For basic websites, you shouldn’t need much ARIA.

And remember: ARIA only affects assistive technology. It doesn’t change visual presentation or keyboard behavior. You still need to implement those separately.

Automated Testing Catches Maybe 30%

Automated accessibility testing tools (axe, Lighthouse, WAVE) are useful but limited. They catch obvious issues:

• Missing alt text
• Insufficient contrast
• Missing form labels
• Heading level skips

They don’t catch:

• Bad alt text (technically present but unhelpful)
• Illogical heading structure (all heading levels present but in wrong order)
• Broken keyboard navigation (focus indicators present but unusable flow)
• Context-specific problems (a button labeled “Submit” when it should be “Delete Account”)

Use automated testing as a first pass. Fix everything it finds. Then test manually with keyboard and screen reader.

Why This Matters

Accessibility is often framed as moral obligation or legal compliance. Both are valid reasons. But there’s a practical reason too: accessible code is better code.

Semantic HTML is easier to maintain. Clear labels make forms usable for everyone. Keyboard navigation makes power users more efficient. Good color contrast makes sites readable in sunlight. The techniques that benefit people with disabilities benefit everyone.

The businesses figuring this out build better products. Whether it’s web applications, mobile apps, or AI interfaces, accessibility thinking improves usability across the board. Organizations investing in accessible design—sometimes with help from specialized development teams—end up with products that are simply better.

Getting Started

Pick one page or component. Run automated testing and fix everything it finds. Test keyboard navigation. Turn on a screen reader and navigate the page. Fix the problems you find.

Then do it for the next page. And the next component. Accessibility isn’t a single project that gets “done”—it’s an ongoing practice. But once you know the basics, it becomes automatic. You write semantic HTML by default. You include alt text. You test keyboard navigation.

The learning curve is gentler than you think. Most accessibility problems come from not knowing the rules. Once you know them, following them is straightforward. Your code gets better, your sites work for more people, and you stop fighting the browser.

That’s not advanced development. That’s basic competence. And it’s achievable for every developer willing to learn.