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. 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 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.
Accessibility isn't a niche accommodation. It's a quality standard.
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.
Legal risk. 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.
SEO overlap. Many accessibility best practices directly improve your search rankings. Descriptive alt text on images helps screen reader users and Google understand your content. 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.
Wider audience. The World Health Organization estimates that over 16% of the world's population has some form of disability. That's more than 1 billion people. Building an inaccessible website isn't just an ethical problem — it's a business problem.
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.
WCAG is organized around four core principles, often abbreviated as POUR:
Perceivable — Users must be able to perceive all content. If someone can't see an image, there needs to be a text alternative. If someone can't hear audio, there needs to be a caption.
Operable — Users must be able to operate all interface elements. If someone can't use a mouse, they need to be able to do everything with a keyboard. Buttons need to be clickable. Timeouts need to be adjustable.
Understandable — Content and interfaces need to be understandable. Language should be clear. Error messages should explain what went wrong. Navigation should be consistent across pages.
Robust — Content needs to work reliably across different browsers, devices, and assistive technologies. This means writing valid, semantic HTML that assistive technologies can interpret correctly.
WCAG has three levels of conformance:
Level A is the minimum. These are the most critical accessibility requirements — the ones without which entire categories of users simply cannot use your site at all. Examples: all images have alt text, all content can be accessed by keyboard, no content flashes more than three times per second (a seizure risk).
Level AA is the standard that most accessibility laws and guidelines reference. It addresses the most common barriers for disabled users without requiring a prohibitive level of effort. Examples: text has a minimum contrast ratio of 4.5:1, captions are provided for live audio, error messages clearly identify the problem field.
Level AAA is the highest level. These are aspirational guidelines that may not be achievable for all content and all contexts. Most websites aim for AA compliance rather than AAA.
For most developers and most projects, WCAG 2.2 Level AA is the target. That's what the law typically references, what accessibility auditors check against, and what will address the vast majority of real-world barriers 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 fixes for each.
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.
<!-- Bad: missing alt text entirely -->
<img src="team-photo.jpg">
<!-- Bad: unhelpful alt text -->
<img src="team-photo.jpg" alt="image">
<!-- Good: descriptive alt text -->
<img src="team-photo.jpg" alt="The Red Surge Technology team at our Monmouth County office">
For decorative images that don't convey information — dividers, background textures, purely aesthetic icons — use an empty alt attribute (alt=""). This tells screen readers to skip the image entirely rather than reading out the filename.
<!-- Decorative image: empty alt tells screen readers to skip it -->
<img src="decorative-divider.png" alt="">
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.
WCAG AA requires:
Tools to check your contrast:
/* Bad: light grey text on white background — likely fails contrast */
p {
color: #aaaaaa;
background: #ffffff;
}
/* Good: dark text on white — passes comfortably */
p {
color: #333333;
background: #ffffff;
}
Screen reader users often navigate by jumping between links on a page. If every link just says "click here" or "read more," that's completely useless without the surrounding context.
<!-- Bad: no context for screen reader users jumping between 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 CTA like "Read more," you can provide additional context visually hidden from sighted users but available to screen readers using a visually-hidden class:
<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;
}
Every interactive element on your page — links, buttons, form fields, dropdowns, modals — 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 */
*:focus {
outline: none;
}
/* Good: customise 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.
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?
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.
<!-- Bad: no label, using placeholder as a substitute -->
<input type="email" placeholder="Email address">
<!-- Good: explicit label 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 that clicking the label focuses the input (better usability for everyone), and screen readers announce the label when the input receives focus.
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">
Screen reader users navigate documents by jumping between headings — similar to how sighted users scan a page visually. 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: one <h1> per page, <h2> for main sections, <h3> for subsections within those, and so on. Never skip levels (jumping from <h2> to <h4>) and never choose a heading level based on how it looks — use CSS for visual sizing.
<!-- Bad: headings chosen for size, not structure -->
<h3>Welcome to Our Website</h3>
<h1>Our Services</h1>
<h3>Web Design</h3>
<!-- Good: logical hierarchy reflecting content structure -->
<h1>Welcome to Red Surge Technology</h1>
<h2>Our Services</h2>
<h3>Web Design</h3>
<h3>Local SEO</h3>
<h2>About Us</h2>
Also use semantic HTML landmark elements to define regions of your page:
<header> <!-- Site header, logo, primary nav -->
<nav> <!-- Navigation menus -->
<main> <!-- Main page content (one per page) -->
<aside> <!-- Sidebar content related to the main content -->
<footer> <!-- Site footer -->
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.
Any video on your website with meaningful audio content needs captions. Not just auto-generated captions (which are often inaccurate) — accurate, properly timed captions.
For videos hosted on YouTube or Vimeo, you can upload a caption file (.vtt or .srt format) directly in the platform. For HTML5 video:
<video controls>
<source src="intro.mp4" type="video/mp4">
<track
kind="captions"
src="intro-captions.vtt"
srclang="en"
label="English"
default
>
</video>
You don't need expensive tools to start testing for accessibility. Here's a practical workflow for any project:
Step 1 — Automated scan. Run your page through WAVE (free, browser-based) or install the axe DevTools browser extension. These tools catch a lot of the low-hanging fruit: missing alt text, contrast failures, missing labels, and structural errors. Automated tools catch roughly 30–40% of accessibility issues.
Step 2 — Keyboard test. Close your mouse. Tab through every interactive element on the page. Can you reach everything? Is the focus indicator always visible? Can you operate every button, link, and form field?
Step 3 — Screen reader test. Turn on a screen reader and try to navigate your page. On Mac, VoiceOver is built in (Command + F5). On Windows, NVDA is free. On iOS, VoiceOver is in Accessibility settings. On Android, TalkBack works similarly. You don't need to master the screen reader — just experience what it's like to use your page without seeing it.
Step 4 — Contrast check. Paste your text and background colour values into the WebAIM Contrast Checker and verify you pass AA requirements.
Step 5 — Zoom test. Set your browser zoom to 200%. Does your layout hold together? Is any content clipped or hidden? Does the page remain usable?
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.
Some resources worth bookmarking:
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 (Americans with Disabilities Act) has been increasingly applied to websites, and courts have ruled that websites serving the public must be accessible. Section 508 of the Rehabilitation Act applies to federal agencies and their contractors. The legal landscape is still evolving, but the trend is clear — accessibility requirements are expanding, not contracting. 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 in doubt about your specific legal obligations, consult a qualified legal professional.
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 things like focus appearance, dragging movements, and consistent help. 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, target 2.2 from the start.
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 semantics aren't sufficient. The cardinal rule of ARIA is: don't use it when native HTML will do the job. A <button> is better than a <div role="button">. A <nav> is better than <div role="navigation">. ARIA fills the gaps that HTML semantics can't cover; it shouldn't replace them.
Start with an audit. Run your existing site through WAVE or axe and fix the issues in order of severity — missing alt text, contrast failures, and missing form labels are usually the quickest wins. Then move to structural issues like heading hierarchy and landmark elements. Keyboard navigation and screen reader testing will reveal the deeper issues. You don't have to fix everything at once — a steady, prioritised approach makes accessibility work sustainable.
No — when done correctly, accessibility improvements generally have a neutral or positive effect on both. Semantic HTML is lighter than div-soup. Descriptive link text and headings improve SEO. Good colour contrast tends to improve readability for everyone. The perception that accessible design is visually limiting is a myth — some of the best-designed websites on the internet are also highly accessible. Accessibility constraints are design constraints that push you toward clarity and structure, which usually produces better design outcomes overall.
Studies 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.
Written by Collin Stewart, founder of Red Surge Technology. We build fast, accessible websites for small businesses across New Jersey — with clean code from day one. Check out our other developer guides: CSS Grid for responsive web design and how to use the JavaScript Fetch API.