The next standard we’ll explore in our series on understanding WCAG 2.0 is 3.3.4 Error Prevention. This standard is required for WCAG level AA compliance, which is part of what Section 508 requires. Here’s the complete text (it’s a long one):

3.3.4 Error Prevention (Legal, Financial, Data): For Web pages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of the following is true: (Level AA)

1. Reversible: Submissions are reversible.
2. Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
3. Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.

Here’s the idea: sometimes users, especially those with disabilities (and me, as you’ll see in a minute), submit forms either by accident or without fully understanding what happens when the form is submitted. Imagine, for example, someone with motor control issues who accidentally presses enter early while filling out a form, submitting it. This standard asks us to make sure that one of the three things in that list applies to the form.

There are a number of circumstances where we don’t need to do anything at all. For example, say we have a web form in our ERP that lets us set an address. As long as changing the address again is easy (for example, by filling out the form again), and we’re shown what the new address is after submission (either as a confirmation, or just with a page reload on submit), then we’re in good shape.

But we need to look for web forms that are not easily reversible. For instance, let’s look at a situation which may or may not have happened in my life about ten years ago. I was trying to pay a bill online. When paying it, I misplaced a decimal point, and paid ten times as much as I owed (like this: $3000.0). The system processed my payment without complaint, overdrawing my checking account, bouncing a $2.00 check at the library, and leading to so very many bank fees. A  simple confirmation page (which, to be fair, they’ve added), or even better, a confirmation page that warned me my payment only had one 0 after the decimal point, would have saved me a lot of grief.

What’s tricky about this accessibility requirement is that most of us rely on third party services for these kinds of legal, financial, and data programs. We buy our ERP system and payment processing systems from vendors, rather than create them at home. Even though we’re not doing development ourselves, we’re still responsible for ensuring our systems are complaint. If your system is receiving updates, and compliance won’t be available by January 18th, 2018, you may need to file a bug with your vendor.

If you’d like to know more about this method, check out these examples and techniques.

Interested in more? Check out the listing of all the posts in this series.

The next standard we’ll explore in our series on understanding WCAG 2.0 is 3.3.3 Error Suggestion. This standard is required for WCAG level AA compliance, which is part of what Section 508 requires. Here’s the complete text:

3.3.3 Error Suggestion: If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content. (Level AA)

This standard has to do with input validation. Let’s say that we have a webform, like this:

This standard is all about what happens when you enter the wrong thing. Say, for example, we enter “9740” as our zip code. This is the wrong way to tell the user:

To meet this standard, all you need to do is provide a helpful error message:

Of course, you don’t want go to the other extreme, either. Think about this nightmare:

One of the goals of this standard is to help people with cognitive disabilities. Yes, that error message explains all the possible circumstances that could have caused the error. But the suggestions aren’t helpful — you have to work to figure out which rule you violated.

And that’s it for this standard. If you’d like to avoid the the messy details, you’re welcome to just skip to the end. But this post got me thinking. When you’re making a form, labels are associated with form fields via the for attribute on the label and the id attribute on the field. That way a screen reader knows how to associate labels and form elements. But how does that work with an error message? There’s no for attribute for an error message. Right?

How to Associate an Error Message with a Form Element

The first place my research took me was the WebAIM site, which suggests a two part approach. First, error messages should be listed at the top of the form. Second, each error message should link to the associated input element. So our form would look like this:

This method meets accessibility requirements, but fails from a usability perspective. If we were to expand that form to have several fields, then visually associating error messages and fields would be difficult. The best practice is to instead display the error message next to the form component it applies to, like Twitter does:

But that leads us back to linking the error message and the form component. WAI-ARIA provides a way to do that:

I know that looks pretty much exactly the same, but I promise if you break out your developer tools, there’ll be some extra attributes. First, we need to add aria-invalid=true to the input (depending on your error, there are some additional attributes you can use). Then, we add the aria-describedby attribute to the input and have it point to the id on our error message.

If you’d like to know more about this method, check out this page on WAI-ARIA regarding form validation. Or, if you’d just like to know strictly what WCAG 2.0 requires, you can look at these examples and techniques. Specifically, be sure to check out the technique for using aria-required to indicate a required field – just putting a * next to each field isn’t good enough. This blog post provides some additional examples and advice.

Interested in more? Check out the listing of all the posts in this series.

The next standard we’ll explore in our series on understanding WCAG 2.0 is 3.2.3 Consistent Navigation. This standard is required for WCAG level AA compliance, which is part of what Section 508 requires. Here’s the complete text:

3.2.3 Consistent Navigation: Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user. (Level AA)

Imagine you’re on a page, and you see these three menu items:

• Home
• Cat Pictures
• Contact

Obviously, you click the Cat Pictures link. After enjoying some amazing pictures, you want to contact the site owner and contribute your own amazing pictures. So you go to click on the bottom link in the navigation. And what do you find?

• Contact
• Home
• Cat Pictures

You:

But it’s ok. You adapt. You click the contact link at top, and contribute your pictures, and the page reloads, thanking you for your pictures. Of course, now you want to see your pictures in the gallery. But what do you see on the reloaded thank you page?

• Cat Pictures
• Contact
• Home

Then you do this:

There’s two ways I’ve seen this happen. One, the rare way, is that someone just wrote their menu query with select * from menu and didn’t bother to set an order by clause, and the database server has (for reasons known only to it) changed how it’s returning results. The much more common way is that some PHP programmer got lazy and rather than put the menu links in an included template file, he just has a PHP file per page, with all the menu links in them, and somewhere while doing edits he mixed up the order. I may or may not speak from experience.

There’s two almost exceptions to this rule. One, you’re welcome to insert additional links within your menu – that’s what they mean by relative order. So although your page may show just the three links in the examples above, once you click on the Cat Pictures link, it’s ok to have this:

• Home
• Cat Pictures
  • Cats with short hair
  • Cats that shed everywhere
• Contact

As long as the three top level links keep the same order (Home, Cat Pictures, Contact) on every page, you’re golden.

The second exception has to do with the phrase “set of web pages”. If you have two sites, one in English (at example.com/en/), and one in Spanish (example.com/es), then the navigation between them doesn’t need to match. So if your menus are ordered alphabetically, and that order changes because the language changes, that’s ok (though make sure you’re setting your page default language!).

And, though we’ve talked mostly about menus on this post, note that the standard actually applies to any recurring navigation element. So things like footer links, search boxes, and skip links should all be consistent.

If you’d like to read more on this statement, you may also be interested in these examples and techniques.

Interested in more? Check out the listing of all the posts in this series.

The next standard we’ll explore in our series on understanding WCAG 2.0 is 3.1.2 Language of Parts. This standard is required for WCAG level AA compliance, which is part of what Section 508 requires. Here’s the complete text:

3.1.2 Language of Parts: The human language of each passage or phrase in the content can be programmatically determined except for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text. (Level AA)

This standard is very similar to 3.1.1, which deals with the default language of the entire page. This standard simply provides a way to display multiple languages within the same page. So for example, here’s a paragraph of text in Arabic (from Wikipedia):

كولومبوس (إنديانا) هي مدينة تقع في الولايات المتحدة في Bartholomew County. يقدر عدد سكانها بـ 44,061 نسمة ومساحتها 72.23 كم² و وترتفع عن سطح البحر 192 متر.

That paragraph is right aligned because Arabic is read from the right to the left. Here’s the source of that paragraph:

<p dir="rtl" lang="ar"><b>كولومبوس (إنديانا)</b> هي مدينة تقع في الولايات المتحدة في Bartholomew County. يقدر عدد سكانها بـ 44,061 نسمة ومساحتها 72.23 كم<sup>2</sup> و وترتفع عن سطح البحر 192 متر.</p>

There’s two attributes added to the p element, dir and lang. Only the lang attribute is required to comply with this standard, but because the language is read right to left, we also need to provide the dir attribute to clarify to both browsers and screen readers that they should read from right to left.

I’m afraid that I’m not sure why it’s necessary to specify the text direction if you’ve already specified a language – after all, Arabic, Farsi, and Hebrew are always read RTL, so isn’t the dir attribute redundant? The W3C says no, you must use both. I wish I could find a more clear rationale.

If you’d like to read more on this statement, you may also be interested in these examples and techniques.

Interested in more? Check out the listing of all the posts in this series.

The next standard we’ll explore in our series on understanding WCAG 2.0 is 3.1.1 Language of Page. This standard is required for WCAG level A compliance, which is part of what Section 508 requires. Here’s the complete text:

3.1.1 Language of Page: The default human language of each Web page can be programmatically determined. (Level A)

When a screen reader reads a page, it needs a voice to use. Here’s the default voice on my Mac reading some words in Spanish:

That’s not too dissimilar from how I sound, which isn’t a coincidence. The default voice tried to pronounce words like an American English speaker (IETF code EN_US), which is what I am. The problem in the audio file above is that we told my computer to pronounce Spanish words (“¡Hola! Cómo estás!“) as though they were in English.

If we’d instead told the computer the words were in Spanish, we’d have heard this:

That uses the ES_ES voice (which, on a Mac, is named Monica). And it sounds totally natural (or, at least, as natural as computer generated language can be).

To specify a language for your entire document, simply add a lang attribute to the html tag:

<html lang="en">

Confusingly, the language codes we use in HTML are different from the IETF codes. Instead, we use ISO-639-1.

Sometimes it isn’t possible to modify the tags on the page. For instance, you might be using a platform that generates HTML, and you don’t have access to change the output. In those cases, you can instead add a Content-Language header to your server:

Content-Language: en

But sometimes, that’s not an option either. You might be stuck with a platform that can only generate HTML 4.01, or you might only be able to insert tags into the header and body, but not modify html tag directly.

For those times, your only option is to use the absolute wrong way to specify a language:

<meta http-equiv="content-language" content="en">

This meta tag (meaning a tag that’s about a page, rather than part of a page), is now considered obsolete. But if it’s your only option, it’s your only option.

If you’d like to read more document language codes, you may also be interested in these techniques, which provides more detail. I also found this blog post very helpful, as well as this page on w3.org.

Interested in more? Check out the listing of all the posts in this series.

The next standard we’ll explore in our series on understanding WCAG 2.0 is 2.4.6, Multiple Ways. This standard is required for WCAG level AA compliance, which is part of what Section 508 requires. Here’s the complete text:

2.4.6 Headings and Labels: Headings and labels describe topic or purpose. (Level AA)

For a really short standard, there’s a lot to unpack.

The first thing you might notice is this standard doesn’t explicitly require headings or labels. While labels are definitely required, there’s actually no specific requirement to have headings on your pages. If it’s appropriate to not have any headings, you are (from an accessibility standpoint) welcome to have nothing but paragraph after paragraph after paragraph.

But situations where it’s appropriate to not have any headers are rare, and adding headers makes your document more navigable. For example, most PDF readers will automatically generate a clickable table of contents for you, as in this picture:

Screen readers can take advantage of headers in a similar way. Imagine if you were stuck listening to your computer reading you all 624 pages of that book sequentially. It’d be almost useless to you. Being able to jump to certain headers would help a lot.

Standard 2.4.6 simply says that if you’re using headers, you need to use headers that describe the topic or the purpose of the subsequent section.

But buried further down on that post, in a little green note, there’s a bit of text that says “Note: Headings and labels must be programmatically determined, per Success Criterion 1.3.1”

Programmatically determined is a tricky phrase. Just about anything is programmatically determinable – so that seems like a phrase ripe for abuse. Fortunately, WCAG 2.0 provides a definition:

determined by software from author-supplied data provided in a way that different user agents, including assistive technologies, can extract and present this information to users in different modalities

So if we do use headings, not only do that have to be programmatically determinable, they need to be programmatically determinable by the software that interprets that page.

If that doesn’t make sense, it might be easier to look at some examples. The paragraph in the example comes courtesy of wikipedia, which has some surprisingly awesome writing.

Parentheses

Parentheses may be nested (generally with one set (such as this) inside another set). This is not commonly used in formal writing (though sometimes other brackets [especially square brackets] will be used for one or more inner set of parentheses [in other words, secondary {or even tertiary} phrases can be found within the main parenthetical sentence]).

That example fails, because the heading above is a paragraph element – there’s no way to determine that it describes the subsequent content.

Parentheses

Parentheses may be nested (generally with one set (such as this) inside another set). This is not commonly used in formal writing (though sometimes other brackets [especially square brackets] will be used for one or more inner set of parentheses [in other words, secondary {or even tertiary} phrases can be found within the main parenthetical sentence]).

This one looks ok, but isn’t. Boldface isn’t a heading standard, so most user agents wouldn’t consider it one.

#Parentheses

Parentheses may be nested (generally with one set (such as this) inside another set). This is not commonly used in formal writing (though sometimes other brackets [especially square brackets] will be used for one or more inner set of parentheses [in other words, secondary {or even tertiary} phrases can be found within the main parenthetical sentence]).

This one is different, because rather than HTML it’s a format called markdown. Markdown has very specific rules about formatting text, which make it easy to determine where a heading is. Remember: the WCAG guidelines apply to all documents.

Parentheses

Parentheses may be nested (generally with one set (such as this) inside another set). This is not commonly used in formal writing (though sometimes other brackets [especially square brackets] will be used for one or more inner set of parentheses [in other words, secondary {or even tertiary} phrases can be found within the main parenthetical sentence]).

That’s probably the best example here – we’re using the H1 tag for the heading. Not only does the browser apply some styles to make it obvious to most folks where the heading is, but we’re using semantic HTML and adhering to a standard browsers can use to navigate pages.

One last example:

The Marathon

Parentheses may be nested (generally with one set (such as this) inside another set). This is not commonly used in formal writing (though sometimes other brackets [especially square brackets] will be used for one or more inner set of parentheses [in other words, secondary {or even tertiary} phrases can be found within the main parenthetical sentence]).

This example uses a heading with the correct markup, but it doesn’t provide the topic in any way, so it fails this guideline.

At Lane, to keep pages consistent, any page that will be interpreted by the browser as HTML should use semantic HTML, with headings and other elements used correctly. Documents that aren’t HTML are a little trickier. In Microsoft Word, for instance, many people use font sizes and bold face to create headings. That’s really not ok – you should be using the headers tools.

If you’d like to read more about the headers and labels guideline, you may also be interested in these techniques, which provides examples and more detail.

Interested in more? Check out the listing of all the posts in this series.