Call us: (732) 520-3386
Email us: info@redsurgetechnology.com
If you've heard the term "web accessibility" and mentally filed it under "important but complicated — deal with later," you're not alone. A lot of developers, especially those just starting out, treat accessibility as an advanced topic they'll circle back to once they've mastered everything else.
Here's the problem: nearly all of the top one million websites on the internet have critical accessibility issues. According to WebAIM's annual accessibility analysis of the top 1,000,000 homepages, over 96% of pages tested had detectable WCAG failures. The average homepage contained over 50 distinct accessibility errors. That means the overwhelming majority of websites are, to some degree, unusable by a significant portion of the people trying to use them.
This guide is for developers who want to change that — starting today. We're going to cover what web accessibility actually means, who it helps, what WCAG is in plain English, and the specific, practical things you can do right now to make your websites more inclusive. No jargon. No overwhelming checklists. Just a clear, actionable starting point.
Building a website for your business and want it done right from day one? Red Surge Technology builds accessible, fast websites for small businesses across New Jersey. Learn more about what we offer.
Web accessibility means designing and building websites so that people with disabilities can use them. That includes people who:
But here's something important that often gets lost: accessibility improvements help far more people than just those with permanent disabilities. They benefit:
In other words, accessibility is good design for everyone. The features you add to support a screen reader user also produce cleaner, more semantic HTML that helps your SEO. The captions you add for a deaf user help the person watching your video in a quiet office. The keyboard navigation you implement for a motor-impaired user helps power users who prefer the keyboard to the mouse. The clear, structured content that helps someone with a cognitive disability also helps someone scanning your page quickly on their lunch break.
Accessibility isn't a niche accommodation for a small group of users. It's a quality standard that raises the baseline experience for everyone.
The ethical case for accessibility is clear — you want your website to work for everyone. But there are practical reasons too that are worth understanding, whether you're a developer justifying time investment to a client, or a business owner deciding where to allocate resources.
In the United States, websites are increasingly being held to ADA (Americans with Disabilities Act) standards. Thousands of accessibility lawsuits are filed each year against businesses with inaccessible websites, and courts have consistently ruled that websites qualify as places of public accommodation under the ADA. This isn't just a concern for large companies — small businesses have been targeted too, and the number of lawsuits continues to rise year over year.
Beyond US law, the European Accessibility Act (EAA) came into force in June 2025, requiring many digital products and services to meet accessibility standards across the EU. If you serve customers internationally, accessibility compliance is no longer optional.
Many accessibility best practices directly improve your search rankings. This isn't coincidence — search engines and assistive technologies both rely on the same underlying structure of semantic HTML to understand your content.
Descriptive alt text on images helps screen reader users and helps Google understand what your images contain. Proper heading structure helps people navigate your page and helps search engines understand your content hierarchy. Fast load times and clean semantic HTML are good for accessibility and for Core Web Vitals, which Google uses as a ranking signal. Descriptive link text helps screen reader users and provides contextual relevance signals to search engines.
Building for accessibility and building for SEO are largely the same work.
The World Health Organization estimates that over 16% of the world's population has some form of disability. That's more than 1.3 billion people. When you factor in temporary and situational impairments — a broken arm, a noisy environment, an aging population — the percentage of people who benefit from accessible design at any given moment is far higher.
Building an inaccessible website isn't just an ethical problem — it's a business problem. You're actively excluding a significant portion of your potential audience.
WCAG stands for Web Content Accessibility Guidelines. It's the international standard for web accessibility, developed and maintained by the W3C (the same organization that develops the standards for HTML and CSS). When people talk about making a website "accessible," they usually mean meeting WCAG standards.
The current version is WCAG 2.2, published in October 2023. It builds on WCAG 2.1 by adding nine new success criteria and removing one (4.1.1 Parsing, which became redundant as modern browsers handle malformed HTML gracefully). The new criteria in 2.2 primarily improve accessibility for users with cognitive disabilities, low vision, and motor impairments — covering things like focus appearance, dragging movements, and consistent help mechanisms.
When starting a new project in 2026, target WCAG 2.2 from the beginning.
WCAG is organized around four core principles, often abbreviated as POUR. Every success criterion in the guidelines fits under one of these principles. Understanding POUR gives you a mental framework for thinking about accessibility without memorizing the entire specification.
Users must be able to perceive all content and interface elements using at least one of their senses. If someone can't see an image, there needs to be a text alternative they can hear or feel. If someone can't hear an audio track, there needs to be a caption or transcript they can read. If content relies purely on colour to convey information — like a red border indicating an error — there needs to be an additional indicator like an icon or text label for users who are colour blind.
This principle covers: text alternatives for non-text content, captions for multimedia, adaptable content that can be presented in different ways without losing meaning, and sufficient colour contrast.
Users must be able to operate all interface elements regardless of their input method. If someone can't use a mouse, they need to be able to do everything with a keyboard. Buttons need to be clickable via keyboard. Custom widgets like dropdowns and modals need to follow standard keyboard interaction patterns. Time limits need to be adjustable or removable. Content shouldn't flash at rates that could trigger seizures. Navigation needs to be consistent and predictable.
This principle covers: keyboard accessibility, sufficient time to complete tasks, seizure-safe content, navigable and findable content, and input modalities beyond the keyboard.
Content and interfaces need to be understandable. Language should be clear and readable. Error messages should explain what went wrong and how to fix it. Navigation and labelling should be consistent across pages. Forms should provide clear instructions. The default language of the page should be declared so screen readers can pronounce it correctly.
This principle covers: readable text, predictable layouts and interactions, and input assistance that helps users avoid and correct mistakes.
Content needs to work reliably across different browsers, devices, and assistive technologies — now and in the future. This means writing valid, semantic HTML that assistive technologies can interpret correctly. It means using ARIA attributes appropriately when HTML semantics aren't sufficient. It means testing across different screen readers, browsers, and devices to ensure broad compatibility.
This principle covers: compatible markup that can be reliably interpreted by current and future user agents and assistive technologies.
WCAG has three levels of conformance. Understanding what each level means helps you set realistic targets for your projects.
Level A criteria are the most critical accessibility requirements — the ones without which entire categories of users simply cannot use your site at all. These are non-negotiable basics.
Examples of Level A criteria:
Level AA is the standard that most accessibility laws and guidelines reference. It addresses the most common and impactful barriers for disabled users without requiring a prohibitive level of effort. For most developers and most projects, WCAG 2.2 Level AA is the target.
Examples of Level AA criteria (in addition to all Level A):
Level AAA criteria are aspirational guidelines that may not be achievable for all content in all contexts. Most websites aim for AA compliance rather than AAA. Some AAA criteria are feasible to implement (like providing sign language interpretation for all video content) while others may be impractical for certain types of content (like ensuring reading level doesn't exceed lower secondary education for all text).
For practical purposes, target WCAG 2.2 Level AA. That's what the law typically references, what accessibility auditors check against, and what will address the vast majority of real-world barriers your users face.
Rather than overwhelming you with the full WCAG checklist, here are the issues that appear most frequently on real websites — and the specific, actionable fixes for each. These seven issues account for the overwhelming majority of accessibility failures detected in automated scans.
Every meaningful image on your website needs an alt attribute that describes what the image contains. Screen readers read this text aloud to users who can't see the image. Search engines use it to understand image content.
<!-- Bad: missing alt text entirely — screen reader may read the filename -->
<img src="team-photo.jpg" />
<!-- Bad: unhelpful alt text that adds no information -->
<img src="team-photo.jpg" alt="image" />
<!-- Good: descriptive alt text that conveys the image's meaning -->
<img
src="team-photo.jpg"
alt="The Red Surge Technology team at our Monmouth County office"
/>
For decorative images — dividers, background textures, purely aesthetic icons that don't convey information — use an empty alt attribute. This tells screen readers to skip the image entirely rather than reading out the filename or the word "image."
<!-- Decorative image: empty alt tells screen readers to skip it -->
<img src="decorative-divider.png" alt="" />
How to write good alt text: Imagine you're describing the image to someone over the phone. What's important about the image in the context of the surrounding content? An image of a pie chart on a financial report needs different alt text than the same image in an article about data visualization. Context determines what's relevant.
Low contrast between text and its background makes content difficult or impossible to read for users with low vision or colour blindness — and hard to read for anyone in bright sunlight or on a dimmed screen.
WCAG AA requires:
Tools to check your contrast:
/* Bad: light grey text on white background — likely fails AA */
.text-muted {
color: #aaaaaa;
background: #ffffff;
}
/* Good: dark grey text on white — passes AA comfortably */
.text-body {
color: #333333;
background: #ffffff;
}
Common trap: Using grey text on light backgrounds for secondary information. Designers often make secondary text lighter to create visual hierarchy, but if the contrast drops below 4.5:1, that information becomes invisible to users with low vision. Use size and spacing for visual hierarchy, not just colour.
Screen reader users often navigate by jumping between links on a page — they bring up a list of all links and jump directly to the one they want. If every link just says "click here," "read more," or "learn more," that list is completely useless without the surrounding context.
<!-- Bad: no context for screen reader users navigating by links -->
<a href="/blog/seo-guide">Click here</a>
<a href="/blog/website-cost">Read more</a>
<!-- Good: descriptive link text that makes sense out of context -->
<a href="/blog/seo-guide">Read our Local SEO Guide for NJ Businesses</a>
<a href="/blog/website-cost">See how much a website costs in New Jersey</a>
If you genuinely need a short call-to-action like "Read more" for design reasons, you can provide additional context hidden visually but available to screen readers:
<a href="/blog/seo-guide">
Read more
<span class="visually-hidden"> about local SEO for NJ businesses</span>
</a>
.visually-hidden {
position: absolute;
width: 1px;
height: 1px;
padding: 0;
margin: -1px;
overflow: hidden;
clip: rect(0, 0, 0, 0);
white-space: nowrap;
border: 0;
}
This .visually-hidden class is a standard pattern used across the web. It hides content visually while keeping it in the accessibility tree so screen readers can find it.
Every interactive element on your page — links, buttons, form fields, dropdowns, modals, custom widgets — must be reachable and operable by keyboard alone. Users who can't use a mouse navigate by pressing Tab to move between elements and Enter or Space to activate them.
The most common mistake is removing the default focus indicator:
/* Bad: removes the visible focus ring entirely — keyboard users are lost */
*:focus {
outline: none;
}
/* Good: customize the focus style rather than removing it */
*:focus-visible {
outline: 2px solid #0066cc;
outline-offset: 2px;
}
Never use outline: none without replacing it with a clearly visible custom focus style. Without a visible focus indicator, keyboard users have no idea where they are on the page. The :focus-visible pseudo-class is preferred because it only shows the focus ring when the user is navigating by keyboard — not when they're clicking with a mouse — which gives you the best of both worlds.
To test keyboard accessibility on your own site: Put your mouse aside and try to complete a full user journey using only Tab, Shift+Tab, Enter, Space, and arrow keys. Can you get everywhere you need to go? Can you tell where you are at all times? Are there any elements you can reach but can't operate? Any keyboard traps where you can Tab into a component but can't Tab out?
Every form input needs a visible, associated label. Placeholder text is not a substitute for a label — it disappears when the user starts typing, leaving them with no reminder of what the field is for. Placeholder text also typically has low contrast by design, making it hard to read for many users.
<!-- Bad: no label, using placeholder as a substitute -->
<input type="email" placeholder="Email address" />
<!-- Good: explicit label properly associated with the input -->
<label for="email">Email address</label>
<input type="email" id="email" name="email" placeholder="you@example.com" />
The for attribute on the label must match the id attribute on the input. This association means:
For required fields, mark them explicitly — don't rely on colour alone:
<label for="name">
Full name
<span aria-hidden="true">*</span>
<span class="visually-hidden">(required)</span>
</label>
<input type="text" id="name" name="name" required aria-required="true" />
The aria-hidden="true" prevents screen readers from reading the asterisk aloud (which would be confusing), while the visually-hidden text ensures that screen reader users still know the field is required. The aria-required="true" attribute provides a programmatic indication that assistive technology can use.
For error messages, associate them with the field they relate to:
<label for="email">Email address</label>
<input
type="email"
id="email"
name="email"
aria-describedby="email-error"
aria-invalid="true"
/>
<span id="email-error" role="alert">Please enter a valid email address.</span>
The aria-describedby attribute connects the error message to the input so screen readers announce it when the field receives focus. The role="alert" ensures the error is announced immediately when it appears. The aria-invalid attribute provides a programmatic indication that the field contains an error.
Screen reader users navigate documents by jumping between headings — similar to how sighted users scan a page visually, looking at headings to understand the structure and find what they need. If your page has no headings, or uses headings purely for visual styling rather than structure, this navigation completely breaks down.
Use headings in a logical hierarchy:
<h1> per page (the main title)<h2> for main sections<h3> for subsections within those<h2> to <h4>)<!-- Bad: headings chosen for size, not structure — no logical hierarchy -->
<h3>Welcome to Our Website</h3>
<h1>Our Services</h1>
<h3>Web Design</h3>
<!-- Good: logical hierarchy reflecting the document structure -->
<h1>Welcome to Red Surge Technology</h1>
<h2>Our Services</h2>
<h3>Web Design</h3>
<h3>Local SEO</h3>
<h2>About Us</h2>
<h3>Our Team</h3>
<h3>Our Process</h3>
Use semantic HTML landmark elements to define the major regions of your page:
<header>
<!-- Site header, logo, primary navigation -->
<nav>
<!-- Navigation menus (can have multiple) -->
<main>
<!-- Main page content — one per page -->
<aside>
<!-- Sidebar or complementary content -->
<footer><!-- Site footer, copyright, secondary links --></footer>
</aside>
</main>
</nav>
</header>
These elements give screen reader users the ability to jump directly to the main content, skip navigation, or go straight to the footer — without having to Tab through every element on the page. This is the equivalent of a sighted user glancing at the page layout and immediately understanding where the navigation ends and the content begins.
Any video on your website with meaningful audio content needs captions. Not just auto-generated captions — which are often inaccurate and can garble technical terms, names, and context — but accurate, properly timed captions that convey everything important in the audio track.
For videos hosted on YouTube or Vimeo, you can upload a caption file (.vtt or .srt format) directly in the platform's video settings. YouTube also provides auto-generated captions that you can download and correct — much faster than starting from scratch.
For HTML5 video embedded directly on your site:
<video controls>
<source src="intro.mp4" type="video/mp4" />
<track
kind="captions"
src="intro-captions.vtt"
srclang="en"
label="English"
default
/>
Your browser does not support the video tag.
</video>
The <track> element with kind="captions" provides the caption file. The srclang attribute specifies the language. The default attribute tells the browser to enable these captions by default. The fallback text inside the <video> element displays if the browser doesn't support HTML5 video at all.
For audio-only content like podcasts, provide a transcript. This helps deaf users, users in noisy environments, and users who simply prefer reading to listening.
You don't need expensive tools or certification to start testing for accessibility. Here's a practical, repeatable workflow you can use on any project starting today.
Run your page through a free automated tool. WAVE is browser-based and requires no installation. The axe DevTools browser extension integrates directly into Chrome or Firefox DevTools.
These tools catch roughly 30–40% of accessibility issues automatically: missing alt text, contrast failures, missing form labels, invalid ARIA attributes, and structural errors like skipped heading levels. An automated scan gives you a prioritized list of issues to address and takes under a minute to run.
Close your mouse. Seriously — put it out of reach. Now navigate your page using only the Tab key, Shift+Tab to go backwards, Enter to activate links and buttons, Space to toggle checkboxes, and arrow keys to navigate within components.
Ask yourself:
Turn on a screen reader and try to navigate your page without looking at the screen. On Mac, VoiceOver is built in (Command + F5 to toggle). On Windows, NVDA is free and widely used. On iOS, VoiceOver is in Settings > Accessibility. On Android, TalkBack works similarly.
You don't need to become a screen reader expert. Just experience what it's like to consume your page without seeing it. Can you understand the content? Can you navigate between sections? Do the forms make sense? Do images have appropriate alt text?
Use the WebAIM Contrast Checker to test your text colours against their backgrounds. Check your primary text colour, your secondary or muted text colour, your link colour, and your button text colour. Any colour combination that fails AA contrast requirements needs adjustment.
Set your browser zoom to 200% (Ctrl/Cmd + Plus). At this zoom level, WCAG requires that content remain readable and functional without horizontal scrolling. Does your layout hold together? Is any content clipped, overlapping, or hidden? Can you still navigate and complete key tasks?
Read through your page with fresh eyes — or ask someone unfamiliar with the project to do so. Are your headings descriptive? Do your links make sense out of context? Are your error messages clear about what went wrong and how to fix it? Is your language clear and straightforward?
Accessibility is a broad field, and this guide is a starting point — not an endpoint. The most important thing is to start. Every improvement you make today helps real users right now, and building accessibility into your workflow from the beginning costs far less than retrofitting later.
The best time to build accessibility in is at the start of a project. The second-best time is right now.
In the United States, the ADA has been increasingly applied to websites by courts, which have consistently ruled that websites serving the public qualify as places of public accommodation. Section 508 of the Rehabilitation Act applies directly to federal agencies and their contractors. Beyond US law, the European Accessibility Act came into force in June 2025, requiring many digital products and services to meet accessibility standards across the EU. The legal landscape continues to evolve, but the direction is clear: accessibility requirements are expanding. If you have specific questions about your legal obligations, consult a qualified legal professional familiar with digital accessibility law.
WCAG 2.2, published in October 2023, builds on 2.1 by adding nine new success criteria and removing one (4.1.1 Parsing, which became redundant as modern browsers handle malformed HTML gracefully). The new criteria in 2.2 primarily improve accessibility for users with cognitive disabilities, low vision, and motor impairments — covering areas like focus appearance requirements, dragging movements, target size minimums, and consistent help mechanisms. If your site already meets WCAG 2.1 AA, upgrading to 2.2 AA requires addressing the nine new criteria. When starting a new project in 2026, target 2.2 from the beginning.
ARIA (Accessible Rich Internet Applications) is a set of HTML attributes that provide additional semantic information to assistive technologies. It's most useful for dynamic, interactive components — custom dropdowns, modal dialogs, tab panels, carousels — where native HTML elements don't provide sufficient semantics on their own. The cardinal rule of ARIA is simple: don't use it when native HTML will do the job. A <button> is always better than <div role="button">. A <nav> is always better than <div role="navigation">. ARIA fills the gaps that HTML semantics can't cover; it shouldn't replace them. When you do use ARIA, test thoroughly with a screen reader to verify it behaves as expected.
Start with an audit. Run your existing site through WAVE or axe to identify the issues, then prioritize fixes by impact. Missing alt text, contrast failures, and missing form labels are usually the quickest wins with the highest impact. Then move to structural issues like heading hierarchy and landmark elements. Keyboard navigation and screen reader testing will reveal the deeper interaction issues that automated tools miss. You don't have to fix everything at once — a steady, prioritized approach makes accessibility work sustainable on existing projects.
No — when done correctly, accessibility improvements generally have a neutral or positive effect on both. Semantic HTML is lighter and faster than div-soup. Descriptive link text and headings improve SEO. Good colour contrast tends to improve readability for everyone, not just users with low vision. The perception that accessible design is visually boring or limiting is a myth — some of the best-designed websites on the internet are also the most accessible. Accessibility constraints push you toward clarity and structure, which usually produces better design outcomes overall.
Studies and industry experience consistently show that building accessibility in from the start adds roughly 10–20% to development time — far less than retrofitting an inaccessible site later, which can cost several times the original build. The single most impactful thing you can do is write semantic HTML from the start: use the right elements for the right jobs, structure your headings correctly, label your forms properly, and make sure everything works by keyboard. Most of the foundation of accessibility is just good HTML. It only becomes expensive when it's ignored until the end.
If you're overwhelmed and don't know where to start, begin with keyboard accessibility. Close your mouse and try to use your entire site. Every issue you discover is something real users experience every day. Fixing keyboard navigation and focus management addresses barriers for the widest range of users — including screen reader users, motor-impaired users, and power users — and forces you to think about interactive element semantics, which naturally leads to improvements in other areas.
Written by Collin Stewart, founder of Red Surge Technology. We build fast, accessible websites for small businesses across New Jersey — with clean code and inclusive design from day one. Check out our other developer guides: CSS Grid for responsive web design and how to use the JavaScript Fetch API. If you have questions about making your website more accessible, reach out — we're happy to help.