How to improve website accessibility: a practical guide
The fixes that remove the most common barriers, how to test them by hand in 15 minutes, and what automated accessibility checkers can and can't tell you.
An accessible website is one that people can use regardless of disability or how they access the web: with a screen reader, by keyboard only, with magnified text, with limited color vision, or with a hand tremor. The same improvements also help people with a broken arm, a small phone screen in bright sunlight, or a slow connection.
The widely used benchmark is the Web Content Accessibility Guidelines (WCAG), currently version 2.2. Many accessibility laws and procurement rules refer to WCAG, most often at level AA. This guide focuses on the fixes that remove the most common barriers, then shows how to test them.
Start with an automated check, then test by hand
An automated scan is the quickest way to find the obvious problems. Rudra's free accessibility checker loads your page in a real browser and runs axe-core, the widely used open-source testing engine. It lists each rule that fails, how many elements are affected and how serious the impact is: missing alt text, unlabeled form fields, insufficient contrast, a missing page language, empty buttons and links, and more.
The fixes that matter most
1. Give images meaningful text alternatives
Every <img> needs an alt attribute. For informative images, describe what the image conveys in context, not just what it depicts: alt="Line chart: sign-ups doubled after the March redesign" is more useful than alt="chart". For purely decorative images, use an empty alt="" so screen readers skip them. For an image that is a link or button, describe the action ("Search", "Download the report"). Complex charts also need the key data in nearby text or a table.
2. Label every form field
Each input needs a visible label that's connected to it in the code: <label for="email">Email address</label> followed by <input id="email" type="email" autocomplete="email">. Placeholder text isn't a label; it disappears as soon as someone types and is often low contrast. Show errors in text next to the field (not only as a red border), explain how to fix them, and connect them to the field with aria-describedby.
3. Get color contrast right
- Normal text: a contrast ratio of at least 4.5:1 against its background (WCAG 1.4.3, level AA).
- Large text (at least 24 px, or about 18.7 px if bold): at least 3:1.
- Interface components and meaningful graphics, such as input borders, focus indicators and icons that carry meaning: at least 3:1 against adjacent colors (WCAG 1.4.11).
- Don't rely on color alone (WCAG 1.4.1). A link inside a paragraph should be distinguishable by more than its color, usually with an underline, and an error shouldn't be indicated only in red.
Browser developer tools show the contrast ratio when you inspect a text element, so you can check and adjust colors as you go. Watch for light gray text, text over photos, and placeholder text.
4. Make everything work with a keyboard
Everything you can do with a mouse should be possible with Tab, Shift+Tab, Enter, Space, the arrow keys and Escape. Use real <button> and <a href> elements instead of clickable <div>s, which can't be focused or activated by keyboard without extra work. Never remove the focus outline without providing a clearly visible replacement; :focus-visible lets you style it for keyboard users only. Make sure a sticky header or cookie banner doesn't hide the focused element (a new WCAG 2.2 criterion, 2.4.11), that dialogs trap focus while open and return it when closed, and add a "Skip to main content" link at the top of the page.
5. Structure pages with headings and landmarks
Screen reader users often navigate by jumping between headings. Use one <h1> that describes the page, then <h2> and <h3> in a logical order, and choose heading levels for structure, not for their font size. Wrap regions in <header>, <nav>, <main> and <footer> so people can jump straight to the content.
6. Set the page language and a unique title
<html lang="en"> (or your language) tells screen readers how to pronounce the text. A unique, descriptive <title> is the first thing announced when a page opens and what identifies it among browser tabs.
7. Write links and buttons that make sense on their own
Screen reader users can list all the links on a page, where "Click here" and "Read more" repeated ten times are meaningless. Use text like "Read the pricing guide". Icon-only buttons, such as a magnifying glass or a close "×", need an accessible name: <button aria-label="Close">.
8. Make targets big enough to hit
WCAG 2.2 added a level AA requirement (2.5.8) that pointer targets be at least 24 × 24 CSS pixels, or spaced so that a 24-pixel circle around each doesn't overlap another. Larger targets, around 44 × 44 pixels (the level AAA guideline), are better still on touchscreens.
9. Support zoom and reflow
Never disable zoom with user-scalable=no or maximum-scale=1. Content should reflow into a single column without horizontal scrolling at a width of 320 CSS pixels, which is what 400% zoom on a typical desktop screen produces (WCAG 1.4.10). A responsive layout gets you most of the way; see how to make a website mobile friendly.
10. Handle media and motion with care
Provide captions for videos and transcripts for audio. Don't autoplay sound. Give carousels and animations a pause button, and respect the prefers-reduced-motion media query by reducing or removing non-essential animation for people who have asked for it.
11. Prefer native HTML to ARIA
ARIA attributes change what assistive technology announces, but not how an element behaves. A <div role="button"> still needs keyboard handling you have to write yourself; a <button> has it built in. Use native elements wherever possible, and add ARIA only when HTML has no equivalent, following the patterns in the W3C's ARIA Authoring Practices Guide.
A 15-minute manual test
- Unplug the mouse. Tab through the page from the top. Can you see where focus is at every step? Can you reach and operate every link, button, menu and form field? Can you close pop-ups with Escape?
- Zoom to 200%, then 400%. Does text reflow, or do you have to scroll sideways? Does anything overlap or disappear?
- Try a screen reader for a few minutes: NVDA (free, Windows), VoiceOver (built into macOS and iOS) or TalkBack (Android). List the headings and links, and fill in a form. Is everything announced clearly?
- Check the images. Read the alt text (the screen reader, or your browser's accessibility inspector, shows it). Does it describe what matters?
- Look at the page in grayscale (most operating systems have a color filter setting). Is any information conveyed only by color?
Make accessibility part of the process
- Fix issues in shared components and templates first; one fixed header or form component fixes every page that uses it.
- Add automated checks to your development pipeline, for example axe-core with your end-to-end tests, so regressions are caught before release.
- Include keyboard and contrast checks in your definition of done for new features.
- Publish an accessibility statement with a way for people to report barriers, and respond to what they tell you.
Common mistakes
- Relying on an overlay widget to fix accessibility. A script added on top of the page can't repair the underlying markup, and many disabled users report that overlays get in their way.
- Stuffing alt text with keywords, or starting it with "Image of" (screen readers already announce that it's an image).
- Using placeholder text instead of labels.
- Removing focus outlines for aesthetic reasons.
- Adding
aria-labelto everything, sometimes overriding perfectly good visible text. - Treating a clean automated report as proof that a site is accessible.
Check accessibility across your site
Run a free audit: Rudra checks every crawled page for missing alt text, unlabeled fields, missing language and titles, heading problems and unclear links.
Frequently asked questions
What is WCAG 2.2 level AA?
WCAG 2.2 is the current version of the W3C's Web Content Accessibility Guidelines. Its success criteria are grouped into levels A, AA and AAA; level AA includes all A and AA criteria and is the level most laws and policies refer to.
Can an automated tool make my website compliant?
No. Automated tools such as axe-core reliably catch many common issues, but a large part of WCAG needs human judgement, such as whether alt text is meaningful, focus order is logical or instructions are clear. Combine automated scans with manual keyboard and screen reader testing.
What color contrast ratio do I need?
For WCAG AA, normal text needs at least 4.5:1 against its background, and large text (at least 24 px, or about 18.7 px bold) needs at least 3:1. Interface components and meaningful graphics also need at least 3:1 against adjacent colors.
Does accessibility help SEO?
Indirectly, in places. Descriptive alt text, clear headings, meaningful link text and proper page titles help search engines understand a page as well as people. But accessibility is worth doing for your users; any search benefit is a side effect.
Where should I start on a large website?
Start with the templates and shared components used everywhere (header, navigation, footer, forms) and your most important user journeys, such as sign-up, checkout or contact. Fixing those removes the most barriers for the least effort.