Designing Your Website for WCAG 2.1 AA Compliance

1. What is WCAG 2.1 AA Compliance?
2. The Four POUR Principles
3. Most Common Compliance Issues and How to Fix Them
4. Essential Testing Tools
5. The Business Case for Accessibility
6. Frequently Asked Questions

WCAG stands for Web Content Accessibility Guidelines, developed by the World Wide Web Consortium (W3C) to provide a single shared standard for web accessibility. Version 2.1, released in 2018, builds on WCAG 2.0 with additional success criteria addressing mobile accessibility, people with low vision, and people with cognitive and learning disabilities.

The guidelines are organized into three conformance levels:

• Level A: The minimum level of accessibility, addressing the most severe barriers
• Level AA: The target standard for most organizations, addressing major barriers to access
• Level AAA: The highest level, though full conformance is not always possible for all content

WCAG 2.1 AA compliance means your website meets all Level A and Level AA success criteria. This is the level required by most accessibility laws worldwide, including Section 508 in the United States, the European Accessibility Act, and similar legislation in Canada, Australia, and many other jurisdictions.

Every WCAG success criterion falls under one of four foundational principles. Understanding these principles helps you think about accessibility holistically rather than as a checklist.

Perceivable

Information and user interface components must be presentable to users in ways they can perceive. This means:

• Providing text alternatives for non-text content like images, icons, and graphs
• Offering captions and transcripts for audio and video content
• Creating content that can be presented in different ways without losing meaning
• Making it easier for users to see and hear content, including sufficient color contrast

Real-world example: A "Play" button represented only by a triangle icon fails this principle. Screen reader users cannot perceive its purpose. Adding aria-label="Play video" or visible text makes it perceivable to everyone.

Operable

User interface components and navigation must be operable by all users. This includes:

• Making all functionality available from a keyboard
• Giving users enough time to read and use content
• Avoiding content that causes seizures or physical reactions
• Helping users navigate, find content, and determine where they are
• Making it easier to use inputs other than keyboard

Real-world example: Dropdown menus that only work on hover are not keyboard-operable. Users navigating with keyboards, voice control, or switch devices cannot access the menu items.

Understandable

Information and operation of the user interface must be understandable. This means:

• Making text readable and understandable
• Making content appear and operate in predictable ways
• Helping users avoid and correct mistakes

Real-world example: A form that clears all fields when a single error occurs is not understandable or helpful. Users should receive clear error messages identifying which fields need correction, with their previously entered data preserved.

Robust

Content must be robust enough to be interpreted reliably by a wide variety of user agents, including assistive technologies. This involves:

• Maximizing compatibility with current and future tools
• Using valid, semantic HTML
• Providing name, role, and value for all user interface components

Real-world example: Custom widgets built entirely with div elements and CSS, without proper ARIA attributes, fail the robust principle. Screen readers cannot determine what these elements are or how to interact with them.

Based on the WebAIM Million annual accessibility analysis, these issues appear on over 90% of home pages tested.

1. Low Color Contrast

The problem: Text that doesn't have sufficient contrast against its background is difficult or impossible for users with low vision or color blindness to read.

The standard: WCAG 2.1 AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18pt or 14pt bold and larger).

How to fix it:

• Use a color contrast checker during the design phase
• Avoid placing text over busy background images without sufficient overlay
• Don't rely on color alone to convey information (use icons, patterns, or text labels as well)
• Test your color palette with tools like WebAIM's Contrast Checker or the built-in checker in Figma

2. Missing Alternative Text for Images

The problem: Screen readers cannot describe images without alternative text, leaving users unable to access important visual information.

The standard: All informative images must have descriptive alt text. Decorative images should have empty alt attributes (alt="") so screen readers skip them.

How to fix it:

• Write alt text that describes the content and function of the image
• For complex images like charts or diagrams, provide both alt text and a longer description nearby
• Don't start with "Image of..." or "Picture of..." as screen readers already announce it's an image
• For decorative images, use alt="" to mark them as decorative

Example:

<!-- Poor -->
<img src="team-photo.jpg" alt="team">

<!-- Better -->
<img src="team-photo.jpg" alt="Huston Design team of eight people gathered around a conference table during a brainstorming session">

<!-- Decorative image -->
<img src="decorative-swoosh.svg" alt="" role="presentation">

3. Non-Descriptive Link Text

The problem: Link text like "click here" or "read more" doesn't provide context when read in isolation, which is how many screen reader users navigate pages.

The standard: Link text must make sense out of context and clearly describe the link destination.

How to fix it:

• Use descriptive link text that identifies the destination or action
• Avoid generic phrases like "click here," "more," or "continue"
• Keep link text concise but meaningful
• If you must use generic text, add aria-label or sr-only text for context

Example:

<!-- Poor -->
<a href="/services">Click here</a> to learn about our services.

<!-- Better -->
Learn about our <a href="/services">web design and development services</a>.

<!-- Or -->
<a href="/services">View our web design and development services</a>

4. Missing Form Labels

The problem: Form inputs without properly associated labels are unusable for screen reader users, who cannot determine what information to enter.

The standard: Every form input must have a programmatically associated label element.

How to fix it:

• Use the label element with a for attribute matching the input's id
• Don't rely solely on placeholder text, which disappears when users start typing
• Group related inputs with fieldset and legend elements
• Provide clear error messages associated with the relevant inputs

Example:

<!-- Poor -->
<input type="email" placeholder="Email">

<!-- Better -->
<label for="email">Email Address</label>
<input type="email" id="email" name="email" required>

<!-- With error message -->
<label for="email">Email Address</label>
<input type="email" id="email" name="email" aria-describedby="email-error" aria-invalid="true" required>
<span id="email-error" class="error">Please enter a valid email address</span>

5. Insufficient Keyboard Navigation

The problem: Elements that only respond to mouse events exclude keyboard users, including many people with motor disabilities and power users who prefer keyboard navigation.

The standard: All functionality must be operable through a keyboard interface. Users must be able to see where keyboard focus is at all times.

How to fix it:

• Ensure all interactive elements can receive keyboard focus
• Make focus indicators visible and with sufficient contrast
• Maintain a logical tab order that follows the visual layout
• Provide skip links to bypass repetitive navigation
• Don't trap keyboard focus in modals or widgets

Example:

/* Ensure focus is always visible */
a:focus, button:focus, input:focus {
  outline: 2px solid #0066cc;
  outline-offset: 2px;
}
/* Never use outline: none without providing an alternative focus indicator */

6. Inaccessible Custom Widgets

The problem: Custom dropdowns, tabs, accordions, and other widgets built without proper ARIA attributes are invisible or unusable to assistive technologies.

The standard: Custom widgets must use appropriate ARIA roles, states, and properties to communicate their purpose and state to assistive technologies.

How to fix it:

• Follow WAI-ARIA Authoring Practices for common widget patterns
• Test custom components with actual screen readers
• Consider using accessible component libraries rather than building from scratch
• Ensure keyboard interactions match expected patterns (Arrow keys for tabs, Enter/Space for buttons, etc.)

Automated testing can catch approximately 30-40% of accessibility issues. Manual testing and testing with real users is essential for comprehensive compliance.

Automated Testing Tools

Browser Extensions:

• axe DevTools (Free and paid versions) - Comprehensive testing with clear issue descriptions
• WAVE - Visual feedback showing where accessibility features are and are not
• Lighthouse - Built into Chrome DevTools, provides accessibility scoring

Online Checkers:

• WebAIM's Contrast Checker - Quickly test color combinations
• WAVE Web Accessibility Evaluation Tool - Enter a URL for instant analysis
• Accessible Colors - Find accessible color alternatives

Code-Level Testing:

• Pa11y - Automated testing integrated into your build process
• axe-core - JavaScript library for automated testing
• Storybook with a11y addon - Test components in isolation

Manual Testing Checklist

Spend 30 minutes doing these tests on every page:

1. Keyboard navigation: Tab through the entire page without using a mouse. Can you access everything? Is focus always visible?
2. Screen reader testing: Use NVDA (Windows) or VoiceOver (Mac) to navigate the page. Is all content announced? Do buttons and links make sense?
3. Zoom test: Zoom to 200% in your browser. Does everything still work? Is text still readable?
4. Color blindness simulation: Use browser DevTools or a plugin to simulate different types of color blindness. Can you still distinguish all elements?
5. Video and audio: Are captions accurate? Can you get the same information from transcripts?

Working with Real Users

The most valuable testing comes from people who actually use assistive technologies daily. Consider:

• Partnering with accessibility organizations for user testing
• Hiring accessibility consultants who are themselves disabled users
• Running beta tests that specifically recruit users of assistive technologies
• Creating a feedback mechanism for accessibility issues

Beyond compliance, accessibility makes excellent business sense.

Legal Protection

Organizations face increasing legal action under the Americans with Disabilities Act (ADA), with website accessibility lawsuits growing by double digits annually. WCAG 2.1 AA compliance significantly reduces legal risk and demonstrates good faith effort to accommodate users.

Expanded Market Reach

According to the World Health Organization, over one billion people live with some form of disability. That's 15% of potential customers excluded by inaccessible websites. Accessible design also benefits:

• Older users experiencing age-related changes in vision, hearing, or dexterity
• Users in challenging environments (bright sunlight, noisy spaces)
• Users with temporary disabilities (broken arm, eye injury)
• Users with slow internet connections who benefit from text alternatives

Improved SEO

Many accessibility practices align with search engine optimization best practices:

• Descriptive headings help both users and search engines understand content structure
• Alternative text for images provides context for search engine indexing
• Semantic HTML helps search engines categorize and rank content
• Keyboard navigable sites are easier for search engine crawlers to index
• Fast-loading, well-structured sites rank higher

Enhanced User Experience for Everyone

Curb cuts were designed for wheelchair users but benefit parents with strollers, delivery workers, travelers with luggage, and cyclists. Similarly, accessible web design benefits all users:

• Clear headings and content structure help everyone scan and find information
• High contrast text is easier to read for everyone
• Captions benefit users in sound-sensitive environments
• Keyboard shortcuts increase efficiency for power users
• Simple, clear language reduces cognitive load for all readers

How much does it cost to make a website WCAG 2.1 AA compliant?

The cost varies significantly based on your site's current state and complexity. Addressing accessibility during initial design and development costs approximately 5-10% more than ignoring it. Retrofitting an existing inaccessible site can cost 20-30% of the original development budget. However, this is substantially less than defending against a single accessibility lawsuit, which can cost $50,000-$100,000 in legal fees alone.

Do I need to make my PDF files accessible?

Yes, if PDFs are part of your website content, they must meet WCAG 2.1 AA standards. This includes proper tagging, reading order, alternative text for images, and form field labels. Consider providing HTML alternatives to PDFs when possible, as they're easier to make accessible and more mobile-friendly.

What about third-party widgets and plugins?

You remain responsible for the accessibility of third-party content on your site. Before integrating chatbots, maps, social media feeds, or payment processors, verify they meet WCAG 2.1 AA standards. If a vendor cannot provide accessibility conformance documentation, consider alternative solutions.

How often should I test for accessibility?

Conduct comprehensive accessibility audits annually and test every new feature or significant design change before launch. Set up automated testing in your deployment pipeline to catch common issues continuously. Make accessibility part of your ongoing quality assurance process, not a one-time project.

Can I claim full WCAG 2.1 AA compliance if I have one or two minor issues?

No, compliance is an all-or-nothing standard. You cannot claim conformance with any level if you fail to meet any success criterion at that level. However, you can publicly document your efforts and provide a roadmap for addressing remaining issues, which demonstrates good faith and ongoing commitment.

What's the difference between ADA compliance and WCAG 2.1 AA compliance?

The ADA itself doesn't specify technical standards for websites. However, the Department of Justice recognizes WCAG 2.1 AA as the most widely accepted standard. Meeting WCAG 2.1 AA is currently the strongest defense against ADA website accessibility claims.

Getting Started with Your Accessibility Journey

Achieving WCAG 2.1 AA compliance might seem overwhelming, but remember that accessibility is a journey, not a destination. Start with these actionable steps:

1. Conduct a baseline audit - Understand where you are now using automated tools
2. Prioritize high-impact fixes - Address color contrast, missing alt text, and form labels first
3. Educate your team - Make accessibility part of everyone's role, from content creators to developers
4. Build accessibility into your workflow - Include accessibility requirements in design mockups, development tickets, and QA checklists
5. Test with real users - Nothing replaces feedback from people who actually use assistive technologies
6. Document your progress - Create a public accessibility statement showing your commitment and progress

Accessibility is not just about avoiding lawsuits or checking compliance boxes. It's about creating digital experiences that work for everyone, regardless of how they access the web. When you design with accessibility in mind from the start, you create better websites for all users while expanding your reach and protecting your business.

Need Help Achieving WCAG 2.1 AA Compliance?

At Huston Design, we integrate accessibility into every project from initial wireframes through launch and beyond. Our team stays current with the latest WCAG standards and assistive technologies to ensure your website welcomes all users.

Contact us today for a free accessibility consultation and learn how we can help you create an inclusive, compliant website that expands your reach and protects your business.

Schedule Your Accessibility Consultation