What Web Accessibility Means
Web accessibility means designing and building a website so that people with disabilities can perceive it, understand it, navigate it, and interact with it. That covers a wide range of needs. A person who is blind uses a screen reader that speaks the page aloud, so the page has to make sense as spoken text and every control has to announce what it does. Someone with low vision may enlarge the text to twice its normal size and needs the layout to hold together instead of breaking. A person with a motor condition may navigate entirely by keyboard, or with a switch device, and cannot rely on precise mouse movements. Someone who is deaf needs captions for video. A person with a cognitive difference needs clear language and a layout that does not overwhelm.
It helps to widen the picture beyond permanent disability. Accessibility also serves temporary and situational limitations. A parent holding a baby is browsing one handed. A commuter on a loud train cannot hear a video and depends on captions. A traveler in bright sun struggles with low contrast text. An older visitor whose eyesight has changed appreciates larger type and generous spacing. When you build for the person at the edge, you almost always improve the experience for everyone in the middle.
A common misconception is that an accessible site has to look plain, or that accessibility is a layer you bolt on at the end. Neither is true. Accessible sites can be beautiful, modern, and expressive. And the cheapest, most reliable way to get there is to build accessibility in from the first wireframe rather than trying to retrofit it after launch. Retrofitting is possible, but it costs more and tends to leave gaps. If you want a sense of how this fits into a broader build, our overview of web design services shows where accessibility sits in the process.
Assistive technology in plain terms
To design well, it helps to know the tools people actually use. Screen readers convert on screen content into speech or braille. Screen magnifiers enlarge part of the display. Speech recognition lets people control a computer with their voice. Switch devices allow a single button, or a puff of breath, to drive navigation. Browser zoom and operating system settings let people change text size, contrast, and motion. Your site does not talk to each of these tools directly. Instead, it exposes clean, standard HTML, and the tools read that structure. This is why the underlying code quality matters so much. A tidy, semantic page is one that assistive technology can interpret correctly, and a tangle of unlabeled boxes is one that leaves users guessing.
Why Accessibility Matters
There are four honest reasons to care about accessibility, and they reinforce each other. The first is the human one. A large share of the population lives with a disability, and those people are your customers, your readers, and your job applicants. When your site locks them out, you are not making a neutral choice. You are turning people away who wanted to buy, book, sign up, or learn.
The second reason is reach and revenue. People with disabilities control significant spending power, and they tend to stay loyal to businesses that treat them well. An inaccessible checkout, a form that cannot be completed by keyboard, or a menu that a screen reader cannot open is a leak in your funnel that you probably cannot see in your analytics, because the people who hit it simply leave. Fixing these barriers widens the top of the funnel without spending more on advertising.
The third reason is legal risk, which we cover in detail further down. Lawsuits and complaints over inaccessible websites have become common, and most of them settle. Building to a recognized standard is the most effective protection, and it is far cheaper than defending a claim.
The fourth reason is quality. Accessible sites are usually faster, cleaner, and easier to maintain, because the same habits that help assistive technology also produce well structured code. Search engines reward that structure too, which we return to near the end. In short, accessibility is one of those rare investments where doing the right thing and the smart thing point in the same direction.
The takeaway from that picture is simple. No single group dominates, and the barriers overlap. A caption helps a deaf visitor and a commuter alike. Keyboard support helps a person with a motor condition and a power user who prefers the keyboard. Designing for one need tends to help several at once, which is why accessibility pays back more broadly than people expect.
Understanding WCAG
The main standard for web accessibility is the Web Content Accessibility Guidelines, almost always shortened to WCAG. It is published by the World Wide Web Consortium, the body that maintains the core standards of the web. WCAG is not a law by itself, but it is the reference that most laws, contracts, and audits point to. When someone says a site should be accessible, they almost always mean it should meet WCAG.
WCAG is organized into individual success criteria, each one a testable statement about the page. The criteria are grouped into three conformance levels, and this is the part worth understanding well, because it is where planning decisions get made.
- Level A is the minimum. These criteria cover the most basic barriers, the ones that make a site completely unusable for some people if ignored. Meeting only Level A is not enough for most purposes, but failing it is a serious problem.
- Level AA is the practical target for almost every website. It adds criteria for things like color contrast, text resizing, and clear navigation. When a law, a government contract, or a client agreement names a standard, it is almost always WCAG Level AA. This is the level we recommend as the default goal for business sites.
- Level AAA is the highest bar. It includes strict criteria that are appropriate for some specialized content but are not realistic or even sensible to apply to an entire site. Aiming for full AAA everywhere is usually the wrong goal. Reaching for it selectively on critical content can make sense.
There are also version numbers. WCAG 2.0 came first, WCAG 2.1 added criteria for mobile, low vision, and cognitive needs, and WCAG 2.2 refined things further with a handful of new criteria. For a business site, the sensible instruction to give any developer is short: meet WCAG 2.1 Level AA or newer. That single sentence captures what the large majority of legal frameworks and procurement rules expect.
The table below shows the kind of criteria that live at each level, so the difference feels concrete rather than abstract. These are representative examples, not the full list, which runs to dozens of criteria.
| Level | What it covers | Example criteria |
|---|---|---|
| A | Basic barriers that block access entirely | Images have text alternatives; content works by keyboard; video has captions when it conveys information; page has a logical reading order |
| AA | The practical bar for most sites and laws | Text contrast of at least 4.5 to 1; text can resize to 200 percent without breaking; clear focus indicator; consistent navigation; meaningful page titles and headings |
| AAA | Strictest, for selective use | Contrast of at least 7 to 1; sign language for video; no timing on tasks; very plain reading level throughout |
If you take one thing from this section, let it be the phrase WCAG 2.1 AA. It is the shorthand that keeps a project honest. When you brief a designer or developer, name that target, and ask how they will prove they hit it. If you are not sure your current site is anywhere close, you can request a free quote for an accessibility review and we will tell you where you stand.
The Four Principles (POUR)
Underneath all the criteria, WCAG rests on four principles. They are often remembered by the acronym POUR: perceivable, operable, understandable, and robust. Every success criterion supports one of these four ideas, so if you understand the principles you understand the point of the whole standard.
Perceivable
Content must be available to at least one of a person's senses. If information is carried only by an image, a blind visitor loses it, so images need text alternatives. If it is carried only by audio, a deaf visitor loses it, so video needs captions. If it is carried only by color, someone who is colorblind may miss it, so color should never be the sole signal. Perceivable also covers contrast, because text that blends into its background is not truly perceivable for people with low vision.
Operable
People must be able to use every control, and not just with a mouse. This is where keyboard access lives. Every link, button, menu, and form field should be reachable and usable with the keyboard alone, and the currently focused element should be clearly visible. Operable also means not setting traps, such as a popup that cannot be closed by keyboard, and not relying on gestures that some people cannot perform. Giving people enough time to complete tasks and avoiding content that flashes rapidly, which can trigger seizures, also fall under this principle.
Understandable
Content and controls should behave predictably and read clearly. Navigation should stay consistent from page to page. Form errors should explain what went wrong and how to fix it, in plain language rather than a cryptic code. Text should be written as simply as the subject allows. A page that technically exposes all its information but does so in a confusing way still fails people, especially those with cognitive differences.
Robust
The page should work reliably with a wide range of browsers and assistive tools, today and as those tools evolve. In practice this means writing clean, standard HTML and using the right element for the job, so that a screen reader knows a button is a button. When custom components are needed, they should carry the correct roles and labels so that assistive technology can interpret them. Robust code is why accessibility and good engineering are so closely tied. Sloppy markup fails this principle first.
ADA and the Legal Picture
Many business owners first hear about accessibility through the legal side, often after a warning letter or a competitor's lawsuit. It is worth understanding the landscape, without turning this into legal advice, which we are not qualified to give.
In the United States, the Americans with Disabilities Act, known as the ADA, is the law most often cited. It was written before the modern web, so it does not spell out technical rules for websites. Instead, courts and the Department of Justice have generally treated business websites as places that must be accessible, much like a physical storefront needs a ramp. Because the ADA itself does not list web rules, WCAG has become the practical benchmark that courts and settlements refer to. This is the core reason WCAG Level AA keeps coming up. It is the yardstick everyone reaches for.
Public sector and federally funded organizations in the US face an additional requirement often called Section 508, which points to WCAG as well. In Canada, accessibility law varies by jurisdiction, with provincial frameworks and federal rules that likewise lean on WCAG as the technical reference. Across Europe, the European Accessibility Act and related standards push private companies toward the same guidelines. The details differ from place to place, but the destination is remarkably consistent. Nearly every framework in the world lands on WCAG.
Lawsuits and demand letters over inaccessible sites have grown into a steady stream, and they tend to target the same recurring failures: images without alt text, forms that cannot be completed by keyboard, poor contrast, and menus that break with a screen reader. Most claims settle rather than going to trial, and the settlement usually requires fixing the site anyway, plus paying the other side. Building to WCAG AA from the start is by far the cheaper path. If you would like a clear read on where your current site stands before anyone else raises the question, get in touch for a free quote and we will scope an audit.
One warning worth stating plainly. A number of vendors sell an overlay widget, a small script you add to your site that promises instant compliance with a floating accessibility button. These tools are widely criticized by disabled users and accessibility experts because they do not fix the underlying code, often interfere with the assistive technology people already use, and have not stopped lawsuits. Treat the promise of one line, instant compliance with healthy skepticism. Real accessibility comes from fixing the page itself, not from a layer painted over the top.
Common Barriers and Who They Affect
Before fixing anything, it helps to know what actually goes wrong. The same handful of problems appear on site after site. If you address these, you will have solved the majority of real barriers people hit.
Missing text alternatives
Images that carry meaning, such as a chart, a product photo, or an icon that acts as a button, need a short text description in the alt attribute. When that description is missing, a screen reader may announce a filename or nothing at all, and the visitor loses whatever the image conveyed. Purely decorative images should have an empty alt so the screen reader skips them cleanly.
Poor color contrast
Light gray text on a white background looks elegant to some designers and is invisible to many readers, especially those with low vision or anyone outdoors. WCAG AA asks for a contrast ratio of at least 4.5 to 1 for normal text. This is one of the most common failures and one of the easiest to fix.
Keyboard traps and no focus indicator
Some people never touch a mouse. If they cannot reach your menu, your buttons, or your form fields by pressing Tab, and cannot see which element is currently focused, your site is unusable for them. Custom dropdowns and modal dialogs built without care are frequent offenders here.
Unlabeled forms and buttons
A form field without a proper label leaves a screen reader user guessing what to type. A button whose only content is an icon, with no accessible name, is announced as button and nothing more. Labels are cheap to add and remove a huge amount of confusion.
Missing captions and video controls
Video and audio that carry information need captions, and ideally a transcript. Without them, deaf and hard of hearing visitors are excluded, and so is anyone in a situation where sound is off.
Confusing structure
Headings that are chosen for their size rather than their meaning, links that all read click here, and pages with no clear landmarks make navigation slow and disorienting, particularly for screen reader users who often move through a page by its headings and links.
Time limits and surprise movement
Some sites log people out after a short window, or move a carousel along before a slow reader has finished. A person with a motor or cognitive difference may need far more time than the designer assumed, and an automatic slideshow that shifts under their cursor can make a task impossible. Where a time limit is genuinely needed, people should be warned and given an easy way to extend it. Where movement is decorative, it should be gentle, pausable, and never the only path to important content. These are quiet barriers that rarely show up in a quick glance yet block real people every day.
Content that only works one way
A pinch to zoom gesture, a drag and drop that has no keyboard equivalent, or an instruction that says tap the green button all assume a single way of interacting. People who use a keyboard, a switch, or a screen reader need another route to the same outcome. The fix is to make sure every action has more than one path and that instructions describe controls by their label rather than their position or color alone.
Notice that none of these are exotic. They are ordinary oversights that creep in when accessibility is not part of the routine. That is encouraging, because it means the fixes are ordinary too.
Practical Fixes You Can Make
This is the part you can act on. Below are the changes that remove the most common barriers, described in plain terms. Many can be applied to an existing site without a full rebuild, though the cleanest results come from building these habits in from the start.
Write meaningful alt text
For every image that carries information, add a short description of what it shows or does. Describe the point, not every pixel. A photo of a red winter coat on a product page might read red wool winter coat, front view. A magnifying glass icon that runs a search should be labeled search. Leave the alt empty for images that are purely decorative, so assistive technology skips them.
Fix your color contrast
Check the contrast between your text and its background, and adjust until normal text reaches at least 4.5 to 1. This often means darkening a light gray or choosing a stronger shade for links and buttons. Do not use color as the only way to signal something. If a required field is marked only by turning its label red, add a word or an icon so colorblind visitors get the message too.
Make everything work by keyboard
Put your mouse aside and try to use your site with the Tab key, the Enter key, and the arrow keys. You should be able to reach every link, button, and field, activate them, and always see a clear outline around whatever is focused. If a menu or a popup cannot be reached or closed by keyboard, that is a priority fix. Never remove the focus outline in your styles without replacing it with something equally visible.
Label every form field and control
Connect a visible label to each form field so screen readers announce it correctly. Give icon only buttons an accessible name. Write error messages that say what went wrong and how to fix it, for example enter a valid email address such as name at example dot com, rather than a bare error. Well built forms are one of the highest impact areas, because forms are where conversions happen. Our guide to building a site covers this alongside other fundamentals in how to make a website.
Use headings and structure honestly
Choose heading levels for their meaning, not their appearance. One main heading per page, then logical subheadings beneath it. Use real lists for lists and real buttons for buttons. Write link text that makes sense out of context, so read our returns policy rather than click here. This structure helps screen reader users move quickly and helps search engines understand your page, which is a theme we return to shortly.
Caption your media
Add captions to any video that conveys information, and provide a transcript where you can. Make sure media does not play automatically with sound, and that people can pause it. This helps deaf visitors and everyone scrolling in a quiet office or a loud train.
Respect motion and zoom
Some people feel unwell from large moving animations, so honor the reduce motion setting their system provides and keep essential motion gentle. Make sure your layout survives when text is enlarged to double its size, which many low vision visitors rely on, without content overlapping or disappearing. These same habits help small business owners reach mobile visitors, a topic we expand on in small business website design.
A short pre-launch checklist
- Every meaningful image has alt text; decorative images have empty alt.
- Text contrast meets at least 4.5 to 1 for normal text.
- The whole site can be used with a keyboard, with a visible focus outline.
- Every form field has a label and clear error messages.
- Headings follow a logical order and links make sense on their own.
- Videos have captions and nothing plays loud audio automatically.
- The layout holds together at 200 percent text size.
- Color is never the only way information is conveyed.
Run through that list before any launch and you will already be ahead of most sites on the web.
How to Test Accessibility
Fixing barriers is only half the job. You also need to check your work, and the reliable approach mixes automated tools with real human testing. Neither one is enough on its own.
Automated tools
Automated checkers scan your pages and flag issues like missing alt text, low contrast, and unlabeled fields. They are fast, free, and a great first pass. Browser based tools and command line checkers can be run on every page and even wired into your build process so problems are caught before they ship. The important caveat is that automated tools catch only part of the picture, often less than half of all issues. They can tell you an image lacks alt text, but they cannot tell you whether the alt text you wrote is meaningful. Treat them as a smoke detector, not a full inspection.
Manual testing
The checks that matter most are the ones a tool cannot do. Unplug your mouse and navigate the whole site with the keyboard. Turn on a screen reader, which is built into every major operating system at no cost, and try to complete a real task such as finding a product and filling the form. Zoom the text to 200 percent and see if the layout survives. Turn your display to grayscale for a moment to confirm you are not relying on color alone. These manual passes surface the problems that break real journeys.
Testing with real people
The gold standard is to watch people who actually use assistive technology try your site. They will find issues that neither tools nor your own manual testing reveal, because they use the software fluently and expect it to behave in particular ways. For a critical site, this kind of testing is well worth arranging.
Accessibility is not a one time certificate. Every new page, feature, or content update can introduce a barrier, so the testing loop should run regularly, not just once at launch. Folding these checks into your normal release routine keeps the site accessible over time. Our overview of ongoing website maintenance services explains how this fits alongside other upkeep.
Accessibility and SEO
Here is a pleasant surprise for anyone focused on traffic. The habits that make a site accessible also help it rank in search. This is not a coincidence. Search engines and screen readers both read the same underlying structure of your page, so when you make that structure clear for one, you make it clear for the other.
Consider a few overlaps. Alt text describes images to a screen reader and also tells a search engine what an image shows, which helps image search. A logical heading structure helps a screen reader user skim a page and helps a search engine understand what the page is about. Descriptive link text that reads well out of context is exactly what search engines prefer over generic click here. Captions and transcripts give search engines text to index from otherwise silent media. Fast, clean, well structured code loads quicker, and speed is a ranking factor as well as an accessibility win for people on older devices.
There is also the matter of engagement. When people can actually use your site, they stay longer, bounce less, and convert more, and those signals feed back into your search performance over time. In other words, accessibility and search visibility are pulling in the same direction. You do not have to choose between building for people and building for search, because the same work serves both. If you want a broader picture of how these pieces connect, our services overview shows where accessibility, performance, and SEO come together in a single build.
It is worth being clear about what accessibility will and will not do for rankings. It is not a magic switch that lifts a page to the top of the results overnight, and no honest agency would claim that. What it does is remove technical friction, strengthen the signals search engines already look for, and widen the audience that can reach and use your content. Think of it as clearing the road rather than pressing the accelerator. Combined with genuinely useful content and a fast, well built site, accessible markup gives every other part of your search effort a firmer foundation to stand on, and it does so while serving real people at the same time.
For deeper technical reference, two sources are worth bookmarking. The W3C Web Accessibility Initiative publishes the guidelines and plain language explanations at w3.org, and the developer documentation on developer.mozilla.org covers the practical how to for each technique. Both are free, reputable, and kept current.
Getting Started the Right Way
If all of this feels like a lot, remember that you do not have to do everything at once, and you do not have to do it alone. Accessibility is a practice you build up, not a switch you flip. The most effective approach is to start with the barriers that affect the most people, prove your progress with testing, and keep the habits going as your site grows.
A sensible order of operations looks like this. First, fix the high impact basics: contrast, alt text, keyboard access, and form labels. These alone remove a large share of real barriers and reduce legal risk quickly. Second, put testing in place, mixing automated scans with keyboard and screen reader checks, so new problems are caught early rather than discovered by a frustrated visitor. Third, make accessibility part of how you design and build going forward, so every new page starts accessible instead of needing a rescue later.
It also helps to name someone as the owner of accessibility, even in a small team. When it is everybody's job it tends to become nobody's job, and standards slip the moment attention drifts to the next feature. That owner does not need to be an expert on day one. They need to keep the checklist visible, make sure new pages are tested before they ship, and raise a hand when a design decision would quietly shut people out. Over a few months this turns accessibility from a scramble before launch into a normal part of how the site is built, which is exactly where you want it to live.
Be wary of treating accessibility as a box to tick once and forget. Content changes, plugins update, a new landing page goes live for a campaign, and any of those can introduce a fresh barrier. The teams that stay accessible are the ones that fold a quick check into their routine, the same way they would proofread copy or test a checkout before a busy weekend. It is a small, repeatable habit, not a heroic project, and that is what makes it sustainable for a business of any size.
If you are planning a new website, this is the ideal moment to bake accessibility in, because it costs almost nothing extra when it is part of the plan and a great deal more when it is bolted on afterward. If you have an existing site, an audit will tell you exactly where you stand and what to fix first, so you spend effort where it counts rather than guessing. Either way, the goal is the same: a site that genuinely works for every visitor, that holds up legally, and that performs better in search as a bonus.
Our team builds and audits sites to WCAG AA as a matter of course, not as an add on, and we explain the work in plain language so you always know what you are getting and why it matters. If you want a clear, honest read on your site, or you are starting something new and want it done right from the first line of code, request a free quote or get in touch with us. It takes a couple of minutes, there is no obligation, and you will come away with a concrete idea of what to do next.