A WCAG Digest

Check any website accessibility compliance laws – from federal Acts like the ADA (Americans with Disabilities Act) to local/state regulations and even international website standards – and it’s a good bet that they mention the WCAG or the Web Content Accessibility Guidelines. The WCAG 2.1 is the current standard for website design that’s usable and friendly toward individuals with disabilities.

Whether you are making your website easier to use for all types of visitors or meeting specific compliance requirements for your government or industry, it’s important to be comfortable with the WCAG 2.1. Any developers you work with on accessibility issues need to be very experienced with the instructions in the WCAG 2.1, and other content creators could also understand its basic requirements. Let’s dive into what all this means and how exactly the WCAG works.

What is WCAG (Web Content Accessibility Guidelines)?

The WCAG is a global effort developed among experts and key organizations such as the W3C (World Wide Web Consortium) and related bodies like the WAI (Web Accessibility Initiative). These are professionals from around the world who discuss what accessibility means when it comes to using technology, especially using the internet.

What sorts of disabilities make the internet harder to use? What are the latest assistive technologies that are enabling internet use? What should websites do to ensure they are compatible with accessibility standards? Questions like these led to the first version of the WCAG, which was published in May 1999. It covered important accessibility features for disabilities like visual impairments, deafness, mobility issues or problems using a mouse, mental disabilities, and more.

The WCAG is updated via a process of consensus. Working Drafts are submitted based on current conditions. Through community input and editing, these Working Drafts are refined until they are ready for a more formal submission, called a Candidate Recommendation. These Recommendations go through another refinement phase, including checks to ensure they can be properly applied to web content. They are then submitted for a final round of W3C endorsement, after which they are scheduled to be published as official WCAG Recommendations, a.k.a; the web standards the Guidelines advise. Each Recommendation includes a clear “Success Criterion” for enabling that capability.

The “2.1” Part of WCAG

The numbers after the WCAG indicate the version of the guidelines. Technology can change rapidly, and that includes all web content. In the beginning, the internet didn’t have cloud storage, shareable spreadsheets, or eBooks. From PDFs to mobile versions of websites, web content changes over time. The WCAG needs to change with it.

In 2008, the first broad update provided the WCAG 2.0. Nearly a decade later, an additional update was made to give us WCAG 2.1, which addresses some of the latest technologies to emerge during that time.

There is another update planned, known as WCAG 2.2, that should be updating the Guidelines by 2022 or 2023 (it was intended to be sooner, but factors like COVID-19 delayed the process). Any agency, tools, or developers your website team works with should be fully aware of the latest version of the WCAG and not use one of the older versions. This makes it easier to weed out services that aren’t worth your time.

The Four Principles of the WCAG

If you’re new to WCAG 2.1, the best place to start is with the four organizing principles, or POUR, a.k.a. Perceivable, Operable, Understandable, and Robust. These principles may sound odd at first, but they make much more sense when you view them from the perspective of individuals with disabilities. Each principle represents what a website should be to an individual with a disability:

• Perceivable: This simply means website content should not be invisible regardless of disability. That means that websites should provide multiple ways to experience content. That often means being careful about colors and contrast, as well as providing both visual and audio information so content can be consumed by the deaf and the blind. It also means that content shouldn’t be invisible behind barriers of difficulty or time – such as timed content that vanishes or locks users out after a certain period.
• Operable: A website should allow individuals with disabilities to operate it. This is similar to Perceivable but focuses on navigation. For example, some users may only be able to use a keyboard. Others may only be using a touchscreen. Some may be able to use a mouse and pointer but won’t be able to select small buttons or tools. A website should support multiple methods of operation, especially when it comes to keyboard navigation or touchscreen use. Content should also avoid lights or animations that could induce seizures and other physical reactions.
• Understandable: Individuals with disabilities should be able to understand all content on a website. This may sound like Perceivable, but it’s important to know that a user may be able to perceive content but still have trouble understanding it. Text is a good example: Website text should be large enough for users to read or easily magnify without losing context. When websites use headers and paragraphs, they should be placed logically. Sites should avoid jargon or words that are unnecessarily technical or provide their definitions. When possible, web form input assistance should also be supported to help automatically fill in the information and correct mistakes.
• Robust: Robust focuses on the more technical aspects of web accessibility. A number of assistive technologies, including third-party software and external hardware, enable individuals with disabilities to use websites. Websites should support this assistive technology, and if new technology is broadly adopted, the site should enable it as well. This is one reason that web accessibility “overlays” aren’t a WCAG solution because they can easily interfere with the screen readers, magnifiers, and other tools that those with disabilities are already using.

Specific WCAG Examples

The POUR principles are a good starting place, but the WCAG 2.1 digs down into the details with very specific instructions about what all website content should be able to do. There are many, many examples of this, but let’s go over a few common steps so you can see what this kind of accessibility optimization can look like:

• Content that can be presented in different ways without losing information or structure: This refers to enabling magnifiers and zooming abilities and supporting readability for different versions like text-only modes.
• Audio descriptions for all pre-recorded videos: This ensures that individuals who may not hear the video can read along with captions or subtitles that are properly synced with the video.
• All functionality of the content is operable through a keyboard interface: This means that users should be able to navigate through a website (including its menus, anchor links, and important buttons or forms) with a keyboard. If a site uses keyboard shortcuts, they should allow users to turn off shortcuts or remap them.
• When possible, the language used can be programmatically determined. This allows for valuable auto-fills that help individuals with disabilities save time and avoid mistakes.

WCAG 2.1’s Three Distinct Levels

Take any specific WCAG recommendation, and you’ll see that it has three different sections or levels of compliance: A, AA, and AAA. Level A refers to the lowest level of compliance, while Level AAA is the most stringent compliance.

• Think of Level A as the standard that all websites should strive for, no matter their purpose. These are the basics and should not be difficult to implement for the average site.
• Level AA is the standard for widespread accessibility, enabling a broad number of individuals with accessibility to use the site: This is the standard that all business sites should strive for when meeting compliance requirements.
• Level AAA is reserved primarily for government websites and related sites that need to be accessed by all users and require as much accessibility support as possible.

Developer Techniques and the WCAG

The WCAG focuses primarily on what websites should be able to do. The Guidelines themselves don’t go into detail about how websites should be able to do these things. This is on purpose. The WCAG doesn’t aim to constrain developers into a particular way of doing things: There are many ways to enable accessibility and methods that constantly evolve over time. Different developers or sites may benefit from different approaches.

However, for developers who really don’t know where to begin and prefer some starting advice for the how side of things, there is an additional WCAG guide, Techniques for WCAG 2.1.

The Techniques guide offers specific examples of how to use web coding like ARIA, HTML, and CSS to meet the Guidelines. It also spells out failure criteria to help developers spot problems and includes plenty of general design advice for enabling accessibility.

While the Techniques section can be helpful, it shouldn’t be thought of as comprehensive, and the examples should be taken with a grain of salt. For any specific technique listed, there’s usually an alternative or different way of implementation.

Finding Out How Your Website Compares to WCAG 2.1

So, you have the WCAG 2.1 ready to help and your website ready for an update. What happens next? How do you know what parts of a website need to be updated for WCAG 2.1?

The best answer is typically a combination of professional auditing tools and experienced developers who have worked on accessibility projects before. Automated auditing can help spot certain kinds of missing accessibility and create a starting list of changes to make. Accessibility developers can flesh out that audit with a complete plan that addresses everything from navigation to the proper HTML tags.

The WCAG 2.1 and Other Online Content

Businesses don’t live only on their websites. Your brand is probably creating a lot of other content you’re sending in emails, posting on social media, or making available via downloads. As a general rule, all this web content should also meet the WCAG 2.1, especially when it comes to the Perceivable principle and any Calls to Action the content may include.

Finding the Right Partner for WCAG 2.1 Compliance

In-house teams aren’t always enough to achieve accessibility compliance. If you are looking for a partner to help with your latest web development project, contact Blue Atlas Marketing and we’ll be happy to set up a discussion with you!

Our web developers have the necessary experience and tools to take care of your accessibility optimization and meet the necessary WCAG standards. A new website design can also help make sites easier to use and improve overall lead generation: We’ll be happy to talk about the specifics for your unique site and set up a plan.