What you'll learn
Quick Answer
Most accessibility comes from using HTML correctly: real buttons and links rather than clickable divs, labels tied to inputs, alt text on meaningful images, headings in order, and visible focus states. Test by navigating your page with only the Tab key. ARIA attributes exist for cases HTML cannot express, and incorrect ARIA is worse than none.
Why This Is Worth Your Time
Beyond the obvious reason that people with disabilities should be able to use what you build, there are three practical arguments.
It overlaps almost entirely with good HTML. Semantic markup, labelled inputs and sensible heading order also help search engines, which read pages structurally.
It is a genuine interview differentiator. Very few fresher portfolios show any accessibility awareness, so mentioning it credibly stands out immediately.
It affects more people than you think. Not only screen reader users — anyone using a keyboard because their trackpad broke, anyone in bright sunlight where low-contrast text vanishes, anyone with a temporary injury.
The fastest test you can run right now: put your mouse aside and press Tab through your page. Can you reach every interactive element? Can you tell where the focus is? Can you activate things with Enter or Space? Can you escape a modal?
If you cannot, neither can a screen reader user, and the fixes are usually small.
Use the Right Element
This single habit resolves most accessibility problems before they exist.
<!-- Wrong: a div pretending to be a button -->
<div class="btn" onclick="save()">Save</div>
<!-- Right -->
<button onclick="save()">Save</button>A real <button> is focusable by keyboard, activates on Enter and Space, announces itself as a button to a screen reader, and works with browser features — all free. Recreating that on a div requires tabindex, key handlers and ARIA roles, and people invariably implement only part of it.
The rule: if it navigates, use <a href>. If it performs an action, use <button>. A link without href is not keyboard-focusable, and a button used for navigation breaks middle-click and open-in-new-tab.
Use landmark elements so users can jump between regions rather than tabbing through everything:
<header>, <nav>, <main>, <aside>, <footer>Exactly one <main> per page. Screen readers offer a shortcut to it, which skips the entire navigation.
Headings describe structure, not size. One <h1>, then <h2> for sections, <h3> for subsections. Do not skip levels to get a smaller font — use CSS for that. Screen reader users navigate by heading, so a broken outline makes a page hard to scan.
Forms and Images
Every input needs a label, properly associated — not placeholder text pretending to be one.
<!-- Wrong: the placeholder disappears when typing, and is not a label -->
<input type="email" placeholder="Email">
<!-- Right -->
<label for="email">Email</label>
<input type="email" id="email">A correctly associated label also enlarges the click target, since clicking the label focuses the input — a usability win for everyone on mobile.
Error messages must be linked to the field and announced, not just coloured red:
<input id="email" aria-describedby="email-error" aria-invalid="true">
<p id="email-error" role="alert">Enter a valid email address</p>Alt text describes the image's purpose, not its appearance.
<img src="chart.png" alt="Sales grew from 200 to 850 units between January and June">
<img src="divider.png" alt=""> <!-- decorative: empty alt, so it is skipped -->An empty alt="" is correct for decorative images and is different from omitting the attribute, which causes some screen readers to read the filename aloud.
For an image inside a link, the alt text should describe the destination, since it becomes the link text.
Do not rely on colour alone to convey meaning. A red border on an invalid field is invisible to a colour-blind user without accompanying text.
Keyboard Navigation and Focus
Never remove focus outlines without replacing them. This is the most common accessibility mistake in the wild, and it is usually done for aesthetics.
/* Wrong — keyboard users can no longer see where they are */
:focus { outline: none; }
/* Right — a visible, styled indicator, shown only for keyboard focus */
:focus-visible {
outline: 3px solid #d1039e;
outline-offset: 2px;
}:focus-visible is the modern solution: it shows the indicator for keyboard navigation but not on mouse clicks, which is what designers usually wanted in the first place.
Add a skip link as the first focusable element, so keyboard users can bypass the navigation on every page:
<a href="#main" class="skip-link">Skip to main content</a>Position it off-screen and bring it into view on focus.
Modals need three things: focus moves into the dialog when it opens, focus is trapped inside while it is open, Escape closes it, and focus returns to the element that triggered it. Custom modals frequently implement none of these, leaving keyboard users stranded behind the overlay.
Do not use positive tabindex values. tabindex="1" and higher override the natural order and create confusing jumps. Use 0 to make something focusable and -1 to make it programmatically focusable only.
Contrast, ARIA and Testing
Colour contrast has measurable minimums: 4.5:1 for normal text and 3:1 for large text against the background. Light grey placeholder text on white is the usual failure, and it affects far more people than assistive-technology users — anyone outdoors, anyone with an older screen.
Browser devtools show the contrast ratio in the colour picker, so checking takes seconds.
ARIA is for what HTML cannot express — custom widgets, live regions, dynamic state. It should be a last resort.
<button aria-expanded="false" aria-controls="menu">Menu</button>
<div id="status" role="status" aria-live="polite"></div> <!-- announces updates -->The first rule of ARIA is not to use ARIA when a native element exists. <button role="button"> is redundant, and <div role="button"> still needs keyboard handlers you probably have not written. Incorrect ARIA is worse than none, because it makes false promises to assistive technology.
How to test, in increasing order of effort:
- Tab through the page. Free, takes a minute, finds most problems.
- Run an automated checker such as the Lighthouse accessibility audit or axe DevTools. These catch roughly a third of issues — useful, but not sufficient.
- Turn on a screen reader. NVDA on Windows and VoiceOver on macOS are built in or free. Fifteen minutes navigating your own site is genuinely eye-opening.
Start with the keyboard test. It costs nothing and it is where most real problems surface.