The Web Content Accessibility Guidelines 2.1 (WCAG 2.1) was initiated with a focus on three major groups: users with low vision, users with disabilities on mobile devices, and users with learning or cognitive disabilities. The goal was to improve WCAG 2.0, the earlier set of guidelines, to ensure these user groups were taken care of.
WCAG 2.1 is based on the same four principles as WCAG 2.0, summarized below:
Perceivable
The information on a web page, as well as the user interface components, must be presented to users in a way that they can perceive it through their senses of sight, sound, and touch.
Operable
The ‘operable’ principle of WCAG 2.0 specifies that the user interface components and navigation must be operable for all users.
Understandable
Website content must be easy for everyone to understand, irrespective of the disabilities they have.
Robust
When people with disabilities use assistive technologies, they often encounter blocks that prevent them from comfortably engaging with the content on the site. The ‘robust’ WCAG 2.0 principle specifies that the website content must be robust, thereby lending itself for easy interpretation by a wide range of assistive technologies.
What’s New in WCAG 2.1
WCAG 2.1 does not replace WCAG 2.0, but adds to it. A lot had changed in terms of technology since WCAG 2.0 was introduced in 2008, so there was a need for an additional set of guidelines. It is backward compatible with the earlier guidelines, which means that:
- The basic principles continue to be the same.
- The earlier guidelines and categories are still applicable.
- WCAG 2.1 retains the earlier numbering system.
- The three levels of success criteria (A, AA, AAA) continue to apply.
Some of the key differences between these two guidelines are listed below:
Orientation of Web Pages
There has been a steady increase in the number of users accessing the Internet via tablets and mobile devices. Typically, when a person flips a tablet or a mobile phone, the orientation changes accordingly. However, due to their disabilities, some people are not able to flip their devices.
For example, there are users who have difficulties in rotating their devices because of limited motor skills. Or, they might need to mount their tablets or mobile phones to their wheelchairs.
WCAG 2.1 states that the content must be accessible both in landscape and in portrait orientation to ensure that people with disabilities are able to view content well in either orientation.
Enhanced Navigation through the Keyboard
Many users with disabilities are not comfortable using a mouse and so prefer to use a keyboard instead. In some website designs, menus are displayed only when the user hovers over a specific option and disappear when the user moves away from the option with the mouse. This causes problems in navigation for keyboard users.
By displaying menus through hover as well as on click, website developers open up their websites to a larger audience. The user should also be able to dismiss the menu through a click on the keyboard.
Reflow Capabilities
Some users with vision impairments need to enlarge content to be able to view it more clearly. This includes users with conditions such as cataracts or myopia as well as elderly users whose vision is deteriorating.
The new guideline addresses this through the concept of reflow. Reflow refers to the reorganization of content on the screen when users zoom into content. It becomes easier to view images and text, and there is no disruption in terms of navigation. Reflow also takes care of content compatibility between various devices. A responsive web design ensures that this is taken care of.
Improving Accuracy for Screen Readers
Websites contain a number of elements with screen labels, such as menus, search bars, buttons, and so on. People with impaired vision engage with these elements through an accessible name, which is read out to them by the screen reader. This name helps users provide spoken commands to other assistive technologies.
WCAG 2.1 specifies that the label for these elements and the accessible name must be the same. This helps in synchronization between the screen reader output and the inputs that the user gives through spoken commands.
Pointer Gestures
With advancements in interface technology, users now engage with content using complex gestures, such as swiping and pinch zooming. However, these actions may be difficult to perform for people with disabilities. Users must be able to achieve the same results using easier gestures, such as a long press or a double-tap.
Response to Motion
There are certain functionalities that are initiated when a user moves their mobile device in a particular manner. For example, by shaking one’s phone, users can undo a certain functionality in some environments. However, this could be a very troublesome feature for people with disabilities.
Users should be able to turn off the triggering of functionalities as a response to accidental motion. Also, the same functionality must be available through simpler options, such as sliders or buttons.
Status Updates
During the journey of interacting with websites, there are specific points when users see a change in status. For example, an online shopper only has to see the shopping cart symbol to understand that they’ve successfully added an item to the cart. People with impaired vision might not be able to see such changes clearly and the screen reader may not have the required inputs to announce such changes either.
According to the new guideline, users must be able to hear such status changes as soon as they occur. When a specific property of an on-screen element changes, the screen reader must be able to announce the change to the user.
The Need for WCAG 2.1 Alignment
The WCAG guidelines have emerged as a standard for several international regulations and laws around website accessibility. With a few lines of code in key locations, organizations can make their websites compatible with WCAG 2.1 and accessible to a larger audience base.
Learn More
To learn more about WCAG 2.1, click here -> WCAG 2.1
