This blog post has been updated to include the latest WCAG 2.2 guidelines released on October 5, 2023 and more robust examples and ways to make your website accessible for people with disabilities.
FACT: According to recent statistics, 61 million people in the US live with a disability, representing approximately 1 in 5 individuals. Despite this significant portion of the population, accessing and using websites remains a challenge for many. Fortunately, Web Content Accessibility Guidelines, or WCAG, are helping people with disabilities gain crucial access to the online world.
What are the basic principles of WCAG?
WCAG is a set of guidelines and recommendations for making accessible web content for people with various disabilities – disabilities including visual, physical, cognitive, auditory and more.
To understand the basic principles behind WCAG, you only need to learn one simple acronym: POUR. These four principles lay the necessary foundation for building accessible web content.
Perceivable - information and user interface components must be presentable to users in ways they can perceive, using one or more of their senses. This means:
- Provide text alternatives for non-text content such as images so individuals who are partially or fully blind can understand what the images are showing or conveying.
- Provide captions and other alternatives for multimedia content such as video so individuals who are deaf or hard of hearing can perceive the video content.
- Create content that can be presented in different ways, including by assistive technologies, without losing information or meaning.
Operable - User interface (UI) components and navigation must be operable by people with disabilities. This means:
- Users must be able to control UI elements. For example, the user must be able to activate the action of a button through the method and assistive technology they’re using. That could be a mouse click, using a keyboard, or through voice command.
- All functionality is available for keyboard-only users.
- Content should not be displayed in a way that can cause seizures or adverse physical reactions. For example, video and motion graphics should have an option for a user to pause or stop movement. If you have a video or motion that plays automatically on load, you can use WCAG Technique C39 and use the CSS reduce-motion query to prevent motion. This technique utilizes a media feature in CSS that detects if the user has requested that the system minimize the amount of non-essential motion it uses. When a user with these settings enabled accesses the site, the animation will instead show as a still.
Understandable - Information and the operation of user interface must be understandable. This means:
- The user and assistive technologies such as screen readers must be able to make sense of the information and how to operate the user interface.
- Ensure copy is clearly written and easy to understand. Avoid jargon, acronyms, unnecessarily complex words, and provide explanations as needed so content is more understandable for people of varying language skills.
- Utilize headings, bullet points, spacing, and concise text so people with cognitive disabilities who have difficulty focusing can scan content.
Robust - Content must be robust enough that it can be interpreted by a wide variety of user agents, including assistive technologies and browsers. This means:
- Using semantic HTML when coding so that you maximize compatibility with current and future technologies.
- Have error messages that appear and are understood by screen readers in case a user makes a mistake when filling out a form.
How can you develop WCAG compliant content?
Now that you have a better understanding of what WCAG is and why these guidelines are so important, here are some best practices for creating WCAG-compliant content.
- Structure your content properly. Semantic markup and proper use of headings are crucial. By including semantic tags, you will make it clear to the browser what the page means and what content it includes.
- Use labels. If a control or form element has no text label, make sure you add one.
- It’s best not to rely on visual cues. The content of your pages should make sense regardless of whether or not the user is able to visually see the page, having the page read to them, or if they are colorblind. Be sure to use sufficient contrast between the colors of the text and the background.
Here are some resources we found to be helpful:
-
W3C WIA: Web Content Accessibility Guidelines (WCAG) Overview
-
DynoMapper: 70 Web Accessibility Resources for Designing with Inclusivity
What about conformance levels for WCAG?
WCAG conformance is categorized into three levels:: A (lowest), AA (mid range), and AAA (highest). Each level represents progressively higher levels of accessibility compliance, with AA being the standard typically aimed for. Conformance at higher levels also means you are conformant at the lower levels. For example, by conforming to AA, a Web page meets both the A and AA conformance levels.
For compliance, one of the three levels must be fully met. Let’s look at level qualifications:
- Level A: The web page satisfies all of the level A success criteria, or the minimal level of conformance.
- Level AA: The page satisfies all the Level A and Level AA success criteria.
- Level AAA: The website satisfies all success criteria for all three levels of conformance. Level AAA is the most difficult level to achieve.
It’s also a good idea to include an accessibility statement as public information on your site. This statement will indicate your internal organizational policies, your accessibility goals, and past successes for serving users with disabilities. This accessibility statement resource from a leading authority on website accessibility provides guidance on what to include in an accessibility statement, a generator tool, and examples.
What’s new in the wcag 2.2 guidelines?
On October 5, 2023 W3C released updated WCAG 2.2 guidelines. Version updates are infrequent. Version 2.1 was released in 2018 and prior to that 2.0 was published in 2008. There are nine new success criteria in 2.2 that span the three levels.
Level A
- 3.2.6 consistent help
- States that “If a Web page contains any of the following help mechanisms [human contact details, human contact mechanicsm, self-help option, or a fully automated contact mechanism], and those mechanisms are repeated on multiple Web pages within a set of Web pages, they occur in the same order relative to other page content.” For example, if you have a global header navigation with a contact phone number, you should keep that global navigation consistent across all web pages.
- 3.3.7 redundant entry
- States that “Information previously entered by or provided to the user that is required to be entered again in the same process is either auto-populated or available for the user to select except when re-entering the information is essential, the information is required to ensure the security of the content, or previously entered information is no longer valid.” An example of when this would apply is for an ecommerce website. A user should not have to enter a billing address when it is the same as the shipping address that they previously entered. In this case, there should be a way to select that the billing address and the delivery address are the same.
Level AA
- 2.4.11 focus not obscured (minimum)
- States that “When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.” An example of this is when you have a global chat option or some other overlay that hides content behind it. If a user is not able to take keyboard actions (i.e. using the Escape key to dismiss the overlay that’s obscuring content) to allow the item with focus to be revealed then it will not be pass this guidelines.
- 2.5.7 dragging movements
- States that “All functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging, unless dragging is essential or the functionality is determined by the user agent and not modified by the author.” This guideline allows people with motor impairments to be able to still interact with your website and complete tasks. For example, if you require a user to order things by dragging them into the order they want that would not pass this guideline as people with motor impairments may struggle with that type of action. If you provide an alternate/secondary way to achieve the task by allowing them to click arrows to order and those arrows are no less than 24 by 24 pixels then you would pass this guideline.
- 2.5.8 target size (minimum)
- States that “The size of the target for pointer inputs is at least 24 by 24 CSS pixels” with a handful of exceptions. This ensures that people who struggle with fine motor movement can still operate and complete tasks on a website.
- 3.3.8 accessible authentication (minimum)
- States that “A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless that step provides” an alternative method, a mechanism to assist, is a test to recognize objects, or the test is to identify non-text content the user provided. An example of how your website can provide a mechanism to assist users is by allowing content to be copy and pasted to reduce burden.
Level AAA
- 2.4.12 focus not obscured (enhanced)
- States that “When a user interface component receives keyboard focus, no part of the component is hidden by author-created content.” This is a more strict guideline than 2.4.11 discussed above as it requires that no content is hidden in the first place.
- 2.4.13 focus appearance
- States that “When the keyboard focus indicator is visible, an area of the focus indicator is at least as large as the area of a 2 CSS pixel thick perimeter of the unfocused component or sub-component, and has a contrast ratio of at least 3:1 between the same pixels in the focused and unfocused states.
- 3.3.9 accessible authentication (enhanced)
- States that “A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless that step provides” an alternate authentication method or a mechanism to assist the user.
Can we guarantee compliance with WCAG?
The truth is, we can’t. It’s rare that any website will be 100% WCAG compliant at all times. Sites are dynamic, and their technology is always changing. Few third-party companies will certify a website as being WCAG compliant. If a company does offer a certification, that certification is only valid for a specific date and time. Those in pursuit of WCAG compliance should refer to their legal team to determine the level of compliance they need, and what that compliance would entail for their specific website, and develop guidelines and testing protocols to ensure ongoing compliance.