Understanding WCAG 2.0: 4.1.1 Parsing

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

4.1.1 Parsing: In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features. (Level A)

Web Browsers operate under a forgiveness by default principle. They’re very liberal in what sorts of input they accept, and they do their best to show you something. Here’s an example, taken straight from that link:

Hello!

If you inspect that line, you’ll find the color is specified as “sxbxxsreen”. “Sxbxxsreen” doesn’t exist as a color, either in the real world or within the browser. While most computer programs would either ignore “sxbxxsreen” or crash, browsers make a guess. Firefox converts the whole thing to a set of rgb hex values, using 0’s for invalid characters (look for Dak’s comments in that link for full explanation). Not every browser guesses the same way.

Web browsers also guess with malformed html:

<title>hello</title>
<p>Hello!
<body bgcolor="sxbxxsreen">

There’s no doctype, no html tag, no head tag, the p tag isn’t nested properly and doesn’t close, the specified background color doesn’t exist, and the body doesn’t close. But, amazingly, my web browser renders that page without complaint:

Screenshot of the previously desribed website, showing the word hello poorly contrasting on a blue backgroundWhile this is generally a good thing (nobody really wants a browser to stop working because of a minor syntax error), it can become a problem if we depend on browsers to always guess correctly. A screen reader, which is a type of browser (though the WCAG specification refers to both browsers and screen readers as “user-agents“, I’m calling them browsers in these posts because user-agent has another meaning). And while most of us test our web pages to make sure they work in the most common browsers, none of us has every browser out there.

This standard requires four things: close open tags, nest tags correctly, don’t use duplicate attributes, and make ids unique. The easiest way to see if you meet those requirements is by validating your page. To do that, first make sure your doctype is correct, since that will tell the browser how to interpret the html. In older pages, you might see something like this at the very start of the source:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" 
                      "http://www.w3.org/TR/html4/loose.dtd">

But most new web pages use the HTML5 doctype:

<!doctype html>

which is the first and only doctype I can write from memory.

One your doctype is correct, you can use the W3C validator to check your document for errors. Here’s links for the legacy validator and the HTML5 validator.

If we validate the Lane home page, we’ll find many errors and warnings that don’t relate to the WCAG standard, and which we’ll have to interpret ourselves. For instance, there’s these:

  • Attribute xmlns:video not allowed here.
  • Attribute xmlns:product not allowed here.
  • Attribute xmlns:content not allowed here.
  • Attribute xmlns:dc not allowed here.

While technically these attributes aren’t supposed to be there (since they’re XML namespaces and not part of the HTML5 specification), none of them are duplicate attributes, so they’re allowed according to the WCAG 2.0 standard. This page also has a bunch of warnings. Some of them we can also ignore, but others are spot on:

  • Consider avoiding viewport values that prevent users from resizing documents.
  • The name attribute is obsolete. Consider putting an id attribute on the nearest container instead.
  • Consider using the h1 element as a top-level heading only (all h1 elements are treated as top-level headings by many screen readers and other tools).

Without any doubt, I should fix those three warnings. But note what this validator didn’t find: missing tags, improper nesting, repeated attributes, or duplicate ids. In other words, this page meets this standard, even though there’s some work I should do, and even though it doesn’t technically validate.

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

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

Understanding WCAG 2.0: 3.3.4 Error Prevention (Legal, Financial, Data)

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.

Understanding WCAG 2.0: 3.3.3 Error Suggestion

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:

Wrong

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

Please make sure your zip code contains exactly five numbers, then resubmit the form

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

Invalid Password. Your password must meet the following rules:

  • Not be more than 255 characters long
  • Contain at least one number
  • Contain a special character (!, @, #, $, %, ^, &, *)
  • Contain both an uppercase and a lower case letter
  • Not contain a space character
  • Be at least 8 characters long
  • Use only ASCII characters
  • Not contain your username or birth date
  • Not be written down on a note under your keyboard

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:

Please make sure your zip code contains exactly five numbers, then resubmit the form

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:

Screen shot of the Twitter sign up form, showing an error message next to an invalid phone numberBut that leads us back to linking the error message and the form component. WAI-ARIA provides a way to do that:

Please make sure your zip code contains exactly five numbers, then resubmit the form

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.

Understanding WCAG 2.0: 3.2.3 – Consistent Navigation

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:
Gif of Woman's eyes getting closer and closer, while looking more and more stern

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:
Gif of Dweight Schrute from the Office screaming

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.