Web developers, designers and authors often have questions the Web Content Accessibility Guidelines (WCAG). Questions may come up about the difference between WCAG versions 2.0 and 2.1, when WCAG 2.2 will be released, or whether the Americans with Disabilities Act (ADA) requires that websites conform to WCAG. We’ve prepared some answers to these and several other questions. WCAG.com offers a wealth of resources, so browse through the site for answers to other questions you may have about making your website and other digital assets accessible to people with disabilities.
What is WCAG compliance?
It’s actually more accurate to refer to WCAG conformance than compliance. WCAG guidelines are exactly that—guidelines—not laws, which require compliance. There are several requirements (Success Criteria) that must be met in order to conform to WCAG. If you ensure that your website meets the requirements of WCAG 2.1 Level AA, you’ll achieve a level of digital accessibility that is the current best practice. And while WCAG conformance isn’t the same as legal compliance, conforming to level AA helps website owners achieve a level of accessibility required by most laws.
What’s the difference between WCAG 2.0 and 2.1?
One important thing to understand is that if your website meets WCAG 2.1, that means you’ve met WCAG 2.0. This is often called “backward compatibility,” meaning all the guidance and criteria contained in 2.0 are part of 2.1. WCAG 2.1 includes 17 additional requirements. Here are just three of the additional Success Criteria in 2.1:
- 1.3.4 Orientation: Addresses the need to have more than one display orientation.
- 1.4.11 Non-Text Contrast: Describes the importance of sufficient color contrast, not just with text, but also page elements that convey information or require interaction to complete a task.
- 4.1.3 Status Messages: Lets the user know where they are in the process of taking an action by providing feedback if they made an input error, or letting them know how much time they have left to complete an action.
WCAG 2.1 also includes guidance on the accessibility of mobile apps, as well as more examples of accessibility errors and how to fix them. Find more information about the additional Success Criteria found in WCAG 2.1. (Note: WCAG 2.2 is expected to be officially released sometime this summer.)
Is WCAG a legal requirement?
WCAG conformance supports legal compliance, but WCAG isn’t a law or regulation. It’s a worldwide set of shared standards and guidance that can help make your website and other digital assets more accessible to people with disabilities. However, while WCAG isn’t technically a legal requirement, federal courts and the U.S. Department of Justice, citing the accessibility requirements of Title III of the Americans with Disabilities Act (ADA), have relied on WCAG 2.1 Level AA as a basis for many decisions and enforcement actions. The thing to remember is that conforming to WCAG will help you comply with multiple laws.
What does WCAG say about keyboard compatibility?
Recognizing that not everyone uses a mouse to navigate a website, WCAG Success Criterion 2.1.1 Keyboard addresses head-on the need for keyboard compatibility. An individual who is blind or has low vision can’t see where a mouse is pointing. People with repetitive stress injuries or hand tremors may not be able to use a mouse either, so their preference is using just the keyboard to navigate your website. Keyboard compatibility allows people with a variety of disabilities to access your content and transact business. It’s also useful for people with temporary impairments such as a broken arm or simply a broken mouse.
Try doing this–unplug your mouse and make sure you can do everything on your website that you would be able to do if the mouse were working. For more information about keyboard compatibility and its importance to accessibility, check out this story about Alex, a reporter with repetitive stress injury.
Does WCAG address mobile apps and accessibility?
Yes, but not through a unique set of WCAG guidelines that apply only to mobile apps. Though originally developed for websites, WCAG is the best-practice standard for all types of digital experiences, including those using mobile apps. When WCAG 2.1 was published in 2018, 17 new Success Criteria were added, and many of these guidelines also help with removing mobile technology barriers.
For more information, check out these five tips to improve app accessibility and WCAG for Mobile Apps.
What screen readers can you test with (and when do you test)?
There are many different types of screen readers, but you don’t need to test the accessibility of your website using all of them. Testing using a couple different ones will give you a good idea of what’s working and what’s not. It’s more important to stay focused on the WCAG guidelines and techniques than on the differences among several different screen readers. Of course, testing by an actual user of this assistive technology is a must for getting a true, comprehensive picture of the accessibility of your website for a blind or low-vision user. Accessibility testing should be performed during development and continue as new iterations of your website are designed and new content is added and organized. For more information check out WebAIM’s testing with screen readers.
Is it too late in the build process to be accessible?
As the saying goes, “It’s never too late” to take steps to make your website accessible. Building accessible features into your website involves project managers, developers, designers, and content authors, among others. The ideal starting point is at the beginning of the development and design process, but there’s really no end point to this effort. Websites and other digital assets are rarely static, so the need to regularly assess their accessibility, while collaborating with users with different abilities, is critical. Also, trying to fix accessibility barriers later in the build process can take a lot more time and money. For more about building accessibility into the process, visit this W3C working group Wiki page “Start with Accessibility.”
How can I tell how accessible my website is?
The short answer is by testing it. Automated testing tools like WAVE can track down accessibility barriers on your website and report back to you if certain processes or functionalities pass or fail. In this way you can find out what aspects of your website require remediation and maybe some easy fixes. However, automated accessibility testing has its limitations, capturing less than a third of accessibility issues that may be present. W3C’s “Easy Checks” is another good way to get an initial assessment of how accessible your website is. This resource covers page titles, alt text, headings, color contrast and many other areas that form the foundation of an accessible website. WCAG 2.1 checklists can also help you evaluate your site, and they usually offer specific solutions and techniques for meeting the Success Criteria.
To get a comprehensive assessment of how accessible your website is, manual testing is imperative. There’s no technology that can take the place of human interaction with your website, in particular by people who may use assistive technology because of a disability or functional need.
What are the most common accessibility issues found in web design?
Web designers play a central role in making websites and other digital assets accessible, and how they do this covers a lot of territory. Having sufficient color contrast, headings that bring related content together, and providing feedback by letting users know required fields, are just a few key elements designers need to keep in mind. Review the W3C Web Accessibility Initiative’s “Designing for Web Accessibility” to learn more about some of the most common accessibility barriers that relate to design. You may also want to check out WebAIM’s summary of design issues for information about the importance of how your web content is presented and organized for people with a broad range of disabilities.