web-accessibility-introduction-3-large

An introduction to accessibility: Part 3

Adam Soucie's Layout avatar

In the first article in our overview of accessibility, we discussed the standards of a site being perceivable. In the next, we talked about the requirements for a site to be operable. For the last article in our accessibility overview, we’ll cover the final two tenets of accessible websites: understandable and robust. Understandable, on the surface, sounds pretty self-explanatory. But robust? What the heck does that even mean? That’s what we’re here to find out.

Let’s start with understandable.

Understandable

The standards state: “Information and the operation of user interface must be understandable.” From a content perspective, that seems like a “well, obviously (rolls eyes),” and you’d be right. The principle of a site being understandable should be a clear concept, but like an iceberg, what’s on the surface and what’s underneath are two completely different things.

For a site to be understandable, it must cover three main points: be readable, be predictable, and when user input is involved, provide assistance. A user must be able to read your content from a language point of view, have the site behave in a predictable manner (the way “most” websites behave), and be given basic directions when asked to provide input (think labels on a contact form).

web-accessibility-introduction-3-input

Language is a large part of the understandability standards. At the base level, this means using the lang attribute on your main HTML element. WordPress themes should do this be default. The lang attribute is an A-level standard, meaning it is required by Section 508 law. If your theme does not, you’re likely to run into several other accessibility issues. You may want to seriously consider another theme as a result.

One of the more serious aspects of an understandable site is what happens when focus is applied. We discussed focus a lot during the last article of this series, but it needs to be addressed again. When an element takes focus, the context of that element should not change. That’s a scientific way of saying a button should not be activated simply by applying focus. Put yourself in the shoes of a person navigating with the keyboard. You hit the tab key to move to the next link, and suddenly a new page loads. Would you understand what’s going on?

The understandability standard, especially its predictability aspect, are why expected button behaviors are so important. A user should not submit a form until they activate (click or hit the enter key) the button. Simply mousing over it or tabbing to it should not change anything other than apply a hover or focus CSS state change.

Another key element of predictability involves your site’s design. Things like hover and focus states should be consistent throughout a site. This allows users, especially those with visual challenges, to see state changes more effectively. They may not be able to read the button text right away, but by noticing a change in color contrast, they’ll know they’ve hovered or focused on the element. This is not only good design, it is good accessibility.

It is important to note at this point that many of the understandability standards are of the AAA-level. While they are not required by law, this does not mean they should not be considered. For example, take standard 3.1.5 – Reading Level operates on a sliding scale depending on your target audience. That standard references a reading level of lower secondary school. This equates to approximately a 6th grade reading level, the standard for most modern American newspapers, but not even newspapers follow this standard depending on the topic.

When writing for the web, you have to keep your consumers in mind. If your target is researchers working on their doctoral degrees, your content should be on a similar level. But if you’re writing for the general public, you’ll want to factor in something like the Flesch-Kincaid Reading Scale. If you use the Yoast SEO plugin for your WordPress site, the Flesch scale test is built in. It will provide you with a breakdown, evaluating passive voice, transition words, and the length of your sentences. Again, keep your target audience in mind. The Yoast checker assumes you’re writing for a general audience. Your goal should not be a green check from Yoast, but quality content for your audience.

web-accessibility-introduction-3-content

The last key part of understandability is input assistance. At a minimum, this means two things: text error messages and labels on your form inputs. Users must be told what each form input is for and notified with text if an error occurs. Those are the two A-level, required by law standards. If you’re using one of the popular form plugins like Gravity Forms or Caldera Forms, you’re already covered on the error messages portion for simple fields. You’ll still need to make sure your elements are labeled. Proper labeling is its own topic entirely, but for now just make sure you’re providing sensible instructions (“Name” for the name field, “Email” for an email field).

Robust

The final tenet of accessibility is whether or not a site/piece of digital content is robust. Specifically, “content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.” In short: make sure it works, regardless of the technology. There are only two standards involving a robust site, and both are A-level, required by Section 508 law.

A robust site is one that follows HTML standards. Elements are fully formed, and closed when necessary. If you open a <p> tag, close it when the paragraph is done. It’s another instance of “well, obviously,” but mistakes happen. Run your site through an HTML validation service before going live. The W3C provides a free service. Use it, fix your errors, and you’ll be good to go.

The other aspect of a robust site is where WAI-ARIA (Web Accessible Initiative – Accessible Rich Internet Applications) or ARIA truly comes into play. ARIA is it’s own topic, but in short you should be using it only when required. Some instances are labeling a form element with ARIA when the form label is otherwise invisible. Doing so will also keep you covered as regards the input assistance of understandability, depending on how else the form element is labeled.

Conclusion

Web accessibility appears to be a complex topic on the surface. In some ways it is, but often times the solutions are simple. To have an accessible site is to have one that every potential user can enjoy. From a business standpoint, this deepens your potential customer pool. More importantly, from a human standpoint, you’re not excluding anyone.

Over the next few months, I’ll dive deeper into some of the topics we’ve introduced in this overview series. Until then, review the standards and review your sites. Make a list of what needs to be fixed and prioritize it based on the standard level (A, AA, or AAA). If you can’t fix it yourself, hire an accessibility consultant. They’d love to help you improve the internet for all of your potential users.

Comments ( 0 )

Join the discussion