Web accessibility is not a checkbox or a legal requirement -- although it is that too. It is the practice of building sites that work for people regardless of how they interact with them. This guide focuses on practical changes that have real impact, not exhaustive specification reading.
Why Accessibility Matters Beyond Compliance
Scale. The World Health Organization estimates 15% of the global population has some form of disability. That is over 1 billion people. Visual impairments, motor disabilities, cognitive disabilities, and temporary situations (a broken arm, bright sunlight on a phone screen) affect how people use the web.
Search and usability overlap. Many accessibility improvements directly improve the experience for everyone. Clear heading hierarchies help screen reader users navigate and help sighted users skim. Sufficient color contrast helps colorblind users and also helps anyone using a device in bright sunlight. Keyboard navigation helps power users who prefer not to use a mouse.
SEO. Search engines parse page structure similarly to screen readers. Semantic HTML, meaningful alt text, and clear heading hierarchies improve crawlability and relevance signals.
Legal risk. Accessibility lawsuits against websites are increasing, particularly in the United States under the ADA. For e-commerce and government-adjacent services, inaccessibility is a legal liability.
Semantic HTML: The Highest-Leverage Change
Using the right HTML element is the single highest-leverage accessibility improvement. Semantic elements communicate meaning to assistive technologies without any additional ARIA required.
Buttons for actions, links for navigation. A <button> fires on Enter and Space, is keyboard focusable by default, communicates its role to screen readers. A <div onClick> does none of this. When you use a div as a button, you must add role="button", tabindex="0", and keyboard event handlers manually -- recreating what the native element gives for free.
Heading hierarchy. Use h1 through h6 in order. One h1 per page (the main title). Subsections get h2. Subsections within those get h3. Never skip levels. Screen reader users navigate pages by heading -- a coherent heading hierarchy is a navigable outline.
Landmark elements. <header>, <main>, <nav>, <footer>, <aside>, and <section> create landmark regions. Screen reader users jump between landmarks to navigate large pages. A page with <div class="header"> instead of <header> has no navigable landmarks.
Form labels. Every form input needs a <label> element with a for attribute matching the input's id. Placeholder text is not a label -- it disappears when the user starts typing.
<!-- Correct -->
<label for="email">Email address</label>
<input id="email" type="email" />
<!-- Wrong -- placeholder is not a label -->
<input type="email" placeholder="Email address" />
Alt Text for Images
Every <img> needs an alt attribute. The value depends on the image's purpose:
Informative images need descriptive alt text that conveys the same information the image conveys. A photo of a team in an "About" section: alt="The Pristren team at our 2026 offsite in Berlin".
Decorative images that add no information should have an empty alt attribute (alt=""). This tells screen readers to skip the image entirely.
Images of text should have alt text that matches the text in the image. Better: use real text instead of images of text.
Functional images (icons that are buttons, logo links) need alt text that describes the function. An envelope icon button: alt="Send email" not alt="envelope".
Color Contrast
The WCAG 2.1 AA standard requires:
4.5:1 contrast ratio for normal text (under 18pt or 14pt bold). 3:1 for large text (18pt or larger, 14pt bold or larger). 3:1 for UI components (input borders, button outlines) and graphical content (chart lines, icons).
A contrast ratio of 4.5:1 means the lighter color is 4.5 times brighter than the darker one. Tools to check: WebAIM Contrast Checker, browser DevTools (Chrome DevTools shows the contrast ratio when you inspect an element), the axe DevTools extension.
Common failures: light gray text on white backgrounds, colored text on similar-colored backgrounds, disabled states with insufficient contrast.
Keyboard Navigation
Every interactive element must be reachable and operable by keyboard alone:
Focus visible. The focused element must have a visible indicator. Never apply outline: none to interactive elements without providing an alternative focus style. The default browser outline is ugly but effective. Replace it with something visually distinct, not nothing.
Tab order. Focus should move through the page in a logical order (generally top-left to bottom-right). Avoid tabindex values above 0, which pull elements out of the natural tab order and create confusing navigation.
Focus trapping for modals. When a modal is open, keyboard focus should be trapped inside it. Focus should not reach elements behind the modal. When the modal closes, focus should return to the element that opened it.
Keyboard shortcuts for complex widgets. Menus, date pickers, and tabs have established keyboard patterns (arrow keys for navigation within a widget, Escape to close). Follow the ARIA Authoring Practices Guide patterns for these.
ARIA Labels for Icon Buttons
Icon-only buttons are one of the most common accessibility failures. An icon without a text label has no accessible name.
// Wrong -- screen reader announces "button" with no context
<button><XIcon /></button>
// Correct -- screen reader announces "Close dialog"
<button aria-label="Close dialog"><XIcon /></button>
The same applies to icon links and any interactive element whose visible label is an image or icon.
Testing Without Extensive Automation
axe DevTools browser extension (free) runs automated accessibility checks and catches 40-50% of issues without any setup. Install it, open DevTools, and run it on every page you build.
Keyboard navigation testing. Tab through your entire page. Can you reach every interactive element? Does the focus indicator remain visible? Can you operate everything (open menus, submit forms, activate buttons) without a mouse?
Screen reader spot checks. macOS includes VoiceOver (Command + F5). Windows includes NVDA (free download). Navigate a few key flows: the main navigation, a form submission, a data table. Listen for whether the experience makes sense without visual context.
What to Prioritize
If you cannot fix everything at once, this is the order of impact:
- Semantic HTML (buttons, headings, landmarks, labels) -- high impact, fast to fix
- Alt text on images -- high impact, fast to fix
- Keyboard navigation and focus management -- high impact, moderate effort
- Color contrast -- moderate impact, requires design review
- ARIA patterns for complex widgets -- lower impact, higher effort
Fix the quick wins first. A page with correct semantic HTML, alt text, and keyboard navigation is dramatically more accessible than one without them, even if it has some ARIA gaps.
Keep Reading
- Core Web Vitals in 2026: What They Are and How to Actually Pass -- performance and accessibility often have overlapping fixes
- Next.js Performance Optimization: The Practical Guide for Production Apps -- semantic HTML also improves crawlability
- TypeScript for React Developers: Practical Patterns That Actually Help -- typing accessible component APIs
Pristren builds AI-powered software for teams. Zlyqor is our all-in-one workspace -- chat, projects, time tracking, AI meeting summaries, and invoicing -- in one tool. Try it free.
