Our fourth and final guide on the WCAG (Web Content Accessibility Guidelines) accessibility principles is covering the Robust pillar, and how businesses can meet important compliance requirements.

Before we dive into the details, here’s why the WCAG 2.1 is so important for today’s websites. This global standard is referenced by many accessibility and rights laws around the world, including the ADA (Americans with Disabilities Act) and even some state legislation. This comprehensive guide outlines, in detail, how websites should be accessible to individuals with disabilities. It’s occasionally updated to cover new technology, which is why it’s in version 2.1.

The WCAG 2.1 is divided into four pillars, each tackling a different subject: Perceivable, Operable, Understandable, and Robust. Each section provides a list of criteria for each pillar. However, the WCAG goes into lots of details and uses some obscure terminology, so studying criteria can be confusing for newcomers. We’re making it easy with clear guides on what each pillar expects! Let’s start with what Robust refers to.

What the “Robust” WCAG 2.1 Pillar Means

The other pillars primarily focus on web content and web design, with criteria specifying what websites need to do to be accessible by those with a variety of disabilities. The Robust pillar is a little different: It focuses on how compatible and adaptable the website is with different technologies (what the WCAG calls “user agents”). That means a website should be designed to work with a wide range of devices and made to keep working with them for years to come.

This is helpful for all kinds of websites, because Robust isn’t just about supporting assistive technology – it’s about support for a variety of common devices, including browsers and touchscreens. Making sure a website is robust helps users on smartphones or tablets.

WCAG Robust Criteria

The Compatible Guideline

The success criteria within the compatible guideline ensure that, on a fundamental level, website code works with the devices that users have, including assistive technologies. Assistive technology can range from joysticks and special touchscreens or keyboards to screen readers and magnifiers. The criteria in this section are excellent best practices for all websites and will help avoid mistakes or bugs. Important steps include:

• Parsing: This criterion is all about avoiding errors in your code: Don’t forget end tags, nest website elements correctly, avoid duplicate attributes, and so on. In other words, use proper HTML structure and ensure your code doesn’t contain errors – when there are errors, user agents attempt to repair poorly coded content, and some technologies may translate incorrectly, affecting browser compatibility and user experience. If a browser can’t display web content because of a coding bug, it will be even worse for various assistive technologies.How to validate code or check for possible errors? There are many online and offline markup validators – some popular tools include:
  • The W3C Markup Validation Service
  • HTML Validator Chrome extension
  • CSS HTML Validator (formerly CSE HTML Validator)
  • Web Developer Chrome/Firefox extension
  • W3C Nu Markup Validation Service
• Name, Role, and Value: This criterion requires that website elements (including links and other components), have names and roles that can be programmatically determined, and that user agents like assistive technology can properly understand them and know when they’ve changed. For example, a screen reader provided information to the user on whether a checkbox/radio button is selected or if an accordion is collapsed or expanded. And the user can use assistive technology to select/unselect a checkbox item or expand/collapse the accordion list item.

This is not generally a concern with standard user interface components in HTML but is especially important for developers creating custom scripts or components.

• Status Messages: Status messages are new content added to the page, such as a confirmation message, progress bar, form errors, the # of results when a search is performed (but not necessarily the search results themselves), or an update to shopping cart when an item is successfully added. Markup languages (e.g., HTML) use status messages to display a variety of information and assistive technologies need to be able to announce these to the user without interrupting the user’s task at hand by shifting focus. Here we’d use the role attribute to denote a status to allow screen readers to announce new content to the user. For form errors, we might use the role attribute of alert to announce the input error.

Tips About Creating a Robust Site

• It’s a good idea to always use the latest and most efficient coding solutions to make a website robust. This helps ensure that the site will continue to work with assistive technologies for years to come. This also means you won’t have to worry about updating your website repeatedly for web accessibility. Currently, developers are using a variety of HTML5 solutions for screen reader-friendly tags.
• It’s very easy to test out certain kinds of assistive technology if you want to see how accessible your website is. Some of the most popular screen readers in the world, like NVDA, are free to download and use for tests to see how your description tags work, for example. Even taking out a smartphone and seeing how your website automatically resizes or magnifies content can tell you a lot. See our article for more Tools for Website Accessibility Testing
• As we have mentioned before, be careful of relying on website overlays that provide a handful of tools like screen readers or magnifiers. These are problematic. First, they don’t actually make core changes to your website, so underlying problems may still remain and could still cause liability issues. Second, individuals with disabilities typically have their own screen readers or magnifiers they prefer using. Third, overlays can only address some of the accessibility issues with websites, not all of them.
• Website developers should pay attention to unique cases where content may pose problems to assisted technology. A classic example is a restaurant website where all the pages are accessible, but the menu links to a PDF that’s not accessible, so many users with disabilities can’t tell what food to order. If content is available on a site, including downloads or additional formats, it should be accessible.
• Remember that Robust isn’t a pillar that works on its own. The Perceivable and Operable pillars in particular are necessary for a website to robustly support assistive technologies. The Robust pillar is more focused on making sure the changes made to a website will last and will work with as many user agent devices as possible.
• We haven’t touched on rarer types of assistive technology, such as refreshable Braille displays or head pointers. But the same principles of Robust and Operable apply to them as well. As long as code is neat and bug-free, and there’s no awkward pointer placement, websites should do well in these cases, too.

Conformance Claims

The WCAG also includes information on how to make conformance claims on a website. That would be something like a webpage or section detailing that the website follows the WCAG, what version of the WCAG it follows, when it was last updated for accessibility, and similar information.

Creating a conformance claim is not necessary to meet WCAG standards. However, it may be a good idea for many businesses. Including a conformance claim can make it far less likely that your business site will be targeted for an ADA lawsuit, a practice that’s on the rise lately.

Additionally, a conformance claim is just good marketing. It lets visitors know that you care enough about the site to make it easy to use and accessible for everyone.

In addition to what we mentioned above, the WCAG also asks that you specify the link to the version of the WCAG in question, what Level of the WCAG has been satisfied (more on this below), and a list or description of the webpages for which the claim is made – in case certain sections of the website do not meet the WCAG yet. There are also options to state partial conformance, which may happen if your website hosts third-party content that you can’t vouch for, but all your own content follows the WCAG.

About the WCAG Conformance Levels

Individual criteria for the WCAG are labeled by “Level” going from A to AAA. It’s not immediately clear what this means to first-time users, so we’ll give a quick explanation. These are conformance levels referring to how stringent accessibility requirements are (many times conformance and compliance are used interchangeably, as we do).

Level A indicates baseline compliance, the sort of steps all websites should take. Level AA indicates particularly useful requirements for individuals with disabilities. To meet Level AA, it also meets Level A compliance. Most businesses should focus on meeting Level AA compliance to help avoid problems like fines or lawsuits as well as making their website accessible to all, which creates a better user experience all around.

For Level AAA, which is typically reserved for government entities, the site must meet all the criteria in WCAG 2.1 (and upcoming releases of WCAG). This is particularly hard to achieve for some content, but for most content, a Level AAA alternative can be provided. In this case, your conformance claim can include which pages satisfy this level of conformance and/or progress towards meeting the success criteria within this top level of compliance.

An Important Note About Making Changes Using the WCAG

Now that we’ve covered all the WCAG’s pillars, we wanted to end with a quick explanation about how websites can make these changes. If you look at the WCAG 2.1, you’ll see that each success criterion has an individual “How To” section about implementing. In this section, the WCAG provides examples of “techniques and failures,” examples of different coding solutions and a look at what doesn’t work.

These techniques can be very useful for developers looking for ways to implement the WCAG, but they are only suggestions, or what the WCAG calls “informative” vs. the requirements of the “normative” criteria. Web development is always evolving, and while the WCAG tries to give current examples, they are offering newer methods or alternative methods to achieve the success criteria. In other words, developers have plenty of options beyond what the WCAG shows. The best choice usually depends on the type of website, how it was originally coded, and just how much an organization wants to change.

Are You Seeking Help with Website Accessibility?

Website accessibility can be difficult to handle in-house, especially if your team doesn’t have much experience with web design and coding. Blue Atlas Marketing has helped many clients achieve accessibility and avoid liability issues with our experienced developers. Contact us to ask any questions you have about your website, and to find out more about our services.