Understanding WCAG 2.0: 2.4.5 – Multiple Ways

The next standard we’ll explore in our series on understanding WCAG 2.0 is 2.4.5, 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.5 Multiple Ways: More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process. (Level AA)

At first glance, it might be surprising this is even an accessibility guideline. But the WCAG 2.0 guidelines are designed to help everyone use and navigate the web. And this guideline is all about helping people navigate the web.

There’s two pieces to this guideline. The first requires two different ways to get to a given page. That’s not a hard guideline to meet. The easiest way is to have each page linked to from another page as well as each page accessible from a search engine. That’s what we strive to do on the Lane site. Orphans, pages that aren’t linked at all, directly violate this guideline (though we’ll come back to them in a minute).

Another option is to use a site map. But be careful with this one. The SEO definition of a site map is something more akin to our sitemap XML files. But those pages aren’t accessible at all, nor even intended for humans to read. The WAI has a great example of a human accessible site map that does help to meet this guideline.

The second half of this guideline deals with an exception. There’s sometimes information that needs presenting as a result of a process, which isn’t appropriate for people to find any other way. For example, say there’s a confirmation page which appears after you register for a class. It isn’t really appropriate for this page to be found through search or even to be linked at all. It should only be seen in the context of successfully registering for a class.

A couple places you should look out for issues. If your server has a robots.txt file that prevents search engines from indexing pages, remember that search engines may not index your page, so beyond linking to your page, make sure you offer a second path (either a separate internal search engine, a site map, or one of these other techniques). Also be alert to pages that you might have excluded from your sitemap file (the SEO kind), since those pages are a lot less likely to show up in search. And watch out for pages behind authentication, as they’re usually not indexed by search engines, and due to permissions levels can be hard to integrate into site maps.

If you’d like to read more about the multiple ways 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.

Understanding WCAG 2.0: 2.4.4 – Link Purpose

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

2.4.4 Link Purpose (In Context): The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general. (Level A)

Before we get into this standard, let’s first take a look at how sighted people read on the web. And to do that, we first need to discuss this contraption:

An eye tracking machine. Described in detail in textThat’s a modern eye tracker – the ones I used in college were closer to these. But they all work the same. You rest your head on a head rest and a camera records where your focus is as you look at a screen. Lots of interesting work has been done with eye trackers, like determining that your eyes don’t move smoothly over text while reading. On the web, eye trackers have helped us learn that people don’t carefully read pages from the top to the bottom, carefully considering every line of text. Instead, people read pages in an F shaped pattern:

A screenshot of a web page, showing a heat map over laid on top of it, with the red areas in a vague F patternThat’s part of an image from this page discussing the F-shaped pattern at length. People are busy and don’t really read web pages. They read a little across the top, then they scan.

Why should we expect non-sighted people to be any different?

Most screen reading software (JAWS of course, but even Voiceover, which comes with Macs) features tools that make it possible to jump around the page, effectively skimming for content the visitor is interested in.

Which brings us back to link purpose. Imagine you’re using a screen reader, and you ask it to get you the links in a page, so you can skim to the one you’re looking for. It gets you these:

Would you have any idea what class you were going to look at for the second link? To meet this standard, we’d need to adjust how that link is presented in the page. So let’s work with an example. We’ll assume I’m putting together a short snippet that links people to my Underwater Basketweaving class.

<a href="https://classes.lanecc.edu/course/view.php?id=50473">
  https://classes.lanecc.edu/course/view.php?id=50473
</a>

That’s about as bad as you can possibly do, and almost exactly what’s in the list above. It’s just a linked URL in the page, with no context at all.

<a href="https://classes.lanecc.edu/courses/underwater-basketweaving/schmidt">
   https://classes.lanecc.edu/courses/underwater-basketweaving/schmidt
</a>

That’d be better – that’ll still appear as just as link on the page, but at least it’ll be a meaningful and friendly url. Not ideal, but better than what we had before. Also, better for SEO. Better yet would be to set the link text to be something meaningful:

<a href="https://classes.lanecc.edu/course/view.php?id=50473">
  Underwater Basketweaving Class
</a>

That’d look like this: Underwater Basketweaving Class, which could be perfect. But that isn’t your only option. You can instead choose to provide context in the surrounding text:

<p>Check out the Underwater Basketweaving class
  <a href="https://classes.lanecc.edu/course/view.php?id=50473">
    https://classes.lanecc.edu/course/view.php?id=50473
  </a>
</p>

You can also make use of the title attribute to clarify the purpose a link:

<a title="Underwater Basketweaving Class" href="https://classes.lanecc.edu/course/view.php?id=50473">
  Learn about the best class around!
</a>

If you have a particularly complex situation, like where a single label for a link can apply to multiple links, you can also use the aria-labeledby attribute. Confusingly (at least to me) there’s also the aria-label attribute which can be used as well. But I’m not sure why you’d prefer that to the title.

There’s a lot more information available on link purpose, in particular the rest of the techniques I didn’t discuss above.

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

Understanding WCAG 2.0: 2.4.3 – Focus Order

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

2.4.3 Focus Order: If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability. (Level A)

Any part of a program or web page that can receive input from the user can have focus. Let’s take a look at a webform, so we have a something to reference:

Sample Form




This is an interactive webform, so you can click in either of the input boxes. Go ahead, try it right now. I’ll wait.

There’s four elements on that page that could receive focus, but only three that can. I’ve marked the submit button as disabled, so you can’t click it. That element can’t have focus, so you can’t submit the form.

There’s a couple ways to navigate that form. If you’re sighted, you might use the mouse to first click in the first box, and then again to click in the second box. But if you can’t see the screen, it’s hard to use a mouse. Instead, you’d probably use the tab key to move between elements.

The sequence focus follows when tabbing is called the tab order, and is set using the tabindex attribute on html elements. I didn’t set the tab index on any of those elements, so the browser automatically fills in the tab order for us, using the structure of the HTML – in this case, from top to bottom. But take a look at this form:

Bad Sample Form




Doesn’t that feel a little… evil?

For the purposes of editing our web pages, that’s really all there is to this standard. Make sure that the order you move from input to input on your pages makes sense. And if it doesn’t, use the tabindex attribute to fix it.

If you’re doing web development, there’s a little more to consider. Using CSS, it’s possible to position elements in a different order visually than the way they’re written in code. That isn’t necessarily against the rules, but you need to make sure the tab order still works (in addition to the concerns in 1.3.2). Also be alert to things like modal dialogs, or popovers which can visually steal focus from the webpage, but which may not trap the tab key, and may mean someone with low vision can only see the modal, but can still tab outside of it.

If you’d like to read more about focus order, you may also be interested in these techniques, which provides examples and more detail.

And if you’ve never watched a blind person use a computer, you really should. That video is part of a great, funny collection of videos on what it’s like to live without sight.

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

Web Goals check-in

As promised in our initial goals post, a month as passed and now it’s time to check-in and see where we are on meeting our goals. As a review, those goals were:

  1. Reduce the total number of pages on the Lane website by 5% (from 5768 to 5475).
  2. Reduce the number of pages with more than 20,000 characters by 20% (from 193 to 155)
  3. Reduce the average character count of our pages by 10.5%, from 4803 to 4300.
  4. improve the average age of our pages by 6 months, from roughly 24 months old to 18 months old.

Let’s take a look in order, along with some graphs. On each of these graphs, the straight line is the trend line – in order to keep on track for our goal, we need that line to be below the trend line.

Reduce the total number of pages on the Lane website by 5% (from 5768 to 5475)

Clearly, we’re running behind – the count as of today is 5737, about 110 more than we’d hope to have. It turns out that removing pages is really hard. While we’ve removed some things to our archive, we’re fighting an uphill battle as things like news releases and meeting minutes get added.

Reduce the number of pages with more than 20,000 characters by 20% (from 193 to 155)

We’re making progress on this one, but again, it turns out to be really hard. We have 185 nodes with more than 20,000 characters, but we were looking to only have 174 this week. Many of the pages that are really long are actually Board Minutes, which we don’t delete and can’t shorten. Right now we’re optimistic we’ll still find enough pages to fix, but this will be hard.

Reduce the average character count of our pages by 10.5%, from 4803 to 4300.

Although we’ve managed to improve from 4803 characters to 4706, we’re still 150 characters over where we wanted to be. Again, it turns out the board minutes are in large part to blame. But we’re still optimistic.

Improve the average age of our pages by 6 months, from roughly 24 months old to 18 months old.

We came closest on this one. At the start of last month, our average page had last been edited on 11/12/14. Now, that date is 2/3/15 – almost three months newer. That’s a lot of page edits. But we’re still two weeks behind our goal for today, which was 2/21/15.

When tackling this goal, we had a separate subgoal to reduce the number of pages we have that have gone more than four years without an edit. Lori’s done a lot of work on this list, reducing the number of pages on it from 732 to 612, which makes a pretty impressive graph:

Surprisingly, despite all that effort on our very oldest nodes, it wasn’t enough. But we have a month to go, so there’s still some time. We’ll check in again on January 1st!