Part 4: Web Accessibility Principles – Robust

Our fourth and final guide on the WCAG (Web Content Accessibility Guidelines) accessibility principles covers 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 worldwide, including the ADA (Americans with Disabilities Act) and 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 detail and uses some obscure terminology, so studying criteria can confuse 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 to 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 various 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 users’ devices, 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.

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 do you 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 provides information to the user on whether a checkbox/radio button is selected or if an accordion is collapsed or expanded. The user can use assistive technology to select/unselect a checkbox item or expand/collapse the accordion list item.

This is not generally concerned 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 working with assistive technologies for years. 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 certain kinds of assistive technology 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 remain and could still cause liability issues. Second, individuals with disabilities typically have 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 consider unique cases where content may pose problems to assisted technology. A classic example is a restaurant website where all the pages are accessible. Still, 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 support assistive technologies robustly. The Robust pillar is more focused on ensuring the changes 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 the 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 and what version of the WCAG it followed 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 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 web pages 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 you can’t vouch for, but all your 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 unclear what this means to first-time users, so we’ll explain quickly. These are conformance levels referring to how stringent accessibility requirements are (often 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 a Level AAA alternative can be provided for most content. 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 of WCAG’s pillars, we wanted to end with a quick explanation of how websites can make these changes. Looking at the WCAG 2.1, you’ll see that each success criterion has an individual “How To” section about implementation. 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. Still, 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 offer newer 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 lacks 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.