accessibility – Page 3 – Lane Community College Web Team

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.

Understanding WCAG 2.0: 3.1.2 – Language of Parts

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:

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

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.

Understanding WCAG 2.0: 3.1.1 – Language of Page

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.

508 Refresh is done!

So we’ve been waiting a long time for the Section 508 refresh to finish. There’s even a time lapse of Matt Damon waiting for the updated rule:

Matt Damon's aging scene from Saving Private Ryan

But it’s here. Finally, actually here. Published on January 18th, and in effect in one year. You can read the entire thing online (scroll to the end for the appendix to find the actual rule) or just keep reading for the parts I found interesting.

As expected, it looks like the new rule matches pretty closely with WCAG 2.0:

For Section 508-covered ICT, all covered Web and non-Web content and software – including, for example, Web sites, intranets, word processing documents, portable document format documents, and project management software – is required, with a few specific exceptions, to conform to WCAG 2.0’s Level A and Level AA Success Criteria and Conformance Requirements

There’s also a safe harbor for the new rule:

…the Revised 508 Standards include a “safe harbor” provision for existing (i.e., legacy) ICT. Under this safe harbor, unaltered, existing ICT (including content) that complies with the existing 508 Standards need not be modified or upgraded to conform to the Revised 508 Standards

In other words, if your existing stuff is compliant with the old 508 standards, and you don’t alter it, you’re ok. The access board also clarified what an alteration is:

“Alteration,” in turn, is defined as a change to existing ICT that affects interoperability, the user interface, or access to information or data

And they clarified what existing ICT (including content) is:

ICT that has been procured, maintained or used on or before January 18, 2018.

I’m not entirely sure to what extent changes to existing content matter. In other words, if you update just part of a web page that’s compliant under the old rules, but not the new rules, are you obligated to bring the entire page up to the new rules?

The old standards didn’t do a very good job of specifying which types of content were covered; the new standards clarify this:

First, in proposed E205.2, the Board proposed that all public-facing content comply with applicable technical requirements for accessibility. Public-facing content refers to electronic information and data that a Federal agency makes available directly to the general public.

In this case, while most of us aren’t Federal agencies, our school receives Federal money, so this still applies to us. This section goes on:

Second, in proposed E205.3, the Board proposed that non-public-facing electronic content covered by the 508 Standards be limited to the following eight categories of official agency communications: (1) emergency notifications; (2) initial or final decisions adjudicating an administrative claim or proceeding; (3) internal or external program or policy announcements; (4) notices of benefits, program eligibility, employment opportunity, or personnel action; (5) formal acknowledgements of receipt; (6) survey questionnaires; (7) templates and forms; and (8) educational and training materials.

You can ignore the word “proposed” in those two quotes – there’s further clarification that these were the categories adopted, in addition to this one:

…the Board has added a ninth category to final E205.3, requiring that “intranet content designed as a Web page”…

Since the new 508 requirements cover not only web pages, but all ICT (Information and Computing Technology), there was some concern that the WCAG 2.0 standards (which were written primarily for the web), wouldn’t apply to non-web ICT. In the end, it was determined that some of the WCAG 2.0 standards don’t make sense:

Specifically, non-Web documents and non-Web software need not comply with WCAG 2.0 Success Criteria 2.4.1 Bypass Blocks, 2.4.5 Multiple Ways, 3.2.3 Consistent Navigation, and 3.2.4 Consistent Identification.

I’m seeing a lot of WAI-ARIA in modern web apps, but:

WAI-ARIA is a valuable specification, but the technology it addresses is too narrow for our Standards and Guidelines to require its use at this time.

So in other words, you can use WAI-ARIA to comply with a WCAG 2.0 standard, but the use of WAI-ARIA isn’t required.

To sum it up, the new 508 rules (at least, the part that applies to web pages) are just the WCAG 2.0 guidelines, with this change:

For non-Web software, wherever the term “Web page” or “page” appears in WCAG 2.0 Level A and AA Success Criteria and Conformance Requirements, the term “software” shall be substituted for the terms “Web page” and “page”. In addition, in Success Criterion in 1.4.2, the phrase “in software” shall be substituted for the phrase “on a Web page.”

Later this month there’ll be two webinars on the updated rules. I’ll be attending one of them, and will be sure to update this post if my understanding of any of the above was incorrect.

If you’d like a lot of detail on the differences between the old 508 rules and WCAG 2.0, you can follow along with the posts I’ve been writing, complete with examples and how the guidelines apply to Lane.

Understanding WCAG 2.0: 2.4.6 – Heading and Labels

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.

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:

That’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:

That’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:

Learn more about Lane
https://classes.lanecc.edu/course/view.php?id=50473
Sign up for GED tests at http://ged.com

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.

Understanding WCAG 2.0: 2.4.1 – Bypass Blocks

The next standard we’ll explore in our series on understanding WCAG 2.0 is 2.4.1, Bypass Blocks. This standard is required for WCAG level A compliance, which is part of what Section 508 requires. For the first time in this series, we’re exploring a standard that’s substantially equivalent to existing 508 standards (1194.22(o)). Here’s the complete text:

2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages. (Level A)

The existing 508 standard is a little more specific, simply requiring a mechanism to bypass “repetitive navigation links”.

Let’s look at a screenshot of a page on the Lane website, and then break it into some blocks.*

If we overlay this page with some blocks, we get something like this:

If you’re a sighted person, you can quickly skip over the repetitive blocks that appear on every page – you just move your eyes immediately to the start of the body. But if you’re dependent on a screen reader, you’re forced to read the entire page from top to bottom, with one notable exception, like this:

Header
Sidebar
Body (including the in-page block)
Social Bar
Footer Links
Social Links
Contact Info
Megamenu

Notice how the body is the 3^rd thing on there? If you depend on a screen reader, you’ll be forced to hear those first three regions read to you on every single page. In our case, that could be well over a hundred links read to you before you get to the content you need.

And why’s the megamenu block read last, even though it’s at the top of the page? That’s an example of a block where the position in the code doesn’t match the position on the page. The megamenu appears to be at the top of the page, but it’s actually at the bottom of the code, meaning a screanreader reads it last. There’s some complex reasons for that, which would make this post unreasonably long, so we won’t go into them here.

Section 508 helps out by requiring a way to skip repetitive navigation links. Usually this is done by creating a link on the text “skip to content” at the very top of the page, which links to an anchor mid page, right where the body is. To meet this 508 requirement, we put a pair of skip links at the top of all our pages:

One that says “skip to navigation”, which skips directly to the sidebar
One that says “skip to main content”, which skips directly to the top of the body

We also put two more in the footer, which let you skip over parts of the footer:

One at the top of the footer links, which skips to the footer links
One at the top of the social links, which skips to the contact info

There isn’t one to skip the megamenu, since it’s at the bottom of the page, so there’s nothing to skip to – this is a bit of an imperfect solution, but until we can fix it (See this issue to follow along), it’ll work.

Together, these skip links give people these shortcuts to skip parts of the page that appear all over the site:

Though it seems like the skip to navigation link is a bit silly (since it’s skipping nothing in that image), it’s actually important for other pages where we have links in the header (like our landing page).

Under WCAG, instead of just skipping repetitive navigation links, we also need to have a way to skip repetitive page blocks. And that means we need to consider content even at the paragraph level. So while the in-page block in our image isn’t a problem on the contact page, it would become a problem if it was on every page on the site, or even every page on a chunk of the site (like every page in the science department). Then we’d need a skip link.

I’ve seen repetitive text on our site in two places. First is departments that have a common paragraph or sentence they show on every page. For instance, a department might want to show their department vision on every page. That’s actually not ok – instead, they should have their vision just once on their landing page, or link to a page with their vision from their menu.

The second place is people who put lots of links that say “return to top”, which link to the top of the page. Strictly speaking, these aren’t really skip links, but they are completely unnecessary, and a holdover from an earlier time on the web. Screen readers and keyboards both have shortcuts to jump to the top of the page (it’s ctrl-home on a windows computer or cmd-up on a mac) – but most people just scroll or flick the page with their finger on a phone. There’s a place to use an in-page link to the top of the page, but those places are pretty rare.

If you’d like to read more about bypass blocks, you may also be interested in these techniques, which provides examples and more detail. Specifically, it includes discussion about about using aria-roles, which provide an easy way to identify page regions, and make it easier to navigate a page.

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

* The word blocks has a very specific meaning in Drupal, but that’s not how we’re using it here. As far as WCAG is concerned, blocks can refer to Drupal blocks, regions, zones, or even just paragraphs.

Understanding WCAG 2.0: 2.1.2 – No Keyboard Trap

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

2.1.2 No Keyboard Trap: If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away. (Level A)

This one won’t directly impact most of our Drupal users, but it does impact anyone choosing software or building their own.

People with poor vision have difficulty using the mouse, since they can’t necessarily see where it’s pointing. Instead, they’ll often navigate using the keyboard, often by using the tab key to move between elements on the website. Here’s an example:

You can also view this interface directly on CodePen.

CodePen is a great site for doing some quick testing, and I use it all the time when troubleshooting. But it traps your keyboard, failing this accessibility requirement. CodePen is trying to be helpful here – when editing on the page, it’s helpful to be able to indent your code like you would normally in a text editor. But this has the nasty side effect of meaning that once you’re editing on the page, you can’t tab out of that element. For CodePen to be compliant, they’d need to advise us on an alternate method to move between edit boxes using the keyboard.

So if you’re programming something, working with a vendor, or otherwise procuring software for use at Lane, just be aware that you need to make sure there isn’t an element on the page (or within desktop software!) that can trap the keyboard and keep someone from using the page successfully.

If you’d like to read more about keyboard trapping, you may also be interested in this technique, which provides examples and more detail.

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