What WCAG is and where it comes from
WCAG stands for Web Content Accessibility Guidelines. It is published by the World Wide Web Consortium (W3C), the organization that maintains the HTML and CSS standards underlying every website on the internet. The W3C's Web Accessibility Initiative (WAI) develops and maintains WCAG through collaboration between disability advocates, assistive technology vendors, government bodies, and web developers.
WCAG is not a government regulation. It is a technical standard that has been adopted by reference into law in many countries. The United States Department of Justice's 2022 guidance on web accessibility cites WCAG 2.1 Level AA as the practical compliance target under the Americans with Disabilities Act. The European Union's EN 301 549 standard incorporates WCAG 2.1 Level AA by reference. Section 508 of the US Rehabilitation Act, which governs federal agency websites, references WCAG 2.0 Level AA.
The standard has three conformance levels: Level A covers the most critical barriers, Level AA covers the broader set of requirements that make a site usable for most people with disabilities, and Level AAA covers additional enhancements that are often impractical to implement universally. Level AA is the practical target for legal compliance. Auditors test against it, courts reference it in ADA cases, and the DOJ identifies it as the floor for ADA compliance.
WCAG applies to four categories of users: people with visual impairments (including blindness, low vision, and color blindness), people with hearing impairments, people with motor disabilities who cannot use a standard mouse, and people with cognitive disabilities including learning differences. The audience is larger than most business owners expect. The CDC estimates that 61 million American adults live with a disability. Conditions addressed by WCAG span a wide spectrum, from permanent blindness to situational impairments like a broken arm that forces someone to navigate with a keyboard for six weeks.
The business case runs alongside the legal case. An accessible site is a site that more people can actually use, which means more customers and fewer dead-end visits from people who left because a form wouldn't work with their screen reader, or a phone number wasn't a tappable link, or a PDF menu had no text content that assistive technology could read.
WCAG 2.0, 2.1, and 2.2: what changed in each version
The standard has gone through three major versions since 2008, each adding requirements that the previous version did not address. Understanding which version is being referenced matters because auditors, lawsuits, and government standards cite specific version numbers, and the differences between versions are substantive, not cosmetic.
WCAG 2.0 (2008) established the original framework with 61 success criteria across four principles (Perceivable, Operable, Understandable, Robust). Most of the foundational requirements are here: written descriptions for images, captioned video, keyboard navigation, sufficient color contrast, labeled form fields, and clean, well-organized page code underneath. Level AA for WCAG 2.0 is still referenced by Section 508 and older procurement standards. If you are dealing with a contract or requirement that cites this version, conformance to WCAG 2.1 AA satisfies it as well, since 2.1 is backward compatible with 2.0.
WCAG 2.1 (2018) added 17 new success criteria addressing three areas that 2.0 had left underspecified: mobile accessibility, cognitive disabilities, and low vision. The additions include Reflow (1.4.10), requiring content to be usable at 320px wide without horizontal scrolling; Non-text Contrast (1.4.11), extending contrast requirements to UI components like form borders and button backgrounds; Text Spacing (1.4.12), requiring content to remain readable when users override line height, letter spacing, and word spacing; Content on Hover or Focus (1.4.13), governing tooltips and popups that appear on hover; and Pointer Gestures (2.5.1), requiring alternatives to multipoint gestures, among others. Most ADA lawsuits reference this version's Level AA standard as of 2026.
WCAG 2.2 (2023) added 9 more criteria, primarily addressing keyboard navigation and cognitive accessibility. The most significant additions: Focus Appearance (2.4.11), requiring focus indicators to meet minimum size and contrast thresholds; Target Size (Minimum) (2.5.8), requiring interactive elements to be at least 24x24 pixels; and Accessible Authentication (Minimum) (3.3.8), restricting the use of cognitive function tests like CAPTCHAs in authentication flows. WCAG 2.2 removed criterion 4.1.1 (Parsing), which had caused confusion since modern browsers handle HTML parsing robustly.
The practical recommendation: audit and build to WCAG 2.2 Level AA where feasible. The additional criteria in 2.2 are substantively important for keyboard users and people with cognitive disabilities, and building to 2.2 now avoids having to retrofit the gap later as more standards catch up to the newer version.
The four POUR principles: what they require in practice
Every WCAG success criterion belongs to one of four principles: Perceivable, Operable, Understandable, and Robust, commonly abbreviated as POUR. The principles form the framework; the success criteria are the specific, testable requirements within them. Here's what each principle requires in concrete, testable terms for a typical small business website.
Perceivable means users must be able to perceive all content and interface components, regardless of their sensory ability. In practice this covers: all non-decorative images have alt text that describes their meaning (not just their filename); video with meaningful audio has accurate captions; audio-only content has a transcript; content does not rely on color alone to convey information (a form highlighting required fields in red needs another indicator: an asterisk, a label, or an icon); text has sufficient contrast against its background (4.5:1 for normal text, 3:1 for text above 18pt or 14pt bold, 3:1 for UI component borders and state indicators); content does not break when text spacing is overridden; and content appearing on hover or focus is dismissible, persistent, and hoverable.
Operable means all interface components and navigation must be operable. For a small business website the most critical requirements are: every link, button, form field, dropdown, modal, tab panel, accordion, and carousel must be reachable and functional using only the keyboard (commonly Tab to move forward, Shift+Tab to move back, Enter or Space to activate, Escape to close dialogs, and arrow keys for within-component navigation); there are no keyboard traps where focus enters a component and cannot leave without a mouse; nothing on the page flashes more than three times per second; if time limits exist (session expiration, form submission timers), users get adequate warning and the ability to extend; and skip navigation links allow keyboard and screen reader users to bypass repeated navigation on every page.
Understandable means content and interface behavior must be understandable and predictable. Requirements here include: the page declares what language it's written in so screen readers pronounce the words correctly; navigation and page structure are consistent across pages; labels are persistent (the placeholder-as-label pattern fails because placeholder text disappears when the user starts typing); error messages identify which field has an error and describe the correct format; required fields are labeled as required; and pages do not trigger major changes (navigation, form submission, focus shift) without user intention.
Robust means content must be interpretable by current and future assistive technologies. This is primarily about clean, well-organized page code: headings that reflect the actual structure of the content (not just bigger fonts), lists that are built as real lists, buttons that are real buttons a keyboard can operate rather than ordinary boxes wired to respond only to a mouse click, and form fields that are correctly connected to their labels behind the scenes. When the underlying code is built correctly, screen readers read the page reliably across the different software combinations people use. When the code is a tangle of generic containers with scripting bolted on top, different screen reader and browser combinations produce inconsistent, broken results for people using assistive technology.
Common failures that show up in ADA demand letters
ADA web accessibility demand letters cite specific WCAG violations found on specific pages of your site. Plaintiffs' firms use automated tools to scan thousands of sites at once, flag violations, and send templated letters to site owners. Violations appearing most consistently in demand letters correspond to issues that automated tools catch reliably, meaning certain failures generate vastly more legal exposure than others.
Missing or inadequate image descriptions. This is the most common violation in ADA cases and the one automated tools catch most reliably. Every meaningful image needs a written description that a screen reader can read aloud to a blind visitor. Images used as links need a description of where the link goes, not what the picture looks like. Purely decorative images should be marked so screen readers skip them entirely. The failures that generate demand letters: images with no description at all, images described only as "image" or "photo," linked images with no description (the screen reader just reads out the raw web address instead), and complex images like charts or infographics with no text equivalent at all.
Insufficient color contrast. WCAG 2.1 AA requires 4.5:1 contrast ratio for normal text and 3:1 for large text (18pt or 14pt bold) and UI components. Common failures: light gray body text on white backgrounds, which many design templates use by default; pale button text on medium-background buttons; placeholder text in form fields, which is often styled at very low contrast by design; and text over partially transparent overlay images, where contrast varies based on which part of the image is behind the text.
Forms whose fields aren't properly labeled. A very common shortcut is using the faint grey hint text inside a box as if it were the field's label, and that fails WCAG at Level AA because the hint disappears the moment someone starts typing. Every box a visitor types or chooses from, whether it's a text field, a dropdown, or a comment box, needs a real label that's wired to it behind the scenes so a screen reader can announce what the field is for. Required fields need to be marked as required in a way that doesn't rely on color alone. And error messages need to be tied to the exact field that has the problem, so a blind user knows which one to fix.
Video without captions. Any video with meaningful audio dialogue or narration needs accurate captions. Auto-generated captions from YouTube or Vimeo are a starting point but often miss details: proper nouns, technical terms, and overlapping dialogue get transcribed incorrectly. WCAG 1.2.2 requires synchronized captions on prerecorded media. Captions need to be accurate, timed correctly, and include non-speech audio cues (like "[music plays]" or "[phone rings]") where those cues carry meaning.
Keyboard navigation failures in custom JavaScript components. Dropdown menus that only open on hover, modal dialogs that trap keyboard focus or do not return focus to the triggering element when closed, tab panels that require a mouse click to switch, image carousels with no keyboard controls, and date pickers that have no keyboard interface all fail WCAG 2.1.1 (Keyboard) and 2.1.2 (No Keyboard Trap). Automated tools can flag some of these, but the only reliable way to find them is to navigate the entire site with a keyboard, attempting to use every interactive element without touching the mouse.
Missing skip navigation links. WCAG 2.4.1 requires a mechanism to bypass blocks of content that repeat on multiple pages, primarily navigation. Without a "Skip to main content" link at the top of every page, keyboard and screen reader users must tab through every navigation item on every page before reaching the page's actual content. This is technically a Level A requirement, one of the most basic accessibility requirements, and it is absent on a significant fraction of small business sites.
What automated tools catch and what they miss
Automated accessibility testing tools (axe-core, WAVE, Lighthouse's accessibility audit, Deque WorldSpace, Tenon) are valuable for establishing a baseline and finding violations that pattern-matching can reliably detect. Understanding their actual coverage and what they categorically cannot test is critical for understanding why a credible accessibility audit cannot stop at a tool report.
Research consensus places automated tools at catching between 25% and 40% of real WCAG Level AA failures, depending on the tool, site complexity, and failure category. The WebAIM Million study, which runs automated accessibility tests against the top million web pages, consistently finds that pages with more complex content and richer interactivity have higher numbers of failures automation can detect. This is partly because automated tools are better at finding some violation types than others.
What automation catches reliably: images with no written description at all (though not whether the description is meaningful or accurate); text-and-background color combinations that don't have enough contrast; missing or duplicate page titles; pages that never declare what language they're in (which makes screen readers mispronounce everything); accessibility labels applied incorrectly in the code; form fields with no label connected to them; missing heading structure; and keyboard outlines that the design has deliberately hidden.
What automation cannot test: whether an image description is actually meaningful ("photo of Dr. Smith in the clinic" vs. just "photo"); whether the keyboard moves through the page in a sensible order; whether a custom dropdown menu actually responds to the arrow keys; whether a popup window hands keyboard focus back where it belongs when it's closed; whether a page that looks like it has a clear heading structure actually conveys that structure to a screen reader; whether the order a screen reader reads things in still makes sense without the visual layout; whether an error message is connected to the right field; and whether someone can navigate the whole page start to finish using only a keyboard.
The practical implication: an audit that runs an automated tool and delivers a report is not an accessibility audit. It is a coverage report for 25–40% of possible failures. The remaining 60–75% require manual testing. For legal defensibility, manual testing with a keyboard and with screen readers (NVDA on Windows, VoiceOver on Mac and iOS, TalkBack on Android) is the only way to find and document the full failure inventory. See what a full audit and remediation involves →
Why accessibility overlay widgets make things worse
Accessibility overlay widgets are browser-side JavaScript products sold by companies like AccessiBe, UserWay, AudioEye, EqualWeb, and others. The pitch is consistent: add one line of script to your site, and the overlay fixes accessibility issues automatically, making your site WCAG compliant without code-level changes. The pitch is false in a specific, documentable way.
Overlays cannot fix accessibility at the source. They run in the visitor's browser only after the page has already loaded. They can make a few surface-level tweaks: bolting machine-generated descriptions onto images that have none (with wildly variable quality), nudging some color contrast values, and enlarging fonts. What they cannot do is build the underlying page structure that was never there in the first place, make keyboard controls work on menus and widgets that were never built to respond to a keyboard, fix where focus lands when a popup opens and closes, or write a genuinely meaningful description for a complex image that takes human judgment.
The evidence that overlays cause harm to disabled users comes from disabled users themselves. The #OverlayFact Sheet, a statement signed by hundreds of disabled people and accessibility professionals, documents that overlays commonly conflict with screen readers, in some cases making pages that were partially usable before the overlay completely unusable afterward. Users who have customized their browser or assistive technology settings find those settings overridden by overlay behavior they cannot opt out of.
The legal track record of overlays is poor. Multiple ADA lawsuits against companies using AccessiBe and similar products resulted in settlements or judgments against defendants, with courts finding that overlays did not achieve compliance. In some cases the overlay aggravated the plaintiffs' experience. Companies that purchase overlays as a compliance solution and then receive a demand letter are in a worse negotiating position because the overlay demonstrates awareness of the issue and failure to address it at the code level.
The cost comparison is also worth noting. Overlay widgets typically run $50–$500 per month on a subscription basis. A full WCAG audit and code-level remediation on a small business site is a one-time cost. Ongoing compliance maintenance to keep a site accessible as it grows is a much smaller recurring cost than an overlay subscription. The overlay is a more expensive option that achieves less and creates legal exposure rather than reducing it.
PDF accessibility: the overlooked gap in most remediations
PDFs are the most commonly overlooked accessibility gap on small business websites and the source of greatest friction for screen reader users in practice. A screen reader uses the underlying structure of a web page (its headings, its labeled regions, its well-organized sections) to give users a map of the page and let them jump straight to the part they want. A PDF lacking document structure tags is effectively a flat image to a screen reader: no headings to navigate, no reading order, no accessible form fields, no table structure. The content is inaccessible from top to bottom.
The types of PDFs most commonly found on small business sites: restaurant menus and price lists, service brochures and capability statements, intake forms and appointment request forms, terms and conditions documents, and certificates or awards. Any PDF with meaningful content that a visitor might need to read and understand needs to be accessible.
What accessible PDF tagging requires: a document title set in the Properties panel; a tag tree that includes paragraph tags, heading tags (H1 through H6), list tags, table tags with proper header row identification, figure tags with alt text for images, and artifact tags for purely decorative elements; reading order that matches the visual order (especially critical in multi-column layouts, where a naive reading order will interleave text from both columns rather than completing the first column before starting the second); form fields with accessible names and tooltips; and a document language setting.
The most common source of inaccessible PDFs is the export process. Word, InDesign, Illustrator, and design tools can all generate PDFs, but tagging quality depends on how the source document was structured and which export settings were used. A Word document with proper heading styles exported with correct accessibility settings produces a reasonably well-tagged PDF. An InDesign layout with no heading styles exported to PDF as a flat graphic produces an untagged PDF requiring complete manual remediation in Acrobat Pro.
For menus and service lists specifically, there is a practical alternative to PDF: build the content as HTML pages. A menu or service list as a proper HTML page is more accessible by default, loads faster, is indexable by search engines (PDFs are harder for Google to parse and rank), and can be updated without regenerating and uploading a new file. If the PDF serves a purpose that an HTML page cannot (a printable formatted document, a fillable form that needs to be printed and signed), then the PDF needs to be tagged properly. If the only reason for the PDF is habit or convenience, consider converting to HTML.
One-time fix vs. ongoing compliance
A one-time remediation fixes the accessibility failures that exist on the site at the time of the audit. It does not prevent new failures from being introduced as the site is updated. This distinction matters because the most common pattern for accessibility regression on small business sites is not a system failure but normal content management.
The most common sources of post-remediation accessibility drift: new images added to pages without alt text; new blog posts or service pages added without correct heading hierarchy; new contact forms or intake forms added without proper label associations; third-party widgets embedded on the site (live chat, appointment booking, review display) that introduce their own accessibility failures; and new interactive JavaScript components (carousels, FAQs, lightboxes) added from a library or plugin without testing for keyboard navigation.
For sites that are updated infrequently (a five-page small business site that essentially stays the same once it is built), a periodic re-audit every 12–18 months is typically sufficient. Any significant content additions should be reviewed at the time they are made, but for largely static sites, the risk of drift is low and a scheduled re-audit can catch anything that has accumulated.
For sites that are updated regularly (a restaurant that changes its menu seasonally, a contractor that adds project photos regularly, a professional services firm that publishes blog content), some form of ongoing accessibility review makes more sense. This can be structured as an add-on to a maintenance plan: new content goes through a quick accessibility review before it goes live, catching failures before they accumulate and before they reach the automated scanners that plaintiffs' firms use.
An accessibility statement on your site also matters for ongoing compliance. WCAG 2.1 does not require an accessibility statement, but it is good practice and relevant in legal contexts. An accessibility statement documents your conformance target (WCAG 2.1 Level AA), the date of your last audit, any known limitations and planned remediation timeline, and a contact mechanism for users encountering barriers. A current, accurate accessibility statement with a response mechanism demonstrates ongoing good-faith effort, which courts and settlement negotiations treat differently from a site with no evidence of having addressed accessibility.
The practical approach for most small business sites: do the full remediation, ensure ongoing site updates go through a basic accessibility check before publishing, run a periodic re-audit on schedule, and maintain an accessibility statement with contact email. This keeps the site defensible without requiring permanent compliance overhead disproportionate to the site's size.
Website maintenance plans that include accessibility monitoring →
Key takeaways
- WCAG 2.1 Level AA is the practical compliance target for US small business websites. The DOJ's 2022 guidance explicitly cites it for ADA compliance.
- The four POUR principles (Perceivable, Operable, Understandable, Robust) structure all 78 WCAG 2.1 success criteria. Missing image descriptions, insufficient color contrast, unlabeled forms, and keyboard navigation failures are the most common violations found in demand letters.
- Automated tools catch 25–40% of WCAG failures. Manual keyboard testing and screen reader testing are required to find the rest. An audit that stops at an automated scan leaves the majority of violations in place.
- Accessibility overlay widgets (AccessiBe, UserWay, etc.) are not a compliance solution. They cannot fix accessibility at the code level, they degrade the experience of screen reader users, and they appear in lawsuits as evidence of non-compliance rather than a defense.
- PDFs on your website require their own accessibility remediation. An untagged PDF exported from Word or a design tool is effectively inaccessible to screen readers. For menus and service lists, converting to HTML is often the better solution.
- A one-time remediation addresses current failures but does not prevent new ones. Some form of ongoing accessibility review, built into the content publishing process or the maintenance plan, keeps the site defensible as it grows.
- An accessibility statement with your conformance target, last audit date, known limitations, and a contact mechanism demonstrates ongoing good-faith effort and is relevant in any legal context.