{"id":1005,"date":"2016-11-29T11:00:27","date_gmt":"2016-11-29T19:00:27","guid":{"rendered":"http:\/\/blogs.lanecc.edu\/webteam\/?p=1005"},"modified":"2016-12-12T13:08:51","modified_gmt":"2016-12-12T21:08:51","slug":"exploring-wcag-2-0-bypass-blocks","status":"publish","type":"post","link":"https:\/\/blogs.lanecc.edu\/webteam\/2016\/11\/29\/exploring-wcag-2-0-bypass-blocks\/","title":{"rendered":"Understanding WCAG 2.0: 2.4.1 – Bypass Blocks"},"content":{"rendered":"

The next standard we’ll explore in our series on understanding WCAG 2.0 is 2.4.1, Bypass Blocks<\/a>. 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)<\/a>). Here’s the complete text:<\/p>\n

2.4.1 Bypass Blocks:<\/strong> A mechanism is available to bypass blocks of content that are repeated on multiple Web pages. (Level A)<\/p><\/blockquote>\n

The existing 508 standard is a little more specific, simply requiring a mechanism to bypass “repetitive navigation links”.<\/p>\n

Let’s look at a screenshot of a page on the Lane website, and then break it into some blocks.*<\/p>\n

\"The<\/a><\/p>\n

If we overlay this page with some blocks, we get something like this:<\/p>\n

\"A<\/a><\/p>\n

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:<\/p>\n

    \n
  1. Header<\/li>\n
  2. Sidebar<\/li>\n
  3. Body (including the in-page block)<\/li>\n
  4. Social Bar<\/li>\n
  5. Footer Links<\/li>\n
  6. Social Links<\/li>\n
  7. Contact Info<\/li>\n
  8. Megamenu<\/li>\n<\/ol>\n

    Notice how the body is the 3rd<\/sup> 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.<\/p>\n

    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.<\/p>\n

    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:<\/p>\n