On October 5, 2023, the World Wide Web Consortium (W3C) unveiled the much-anticipated WCAG 2.2, marking the culmination of five years of dedication and innovation. In this post, we're diving deep into the latest updates to the key web accessibility guidelines and sharing our unique approach to putting them into practice.
In an increasingly digital world, web accessibility has become more important than ever. It’s not just about compliance with standards or avoiding legal ramifications; it’s about ensuring equal access to information and opportunities for all.
Additionally, web accessibility brings tangible benefits to businesses, such as enhancing the user experience, broadening audience reach, improving a business’s reputation, and boosting search engine optimization.
As a web development company committed to making the web inclusive, we keep a close eye on updates to web accessibility guidelines. Our top priority is ensuring that everyone, regardless of their abilities, can easily access and interact with the websites we develop.
In this respect, we have some exciting news to share with you. After five years in the works, the new version of Web Content Accessibility Guidelines (WCAG) – WCAG 2.2 – was finally released as a “W3C Recommendation” standard on October 5, 2023.
In this post, we review nine additional Success Criteria (SC) introduced in the new guidelines aimed at improving accessibility for individuals with visual impairments, cognitive and learning disabilities, and motor limitations.
Let’s dive in!
When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.
Let’s break down this Success Criterion. It’s all about making sure that when you’re using your keyboard to navigate a webpage, the element you’re focusing on is at least partly visible. This is really important for people who rely on a keyboard or similar device, as it helps them see where they are on the page.
Now, in today’s world of intricate web designs, it’s understood that sometimes the element you’re focusing on might be slightly hidden by other elements. But the more hidden it is, the harder it gets to see. So, web designers and developers should try to reduce how often and how much this happens. Ideally, the focused element should always be fully visible.
Elements like sticky footers, headers, and non-modal dialogs can overlap with the focused element, making it harder to see. For example, a sticky notification like a cookie banner would fail the Success Criterion if it completely hides a focused element.
To fix this, the banner could be made modal, meaning it has to be dismissed before you can navigate the page, or scroll padding could be used to stop it from overlapping.
When we come across a popup, modal window, or burger menu that obscures the opening element, we employ JavaScript to move the cursor to the first focusable element in that block.
It helps the user understand where they’re right now by visually highlighting the state of the focused item. We also use a screen reader that reads highlighted text out loud.
For more details on the SC, visit this page.
When a user interface component receives keyboard focus, no part of the component is hidden by author-created content.
The primary objective of this Success Criterion is to ensure the item that’s receiving keyboard focus remains visible at all times. Just like the previous SC, this one is integral for users who rely on a keyboard or similar input devices, providing them with a clear understanding of their current location on a webpage.
Examples of how this criterion can be met include the use of the same methods as in the previous SC: scroll padding to keep the focused item visible, modal dialogs that don’t obscure the focused item, and notifications that disappear when they lose focus without hiding other controls. This ensures a more accessible and user-friendly experience for all.
For more information, visit this page.
When the keyboard focus indicator is visible, an area of the focus indicator meets all the following:
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.
This Success Criterion has one key purpose: to ensure that when you’re using a keyboard to navigate, the focus indicator is always clear and noticeable. This is closely tied to the 2.4.7 Focus Visible and 1.4.11 Non-text Contrast rules.
While Focus Visible makes sure there’s a visible sign when an item gets keyboard focus, Focus Appearance sets a minimum level for how visible that sign should be. Similarly, Non-text Contrast ensures that a component stands out from the background, and Focus Appearance requires the focus indicator itself to have enough contrast.
Again, this is really important for anyone using a keyboard or similar device, like a switch or voice input. It’s essential to know where you are on the page. And it’s also crucial for people with low vision who might be relying on the keyboard to navigate.
The focus indicator can take different forms. Though a solid outline around the focused item is encouraged, other types of equally noticeable indicators are also acceptable.
To learn more, visit this page.
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 SC is about making sure that if something on a website involves dragging movement, there’s another way to do it with just one click. This is important because not everyone can make precise dragging movements. Some people use devices like trackballs or eye-gaze systems, which can make dragging difficult and prone to errors.
When an interface uses dragging, it usually involves four steps:
However, not everyone can accurately do the “press-and-hold while moving” part. That’s why we need to provide an alternative for users who have mobility issues but use a pointer, like a mouse, pen, or touch input.
This is separate from making things accessible for keyboard use. Why? Because those using a touchscreen may not use a physical keyboard. They can’t use typical keyboard actions like tabbing or arrow keys when faced with a drag-and-drop control.
However, having a text input could be a good single-pointer alternative to dragging. For instance, if there’s a slider, having an input box next to it could allow users to enter an exact value. The on-screen keyboard that appears for touchscreen users provides a way to enter alphanumeric values with just one pointer.
Lastly, this criterion doesn’t apply to user-agent enabled scrolling. It doesn’t cover scrolling a page or using techniques like CSS overflow to make a section of content scrollable.
Regarding this specific Success Criterion, our primary focus revolves around carousels, for which we leverage Swiper.js to achieve the necessary functionality.
If the features provided by this JavaScript library fall short of meeting the SC for drag-and-drop movement, we resort to implementing a custom coding solution.
Want to know more about the SC? Visit this page.
The size of the target for pointer inputs is at least 24 by 24 CSS pixels, except where:
Spacing: Undersized targets (those less than 24 by 24 CSS pixels) are positioned so that if a 24 CSS pixel diameter circle is centered on the bounding box of each, the circles do not intersect another target or the circle for another undersized target;
Equivalent: The function can be achieved through a different control on the same page that meets this criterion;
Inline: The target is in a sentence or its size is otherwise constrained by the line-height of non-target text;
User agent control: The size of the target is determined by the user agent and is not modified by the author;
Essential: A particular presentation of the target is essential or is legally required for the information being conveyed.
So, the whole idea behind this Success Criterion is to make sure that when you’re trying to click or tap on something, you don’t accidentally activate something else that’s too close. This can be a real pain for people who have a tough time with precise movements.
Hitting a small target gets even trickier when there’s another one nearby. By making these targets big enough, or at least putting enough space between them, we can help avoid those accidental clicks or taps.
This rule really helps those dealing with hand tremors, spasticity, quadriplegia, or other conditions that affect their dexterity. Some of these people might use special input devices that aren’t as pinpoint accurate as your typical mouse or trackpad. The bright side is that by meeting this requirement, we’re also making touchscreen interfaces easier to navigate.
Just to clear things up, this Success Criterion sets a minimum size for targets and, if that’s not possible, a minimum amount of space between targets. So, technically, you could still have tiny, hard-to-hit targets and meet this requirement, as long as they’re not too close to any other targets.
But let’s be real, bigger targets are going to be easier for a lot of people to use. So, the best practice is to at least hit the minimum size requirement of the Success Criterion, no matter how much space you’ve got around your targets.
In this context, the design plays a crucial role. If the element is very small, it should either be isolated from neighboring elements or positioned a bit farther away to allow for comfortable interaction.
We frequently encounter this situation in mobile menus, especially when dealing with a small arrow as the nested menu opener. In such cases, we ensure that the button is appropriately sized to enable easy tapping for users.
To find out additional details about this SC, go to this page.
If a Web page contains any of the following help mechanisms, 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, unless a change is initiated by the user:
Human contact details;
Human contact mechanism;
Self-help option;
A fully automated contact mechanism.
Basically, the idea behind this SC is to make sure people can find help when they need it on a website. It’s all about consistency – if you put your help features in the same spot across different pages, users will have an easier time finding them. This isn’t about those little extras like spell checkers or form instructions, but more about the big-picture help.
Making sure your help feature is in the same place on each page makes it a lot simpler for users to find. So, if you’ve got a link or some kind of help button in the header of one page, it’s best to keep it in the header on other pages too.
It could be something like a contact phone number right there on the page, or even a link that takes you straight to a contact page. But whatever it is, it needs to be in the same spot on each page.
When checking to see if this SC is met, you need to see where the help feature is in relation to the rest of the content on the page. If other content that’s on every page comes before the help feature, then it should be the same on this page. And anything that comes after the help feature on other pages should come after it on this page too.
If the help feature is visually in a different spot, but in the same order, it might not be as helpful from a user’s perspective, but it wouldn’t technically fail this criterion.
When someone’s having trouble doing something on a website (or part of a website, which we call a set of web pages), some people with certain types of disabilities might not be able to figure it out without some extra help. They might be struggling with filling out a form, finding a document, or locating a page with the info they need to finish a task.
Without help, some users might just give up. They could also mess up a task, or end up needing help from someone who might not keep their private info safe.
This issue should ideally be addressed while planning the website’s structure. When we encounter inconsistencies in how user assistance is provided, we bring this to the client’s attention and recommend that they should reconsider the website’s structure, especially if accessibility is crucial for them.
Find more information here.
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.
This SC is designed to simplify user experiences, particularly for multi-step processes. It’s about not asking you to input the same information twice within a single process.
Remembering information can be a challenge, especially for users with cognitive or memory issues. It’s also tiresome for everyone else, as the effort to recall information can accelerate fatigue and lead to errors.
While the browser’s autocomplete feature offers some help, it doesn’t fully address the problem. It’s up to the website to provide you with the information you’ve already entered during a process.
This criterion doesn’t imply that websites should store your data between sessions. It only applies within a single activity. However, if a process involves different domains, such as a transaction with a third-party payment provider, it’s included in this criterion.
“Available for the user to select” includes various methods of populating fields, whether it’s choosing an option from a dropdown, copying text into an input field, or using a checkbox to reuse information.
The data that’s “available for the user to select” should ideally be visible on the same page and closely associated with the input field. But it might also be elsewhere on the page, perhaps hidden behind a show/hide component.
This criterion doesn’t apply if you’re providing data in a different way, like uploading a document. It also doesn’t affect how passwords are auto filled by your browser.
While this criterion doesn’t specifically discuss privacy, it’s important to ensure data protection when implementing features like auto-population. There’s a need to avoid exposing personal info while preventing redundant entry.
Finally, there are exceptions to this rule. For example, if re-entering info is essential, for security measures, or if the previously entered information is no longer valid.
Check out this page for more information.
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 at least one of the following:
Alternative
Another authentication method that does not rely on a cognitive function test.Mechanism
A mechanism is available to assist the user in completing the cognitive function test.Object Recognition
The cognitive function test is to recognize objects.Personal Content
The cognitive function test is to identify non-text content the user provided to the Web site.
This rule is all about making sure there’s a simple, safe way to sign in. Most websites use usernames and passwords, but remembering or writing down all that info can be really tough, especially for people with certain cognitive disabilities.
While some sites use things like recognizing objects or user-provided non-text content to help with this, it’s not the best solution for everyone.
So, instead of using a regular Captcha on your website, сonsider some alternative methods. One of the safest approaches is to use the reCAPTCHA from Google. It can be hidden, and in most cases, the user doesn’t even notice that it’s there.
As for other types of Captchas, make sure that they meet the accessibility requirements before incorporating them into your website.
More on this SC here.
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 at least one of the following:
Alternative
Another authentication method that does not rely on a cognitive function test.Mechanism
A mechanism is available to assist the user in completing the cognitive function test.
Let’s break it down. The idea here is to make sure everyone can easily and safely log in, access stuff, and get things done. It’s a lot like Accessible Authentication (the previous SC), but without any exceptions for objects or user-provided content.
When you’re going through the login process:
What’s the payoff? Even if a user has problems with memory, reading (like dyslexia), numbers (like dyscalculia), or perception-processing limitations, they’ll still be able to log in. Their cognitive abilities won’t be a barrier.
Here are some examples of websites that meet this SC:
For more information, click here.
That concludes our review. WCAG 2.2 is an important milestone in the evolution of web accessibility standards. It goes beyond the mere compliance checklist; it aims at creating a more inclusive web where everyone has equal access and opportunities.
As technology continues to evolve, it’s paramount that accessibility remains at the forefront of web design and development, ensuring that no one is left behind in the digital world.
Right after WCAG 2.2 was released, our developers dove headfirst into understanding its intricacies, focusing on the new success criteria we’ve discussed in this post. And you know what? They discovered that we’ve been incorporating these requirements into our clients’ web solutions for quite some time.
From ensuring visible focus on elements and consistent help to providing varied authentication methods, we’re committed to accommodating users of all abilities.
Need assistance in making your website or web application accessible, too? Our experts, proficient in the nuances of accessibility laws and regulations across different regions and entities are always ready to help.
Reach out to us today! Let’s work together to make the web a more inclusive space for all!
This is the second post about our approach to implementing web accessibility guidelines. This time, we explain how we're working to meet the tougher WCAG Level AA requirements.
Our civilization has come a long way in terms of human rights protection. Over the past few decades, most developed countries have made tremendous progress in the fight against the horrendous prejudices based in race, gender, or age discrimination. One of the success stories our society can proudly add to its credits is also the […]
What challenges do people with disabilities face in the digital spaces of smart cities? In this post, we explore these hurdles, the standards designed to help, and innovative assistive technologies that are making a difference.
