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.*

The Lane contact page, at lanecc.edu/contact

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

A labeled version of the same page at lanecc.edu/contact

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:

  1. Header
  2. Sidebar
  3. Body (including the in-page block)
  4. Social Bar
  5. Footer Links
  6. Social Links
  7. Contact Info
  8. Megamenu

Notice how the body is the 3rd 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:

Same contact page, with arrows

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:

Screenshot of the Codepen edit interface

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.

Understanding WCAG 2.0: 1.4.4 – Resize Text

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

1.4.4 Resize text: Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality. (Level AA)

This one might seem super straight forward, but there’s a bit of subtlety to it.

It used to be that browsers didn’t zoom, they’d actually just increase the font size. If you pressed Control + you’d increase the font size (Command + on a Mac), and if you pressed Control – you’d decrease the font size (Command – on a Mac). But this created all sorts of problems. If text was inside of a fixed width container, like a div or a table, and the font size increased, the text would suddenly outgrow the container. CSS developed something of a reputation:

Coffee mug, with the text "CSS is Awesome" overflowing a containing boxBrowser makers changed directions, and instead of the zoom shortcuts changing the font size, they’d instead zoom the entire page. As the apparent font size increased, the containing element would increase size at the same time.

But you can still force your browser to zoom only the text. In Firefox, under the view menu, there’s an option to tell it to zoom text only. Here’s what our contact page looks like normally:

The Lane contact page, at lanecc.edu/contactHere’s what it looks like if I tell Firefox to only zoom the the text, and press cmd + four times (which confusingly zooms the text 300%):

The Lane contact page, zoomed 300%. Description follows in text.See where the issues crop up? Across the top, in our mega menu, the text gets to be bigger than the container. And again, in the twitter and events bar at the bottom, there’s a weird line across the middle (because we should have used a tiling image).

Despite those issues, our pages pass this standard easily. You’re allowed to use either text zoom or page zoom, and using page zoom our page looks great.

As always, a couple of tricky things:

First, if we had to support an old browser that didn’t support zooming (I’m looking at you, IE6), then we’d need to provide an on page method to change text size, usually using a big of Javascript. But here at Lane, we don’t support anything before IE11, so we usually don’t need to worry about this.

Second, mobile is tricky. Our website includes this meta viewport tag:

<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, minimum-scale=1, user-scalable=no" />

But that can actually be problematic, as it prevents pinch zooming. But it turns out that some browsers (like Safari) don’t respect that meta tag. And other browsers support a “reader view”, which strips out a lot of styling to make the page easier to read on mobile. So while the WCAG recommends not including that specific meta tag, and we’ll likely remove it on the next iteration the Lane website, we’re probably fine for now because of the ready availability of workarounds.

Third, text on images should be avoided whenever possible. While page zoom will increase the size of an image appropriately, when you zoom an image it gets pixelated. Pretty much exactly unlike on TV:

This, along with the need to include alt text, is one of the reasons we encourage you to not use text on images on your pages.*

There are a lot of technologies where text zooming is more of an issue than it is on the web, like Flash or Silverlight, but since they don’t typically apply to the Lane website, we’re going to skip over them here. But if you’d like to read more about text resizing, you may also be interested in some of the techniques, which provides examples and more detail.

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

* For the super nerdy, SVGs are actually the exception to this rule, since as web ready vector images, they’ll zoom with the browser. But there’s no real convention for placing alt text on an SVG, so I’d encourage you not to use these yet either.

Understanding WCAG 2.0: 1.4.3 – Contrast

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

1.4.3 Contrast (Minimum): The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following: (Level AA)

  • Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;
  • Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
  • Logotypes: Text that is part of a logo or brand name has no minimum contrast requirement.

Low contrast ratios have been something of an unfortunate design trend recently. Before we get into what contrast ratios should be, let’s look at a couple of examples:

Hello!

Black text on a white background. Simple. Classic. Easy to read. Here’s another example:

Hello!

Yellow on white. It’s pretty obvious this is harder to read. But we can actually quantify just how much harder it is to read by calculating a contrast ratio. Getting the actual contrast ratio is kind of tricky, because color on screens is actually defined as a mix of three colors: red, green, and blue. The W3C provides a formula (at the bottom of this page), which calculates the luminance (a measure of the intensity of light) of the foreground color and divides it by the luminance of the background color to get a contrast ratio. But I found it easier to just use a calculator.

This blog doesn’t use a true black for the text, it uses a black with a little bit of white in it (because, as a rule of thumb, never use a true black on the web). So while true black on white has a ratio of 21, the ratio in our first example is 11.9, which easily meets our requirements. But our second example, which is yellow on white, has a ratio of 1, which is as bad as it gets.

To achieve AA compliance, we need a ratio of at least 4.5. But I find even 4.5 to be difficult to read, especially in a really bright room:

This line has a contrast ratio of 21:1

This line has a contrast ratio of 11:1

This line has a contrast ratio of 7:1

This line has a contrast ratio of 4.5:1

This line has a contrast ratio of 3:1

This line has a contrast ratio of 2:1

So we may want to consider always shooting for AAA compliance, which requires at least a 7. After a while, you kind of get a feel for contrast with black, white, and grey. But color is a lot harder. Let’s analyze a page on the website:

A screenshot of the top of the Lane community website.

There’s a lot of different color combinations there. When we designed the website, we tried to make sure we’d have sufficient contrast to make it readable by everyone. But we didn’t have any guidelines in mind, and just tried our best. It turns out it’s harder to judge contrast in colors.

Let’s start up at the top, on the four tabs for navigation to our different audience landing pages. The white on blue has a ratio of 7.4. But the yellow on blue for “The Community” has a ratio of just 3.8 – something that we’ll need to fix.

The banner had two surprises for me. I thought the white on blue would have fairly high contrast, but it was actually just a 3. While that’s on the edge, that’s actually sufficient here, because the text is considered large scale (at least 18pt, or a bold 14pt). I felt like the black text on the blue banner would have a fairly low ratio, but it’s a 7. So our banner checks out.

The announcements box has some troubles. The orange “Announcements” text has a ratio of just 2.3, partly because the background of that box is a little transparent, and partly because that orange is kind of bright. On the other hand, the linked announcement links are sufficiently contrasting, with a ratio of 5.5.

While I can fix the contrast on the website theme, this standard is part of the reason we encourage you not to change colors on your pages. In addition to not conveying information strictly through color, and keeping with the branding standards of the college, you need to make sure to keep sufficient contrast.

If you’d like to read more about color contrast, you may also be interested in these techniques, which provide examples and more detail.

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

Understanding WCAG 2.0: 1.4.2 – Audio Control

The third standard we’ll explore in our series on understanding WCAG 2.0 is 1.4.2, Audio Control. This standard is required for WCAG level A compliance, which is part of the level AA compliance that Section 508 requires. Here’s the complete text:

1.4.2 Audio Control: If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level. (Level A)

I wasn’t able to think of a place this applies on a Lane website, but I wanted to be sure to mention it. The only place we usually have audio play is on pages with video, and the embed options we have available on Lane pages make it difficult, if not impossible, for audio to play automatically. If you’re building pages for your class, or are doing some web development as part of IT, please be alert to this guideline.

Of course, I’m also of the personal opinion that we don’t want your site reminding everyone of mid 2000’s mySpace profile pages. You know the ones. You’d land on it to find a crazy, mismatched background and Nickelback playing with no way to make it stop. You couldn’t close the browser fast enough. Let’s not bring those days back.

If you’d like to read more about audio control, you may also be interested in this list of 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: 1.3.3 – Sensory Characteristics

The second standard we’ll explore in our series on understanding WCAG 2.0 is 1.3.3, Sensory Characteristics. This standard is required for WCAG level A compliance, which is part of the level AA compliance that Section 508 requires. Here’s the complete text:

1.3.3 Sensory Characteristics: Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation, or sound. (Level A)

As a mostly non-technical requirement, this one is actually pretty easy to understand, and it isn’t too different from a standard that’s already in section 508 (§1194.22(c)), which says you’re not allowed to convey information strictly through color. Standard 1.3.3 simply expands that requirement to cover visual and auditory impairments.

This doesn’t mean that you can’t convey information using some sort of sensory characteristic. You often should. If you have a button on a page to proceed to the next page, I’d encourage you make it look like a green arrow, and tell people to look for a green arrow right in the instructions. But you then also have to very carefully label the arrow as linking to the next page – you can’t rely on someone seeing green or being able to identify the arrow shape.

You also need to be careful referring to an element on a page by position. You can’t have instructions that say “Click on the link in the top right corner of the page”. But you can have instructions that say “Click on the link titled ‘College Catalog’ in the top right corner of the page”. Again, you need to provide an alternate method of locating that link. In this case, we’re using the link text.

The exception to this is above and below. In English, it’s generally acceptable to refer to content preceding the current reading position as being “above”, and content that follows to be “below”. Since your page should have sequence, you can usually refer to content above and below.

Here’s a final example:

Time 8 9 10 11 12 1 2 3 4
Underwater Basketweaving
Quidditch

Above, you’ll see a table with my schedule for this academic year. I’m not taking a particularly demanding schedule, but this way of presenting my schedule only conveys when classes are through color. So this doesn’t even pass existing 508 rules.

Time 8 9 10 11 12 1 2 3 4
Underwater Basketweaving
Quidditch

This one isn’t ok either. We’ve just traded colors for shapes. But you can probably see where this is going:

Time 8 9 10 11 12 1 2 3 4
Underwater Basketweaving
Quidditch

This one is probably ok, according to a strict reading of the guideline. But we could improve it further, by providing span‘s that are visible only to screen readers, which describe when the classes take place. We can’t be sure those symbols are readable by a screen reader either.

If you’d like to read more about sensory characteristics, you may also be interested in Guideline 96: Providing textual identification of items that otherwise rely only on sensory information to be understood, which provides an example and a bit more detail.

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

Understanding WCAG 2.0: 1.3.2 – Meaningful Sequence

The first standard that we’ll explore in our series on understanding WCAG 2.0 is 1.3.2, Meaningful Sequence. This standard is required for WCAG level A compliance, which is part of the level AA compliance that Section 508 requires. Here’s the complete text:

1.3.2 Meaningful Sequence: When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined. (Level A)

In other words, if the order of the content on the page is important, you need to tell a screen reader the order somehow.

There’s a lot of ways to give content order. This blog post has order, for example. So far, we have a paragraph (a p element), a blockquote, then two more paragraphs. WordPress puts all of those a division (a div element). So the structure of this blog post is:

  1. div
    1. p
    2. blockquote
    3. p
    4. p

This blog post depends on sequence for the content to make sense – after all, if the paragraphs got switched, it wouldn’t make sense.

Screen readers use the order of tags on a page to automatically determine sequence. So if your page is mostly text and pictures, you probably already meet this requirement.

The problem occurs when there’s content which is visually in sequence, but whose actual representation isn’t in sequence. Imagine this scenario. You want to put two pictures on your page next to each other, with a caption on each one. You’re having trouble making it look right, so you decide to use a table. It’d look something like this:

A picture of a cat in a monitor A picture of a cat chewing on a monitor

Poof! It works, right? But tables can be read left to right or top to bottom, and the screen reader has no way to know which it should do. So, like most of us, it defaults to left to right, meaning it reads this:

  1. table
    1. A picture of a cat in a monitor
    2. A picture of a cat chewing on a monitor

See the problem now?

Ah, but wait, you say, what about alt tags? Don’t they label the picture?

Well, they would. But this is a circumstance where you want to have an explicitly empty alt tag – alt="". Because these pictures are captioned, an alt tag is redundant. If they had an alt tag we’d be reading the caption to them twice: once in the tag, and once in the caption. And also, even if we did want an alt tag here, that wouldn’t solve the problem.

Blind people aren’t the only people to use screen readers. Many people simply have really, really poor vision, and may be using a screen reader to help read to them. And while their vision is poor, it doesn’t mean they couldn’t still enjoy these cat pictures. The table above doesn’t let someone with poor vision associate a caption with the appropriate picture.

The solution is to use div tags, and set them to the left and the right side of the page. One easy way is to set your div tags to 50% of the width of the page, then set one to float to the left, and the other to float to the right (for the technically minded, you’d may also need to clear afterward). On our Drupal pages, you can use the classes “half left” and “half right” on div tags. Because we’re then grouping our picture and our caption inside of a div on each side, everything will be read in order.

Tables aren’t the only concern with sequence. Have a look at this list:

  • Head east on H St NWt
  • Turn right onto 13th St NW
  • Turn left onto Pennsylvania Ave NW
  • At the traffic circle, take the 1st exit onto 1st St NW

We recognize those as directions, right? But the bullet points are actually a problem. Those bullet points are considered an unordered list (A UL tag). Directions have a sequence. If we use bullet points, we haven’t told the screen reader what order to read the bullets in (it’ll probably know, but why risk it?). Instead, we need to use an ordered list (an OL tag):

  1. Head east on H St NWt
  2. Turn right onto 13th St NW
  3. Turn left onto Pennsylvania Ave NW
  4. At the traffic circle, take the 1st exit onto 1st St NW

You should also pay attention to div tags that are floated from the text. If you have an introductory paragraph that explains some topic, then a sidebar floating that provides clarifying points, you’ll want to make sure the clarifying sidebar is inserted into the HTML after the introductory paragraph, since understanding it depends on first reading the introduction.

If you’d like to read more about meaningful sequence, you may also be interested in Guideline 57, Ordering the Content in a Meaningful Sequence, which provides an example and a bit more detail. For complex layouts, you may also want to look at aria-flowto, which provides a kind of goto statement for text, to tell the screen reader when to jump over text that is out of sequence for presentation.

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