A Beginner’s Deep Dive into Accessible UI with WCAG

Keeping accessibility in mind when creating the user interfaces of web products is key to ethical design that doesn’t discriminate against users with disabilities, who make up an important part of the audience for virtually all kinds of projects. In July 1990, the Americans with Disabilities Act was made into law, making websites public spaces that must be accessible [10]. All electronic and information technology used by federal agencies also must have accessibility features under certain requirements. These accessibility guidelines are set by the World Wide Web Consortium (W3C), which is the World Wide Web’s international standards organization. The W3C is made up of multiple organizations that work together to set standards for the entire internet. The Web Content Accessibility Guidelines (WCAG) that the W3C publishes are what the United States federal government, along with several other countries across the continents, use to set their accessibility standards. Even if you are not creating online platforms in the U.S, where website accessibility is required by law, the WCAG is still generally accepted as a universal set of accessibility guidelines for websites. Knowing about the WCAG and understanding its basic requirements and the levels of standards they have is crucial to UI and UX design that can serve everyone, regardless of disability status.

What is the WCAG?

The W3C, founded in 1994, partnered with the American government to create the Web Accessibility Initiative in 1997. The Web Accessibility Initiative decided that there should be a set of standards that should allow people with disabilities to participate in what was then a rapidly growing World Wide Web which had virtually no restrictions or regulations. The W3C soon after employed the Accessibility Guidelines Working Group, or AGWG, which published the first version of the WCAG in May 1999. The first WCAG in the late 90s was groundbreaking, being one of the first set of guidelines of its kind. It took nearly a decade for the second version of the WCAG to come out in December 2008 after facing the internet boom, and the WCAG 2.0 was made a W3C Recommendation Web Standard after it was updated to fit the changes the internet had faced in the last nine years. The federal government updated their laws, (29 U.S.C § 794 (d) in specific) to closely replicate the WCAG 2.0 and set it as the basic standard of accessibility that was legally mandated for federal agencies and their contractors. They state that according to Section 508, these government “agencies must give disabled employees and members of the public access to information comparable to the access available to others” [3]. Having this law not only allowed for equal access to federal resources, but it was also a step toward giving disabled people the right to equal access to the Internet that now supports us in our day-to-day lives, with the WCAG as the standard.

Another decade later, W3C published the WCAG 2.1 in June 2018, which they state is their final, “stable” Recommendation Web Standard [2]. This means that later versions of the WCAG that are finalized will only add to the version 2.1 standards that serve as baseline requirements for accessibility to the technologies we use currently. The W3C provides past and current versions of the WCAG on their website to be referenced anytime by the public, and even publish working drafts such as the version 2.2 which is set to be released in September 2022. In fact, the W3C makes an effort to provide transparency by automatically updating a page with everyone on the Accessibility Guidelines Working Group board, providing instructions for organizations to join the W3C Member organization to join the working group, and regularly publishing the project plans and the lengthy drafts of new WCAG versions, like WCAG 3.0 [4]. For a beginner programmer, this can be overwhelming, but understanding the basic WCAG guidelines well the first time helps programmers implement a standard for accessibility in their code that can be easily refreshed as new versions come out. 

Current WCAG 2.1 Standards

Because of the W3C’s structure of adding on to their standards, it is simplest to start with their recommended WCAG version, 2.1, before looking into the future 2.2 updates, and then the 3.0 proposed features. Once the baseline guidelines are understood, it will become easier to adapt to the changes the W3C will make to their requirements. The WCAG 2.1 guidelines are split up into three levels based on how much effort is being put into making the design accessible: Level A, Level AA, and Level AAA. Level A is the minimum level of conformance, which provides help for some audiences, but not for all people. Level AA is considered moderate accessibility for most people, which includes the Level A standards and is the recommended level for most web page design. Finally, Level AAA is the most difficult level of standards, which includes the previous two levels and is the gold standard for accessibility when available. However, it cannot be used as general policy according to W3C because “it is not possible to satisfy all Level AAA Success Criteria for some content,” meaning that the Level AA is the most accessible option, as far as that version’s standards go [5]. By following the recommended Level A and AA standards, a web page can be generally considered more accessible for all users, including people with low vision, cognitive disabilities, learning disabilities, and language disabilities.

The key sections of the WCAG 2.1 are split up into four sections for the main principles they define for accessibility: “Perceivable,” “Operable,” “Understandable,” and “Robust”. The WCAG Quick Reference has all the WCAG 2.1 guidelines under each four main principles, with specific success criteria under each guideline (see figure 1).

The first principle is to make the product perceivable, which includes guidelines “text alternatives,” “time-based media,” “adaptable,” and “distinguishable” (see figure 2 and 3). 

This focuses on making sure all the text on the page is adaptable to programs like screen readers and magnifiers, and that all media has some kind of alternative and/or adjustable format for those that cannot rely on their hearing or sight. Another key aspect of accessible user design is making sure that the colors and contrast of visuals are compatible with people with low vision and color blindness, which also makes for easier viewing and less strain for all audiences.

The second principle is operability, which includes guidelines “keyboard accessible,” “enough time,” “seizures and physical reactions,” “navigable,” and “input modalities” (see figure 4 and 5).

This includes the key requirement of having all aspects of a website be navigable via a keyboard, which allows people with mobility difficulties to interact with pages without relying on a mouse. Timed aspects should also be adjustable for people that can’t navigate quickly for various reasons, and media with movement should be friendly to those prone to seizures. This, paired with the standards to make all pages navigable and clear, also removes added stress from the user’s media experience.

The third principle is understandability, which includes guidelines “readable,” “predictable,” and “input assistance” (see figure 6).

This set covers readable text for the ease of people and screen readers alike, and requires predictable patterns in design so all users can learn what to expect from a web page. This also highlights the need for assistance that can help users to prevent errors and undo accidental commands to make for a more universally human-proof interface.

The final principle is robustness, which includes the guideline “compatible” (see figure 7).

This principle’s aim is so that websites are compatible with assistive technology; requiring clean code, properly marked user interface components and status messages. Not only are these habits generally good coding practice, but they are necessary for some screen readers and magnifiers to access and identify page data.

The W3C understands that this page can be hard to navigate, despite it being a “quick reference,” so they provide a filtering system for these guidelines that allow a programmer to narrow down the standards and focus on meeting their accessibility goals one at a time (see figure 8 and 9).

You can filter success criteria by tags, levels, techniques, and the technologies they support. Once the WCAG 2.2 is published, the reference page filters will also give the option to see the entire list of updated guidelines, or just the list of the newly added success criteria from that version. Also available on the internet, of course, are countless checklists and even Google Chrome extensions like the WAVE Evaluation Tool that are able to check a website’s accessibility levels. However, the most accurate way to check for accessibility when building a project is to master the W3C guidelines from the source.

The WCAG 3.0

As of December 2021, the W3C has posted a working draft of the WCAG version 3.0 which is available to the public for input [7]. The W3C is known for a lengthy process when publishing and recommending new versions of the WCAG, so it is good to keep an eye out for upcoming changes that this new version might introduce in the next “few years,” especially since there has been no news of another partial version coming after version 2.1. The WCAG 3.0 will introduce multiple changes, including a new guideline structure that aims to be more clear for those following the requirements, and a conformance rating system from 0-4 [8]. The W3C also aims to provide more supporting material and broaden the list of functional categories of disabilities they cover, including:

• Vision and Visual
• Hearing and Auditory
• Sensory Intersections
• Mobility
• Motor
• Physical and Sensory Intersections
• Speech
• Attention
• Language and Literacy
• Learning
• Memory
• Executive
• Mental Health
• Cognitive and Sensory Intersections [9].

Importance

It is obvious that simply meeting any standards in most cases isn’t enough to make a user experience accessible to every person that encounters it, but when it comes to introducing accessible programming in your user design, the WCAG is a great foundation for beginning to understand how to create a more equitable user interface. Understanding how to navigate the WCAG and understand its background and its changing guidelines on your own is a learned skill that can bring all of your projects to the next level. It is a powerful tool that allows any developer to provide ethical content, broaden their reach, and keep them from relying on third parties for accessibility. The best way to create better accessibility in projects is to understand and keep in mind these base standards before any line of code is written.

Sources

[1] “Identifying User Personas in Accessibility — Why It’s Important | EBSCOpost,” EBSCO Information Services, Inc. | www.ebsco.com. https://www.ebsco.com/blogs/ebscopost/identifying-user-personas-accessibility-why-its-important  (accessed Apr. 08, 2022).

[2] W. W. A. Initiative (WAI), “WCAG 2 FAQ,” Web Accessibility Initiative (WAI). https://www.w3.org/WAI/standards-guidelines/wcag/faq/ (accessed Apr. 08, 2022).

[3] “Section508.gov.” https://www.section508.gov/manage/laws-and-policies/ (accessed Apr. 08, 2022).

[4] “Accessibility Guidelines Working Group.” https://www.w3.org/groups/wg/ag (accessed Apr. 08, 2022).

[5] “Understanding Conformance | Understanding WCAG 2.0.” https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-levels-head (accessed Apr. 09, 2022).

[6] “How to Meet WCAG (Quickref Reference).” https://www.w3.org/WAI/WCAG21/quickref/  (accessed Apr. 12, 2022).

[7] “W3C Accessibility Guidelines (WCAG) 3.0.” https://www.w3.org/TR/wcag-3.0/ (accessed Apr. 12, 2022).

[8] W. W. A. Initiative (WAI), “WCAG 3 Introduction,” Web Accessibility Initiative (WAI). https://www.w3.org/WAI/standards-guidelines/wcag/wcag3-intro/ (accessed Apr. 13, 2022).

[9] “Explainer for W3C Accessibility Guidelines (WCAG) 3.0.” https://w3c.github.io/silver/explainer/#functional-categories (accessed Apr. 13, 2022).
[10] “Introduction to the ADA,” Information and Technical Assistance on the Americans with Disabilities Act.https://www.ada.gov/ada_intro.htm (accessed Apr. 19, 2022).