Website Accessibility in 2026: A Design Guide for Compliance

When discussions about website accessibility come up, many business owners instinctively think about legal compliance. They picture checklists, audits, and the looming threat of lawsuits. While the legal dimension is real and growing, reducing accessibility to a compliance checkbox misses something fundamental about why it matters. Accessibility is, at its core, about whether the people you want to reach can actually use the thing you built. A website that excludes 15 to 20 percent of the population isn't just non-compliant. It's a business that has decided, whether intentionally or through neglect, that a significant portion of potential customers aren't worth serving.

The numbers are striking. Over one billion people worldwide live with some form of disability. In the United States alone, people with disabilities represent a market with over $490 billion in disposable income. In the EU, the European Accessibility Act takes full effect in 2025, creating binding legal obligations for digital services. Website accessibility lawsuits in the US exceeded 4,600 in 2023 and the trajectory continues upward. But beyond the statistics, there's a more practical reality: accessibility improvements tend to make websites better for everyone. Clearer navigation, better contrast, more logical content structure, proper heading hierarchy — these aren't niche accommodations. They're markers of thoughtful, well-crafted design, the kind of design that separates a truly good website from a merely acceptable one.

Understanding WCAG 2.2 and What Changed

The Web Content Accessibility Guidelines, maintained by the World Wide Web Consortium, are the global standard for web accessibility. WCAG 2.2, released in late 2023, builds on its predecessors with nine new success criteria that address gaps identified through years of real-world implementation. Understanding what changed and why helps frame the practical work of making websites accessible.

The most significant additions in WCAG 2.2 address authentication and interaction patterns that have become increasingly common. The "Accessible Authentication" criteria recognize that cognitive load during authentication is a genuine barrier. Requiring users to memorize or transcribe complex passwords, solve CAPTCHAs, or complete multi-step verification puzzles excludes people with cognitive disabilities, memory impairments, and learning differences. The standard now requires that authentication mechanisms offer at least one method that doesn't rely on cognitive function tests. In practice, this means supporting password managers, biometric login, or passkeys alongside traditional authentication.

The "Dragging Movements" criterion addresses a pattern that became ubiquitous as interactive web applications proliferated. Any functionality that requires a dragging motion must also be achievable through a simple pointer action like a click or tap. This helps users with motor impairments, tremors, or anyone using assistive technology that cannot simulate drag operations. The "Target Size" criteria, meanwhile, set minimum dimensions for interactive elements. Clickable and tappable targets must be at least 24 by 24 CSS pixels, with a 44 by 44 pixel recommendation for optimal usability. This benefits not only users with motor disabilities but anyone using a website on a small touchscreen — which, given mobile usage statistics, is the majority of your visitors.

Color Contrast and Visual Accessibility

Visual accessibility begins with contrast, and it's one of the areas where the gap between design aesthetics and actual usability is widest. Designers often favor subtle color palettes, muted tones, and low-contrast text for a perceived sense of sophistication. The problem is that approximately 300 million people worldwide have color vision deficiency, and many more experience reduced contrast sensitivity due to aging, screen glare, or environmental conditions. A design that looks elegant on a calibrated monitor in a dim studio may be unreadable on a phone screen in direct sunlight.

WCAG 2.2 maintains the contrast requirements established in earlier versions: a minimum ratio of 4.5:1 for normal text and 3:1 for large text (18 point or 14 point bold). Non-text elements like form field borders, icons, and graphical objects that convey meaning must also meet the 3:1 ratio. These aren't arbitrary numbers. They're based on research into the contrast sensitivity function of human vision, accounting for the range of visual acuity in the general population. Meeting these ratios doesn't require abandoning your brand palette — it requires being intentional about where and how you use each color.

Beyond contrast ratios, color should never be the sole means of conveying information. A form that indicates errors only by turning the field border red is invisible to someone with red-green color blindness. A chart that distinguishes data series only through color is meaningless to a significant portion of viewers. Every instance where color communicates meaning should be reinforced with a secondary indicator: an icon, a text label, a pattern, or a shape change. This principle of redundant encoding makes your designs more robust not just for accessibility, but for any degraded viewing condition — a cracked screen, low battery brightness, or a projector in a well-lit room.

Keyboard Navigation: The Foundation of Accessible Interaction

If there's a single test that reveals the most about a website's accessibility, it's this: put your mouse away and try to use the site with only a keyboard. Can you reach every interactive element? Can you tell which element currently has focus? Can you activate buttons, submit forms, open and close menus, and navigate through content in a logical order? If the answer to any of these is no, the site has fundamental accessibility problems.

Keyboard accessibility matters because it's the foundation upon which most assistive technologies operate. Screen readers, switch devices, voice control software, and sip-and-puff devices all ultimately interact with the web through keyboard-like input. When a website breaks keyboard navigation, it doesn't just inconvenience keyboard users — it potentially locks out users of every assistive technology that relies on keyboard input patterns. This is why WCAG considers keyboard accessibility a Level A requirement, the most fundamental compliance level.

The practical implementation starts with HTML semantics. Using native HTML elements for their intended purpose — buttons for actions, links for navigation, form elements for input — provides keyboard accessibility without additional effort. The problems arise when developers build custom interactive components using generic elements like divs and spans, which have no inherent keyboard behavior. Every custom component needs explicit keyboard handling: tabindex for focus management, key event listeners for activation, ARIA roles and states to communicate the component's purpose and current state to assistive technology. A skip-to-content link at the top of the page, visible on focus, saves keyboard users from tabbing through the entire header and navigation on every page load. Focus management during dynamic content changes — like opening a modal or loading new content — ensures users aren't left stranded at an irrelevant position in the page.

Making Your Site Work with Screen Readers

Screen readers translate visual interfaces into speech or braille output, and they rely entirely on the semantic structure of your HTML to construct a meaningful representation of the page. What sighted users perceive through visual hierarchy, layout, and spatial relationships must be communicated through proper heading structure, landmark regions, alternative text, and ARIA attributes. When these are done well, screen reader users get an experience that's genuinely equivalent to the visual one. When they're done poorly, the experience ranges from confusing to completely unusable.

Heading structure is the backbone of screen reader navigation. Users frequently navigate by jumping between headings, much like sighted users scan a page by reading the bold section titles. Headings must follow a logical hierarchy: one H1 per page describing the primary content, H2s for major sections, H3s for subsections within those, and so on. Skipping levels — jumping from H2 to H4, for instance — creates confusion about the content's organizational structure. Headings should describe the content of their section, not be used merely for visual styling. If you need text to look like a heading but it's not actually a heading, use CSS to style it appropriately instead.

Alternative text for images is perhaps the most well-known accessibility requirement, and also one of the most frequently done poorly. Good alt text describes what the image communicates in the context where it appears, not just what the image contains. A product photo's alt text should describe the product in a way that helps a purchasing decision. A team photo's alt text should describe who's in the image and what it conveys about the company. Decorative images that don't add meaningful content should have empty alt attributes so screen readers skip them entirely. Informational images, charts, and infographics need detailed descriptions, either as alt text or through associated text content. The goal is information equivalence — a screen reader user should get the same information and be able to make the same decisions as a sighted user.

Accessible Forms and Interactive Elements

Forms are where accessibility failures have the most direct business impact. A checkout form that's inaccessible means lost sales. A contact form that can't be completed means lost leads. A signup form that doesn't work with assistive technology means lost users. And yet forms are one of the most consistently problematic areas of web accessibility, often because developers focus on visual design while neglecting the semantic structure that makes forms usable for everyone.

Every form input needs a programmatically associated label. This means using the HTML label element with a for attribute that matches the input's ID, or wrapping the input within the label element. Placeholder text is not a substitute for labels — it disappears when the user starts typing, leaving them with no indication of what the field expects. Required fields should be indicated both visually and programmatically, using the required attribute or aria-required. Error messages must be associated with their corresponding inputs using aria-describedby or similar mechanisms, so screen reader users know which field has an error and what the error is.

Form validation should be helpful, not hostile. Real-time validation that provides feedback as users complete fields is more accessible than validation that only fires on submission, forcing users to hunt for errors in a form they've already moved past. Error messages should be specific and instructive: "Email address must include an @ symbol" is vastly more helpful than "Invalid input." Success states should be announced to screen readers using live regions or focus management. For multi-step forms, progress indicators should be both visual and semantic, clearly communicating where the user is in the process and how many steps remain. Our exploration of designing for trust examines how form design directly influences whether users feel confident enough to complete their submission.

Media Accessibility: Alt Text, Captions, and Transcripts

Multimedia content presents distinct accessibility challenges because it delivers information through channels that may not be available to all users. Video content is inaccessible to deaf and hard-of-hearing users without captions. Audio content like podcasts is inaccessible without transcripts. Visual content in videos is inaccessible to blind users without audio descriptions. Each media type requires its own accessibility approach, and the solutions benefit a much wider audience than you might expect.

Captions for video content are a WCAG Level A requirement, meaning they're non-negotiable for any level of compliance. But their value extends far beyond accessibility. Studies show that 80 percent of people who use captions are not deaf or hard of hearing. They're watching in noisy environments, in quiet environments where they can't use audio, learning the language, or simply finding that captions improve comprehension. Auto-generated captions have improved dramatically with AI advances, but they still require review and correction, especially for technical content, proper nouns, and specialized vocabulary. Inaccurate captions can be worse than no captions if they distort the meaning of the content.

Transcripts serve a complementary purpose. While captions are synchronized to the video timeline, transcripts provide a complete text version of the audio content that users can read at their own pace, search through, or consume with a screen reader. For podcasts and audio-only content, transcripts are the primary accessibility mechanism. They're also valuable for SEO, since search engines can index transcript text but cannot parse audio content. Audio descriptions — narration added during natural pauses in dialogue to describe relevant visual information — serve users who cannot see the video. For content-heavy videos like tutorials or presentations, audio descriptions ensure that visual demonstrations, on-screen text, and important visual context are communicated verbally.

Testing for Accessibility

Accessibility testing is not something you do once and declare done. It's an ongoing practice that should be integrated into your development workflow, much like security testing or performance monitoring. The most effective testing combines automated tools with manual verification, because each catches issues the other misses. Automated tools can scan for missing alt text, insufficient contrast, and structural problems, but they cannot evaluate whether alt text is actually meaningful, whether the reading order makes sense, or whether a complex interactive component is genuinely usable.

Several automated tools provide a solid starting point. axe, developed by Deque Systems, is widely regarded as the most accurate automated accessibility testing engine and integrates into browsers as a developer extension, into CI/CD pipelines for automated testing, and into testing frameworks for component-level verification. WAVE, from WebAIM, provides a visual overlay that highlights accessibility issues directly on the page, making it particularly useful for designers and content creators. Lighthouse, built into Chrome DevTools, includes an accessibility audit as part of its broader site quality assessment. Running all three catches a wider range of issues than relying on any single tool.

Manual testing should follow a consistent protocol. Navigate the entire site using only a keyboard, checking that every interactive element is reachable, visible when focused, and operable. Test with at least one screen reader — VoiceOver on macOS, NVDA or JAWS on Windows — completing key user journeys like finding information, filling out forms, and completing a purchase. Check content at 200 percent zoom to verify that layouts remain usable and no content is cut off. Test with browser extensions that simulate color blindness, reduced contrast, and other visual impairments. If your budget allows, include testing with actual users who have disabilities — their feedback reveals usability problems that no automated tool or simulation can catch.

Building Accessibility Into the Design Process From the Start

The most common and costly mistake organizations make with accessibility is treating it as a remediation task rather than a design principle. Retrofitting accessibility onto a completed website is dramatically more expensive and less effective than building it in from the beginning. Studies from the Systems Sciences Institute at IBM found that fixing a defect in production costs six times more than fixing it during design. For accessibility specifically, the multiplier is often higher because accessibility fixes frequently require structural changes to HTML that cascade through templates and components.

Accessibility should be a consideration in every phase of the design process. During research and strategy, understanding your audience includes understanding the range of abilities, devices, and contexts in which they'll access your site. During wireframing and prototyping, establishing heading hierarchy, focus order, and content structure ensures that the semantic foundation is solid before visual design begins. During visual design, contrast checking, text sizing, and touch target dimensions should be validated against WCAG criteria, not approximated. During development, semantic HTML, keyboard handling, and ARIA implementation should be reviewed in code review, not deferred to a post-launch audit.

Design systems and component libraries are the leverage point for sustainable accessibility. When you build accessibility into a button component, every button in your application inherits that accessibility. When you build an accessible form field component, every form benefits. This component-level approach means that accessibility isn't something each developer needs to remember and implement individually — it's baked into the building blocks they use. The investment in making your component library fully accessible pays dividends across every page, every feature, and every future update. At PinkLime, we treat accessibility as a design fundamental rather than a compliance afterthought, ensuring that the websites we build work for everyone from day one. If you're planning a new site or evaluating an existing one, understanding the full picture of what makes a good website includes accessibility as a core criterion, not an optional extra.