Website Redesign Check-in

It’s been a while since our last redesign post, but don’t think we haven’t made some progress. We’ve been averaging about one video call per week, and are getting closer and closer to development work.  Some of the things we’ve done:

Developed Batch 1 Designs

Our first batch of pages included the homepage, a career community page, and a program page. Our assumption is that these are some of the first pages most prospective students are going to look for, so we wanted to dive right into them. Our homepage is definitely going to shift direction, and be focused very narrowly on prospective student.

User Tested Batch 1

To be certain that we were on track with design and the information architecture, we did some intensive testing with some real prospective students. Users were asked to perform specific tasks, with people watching exactly what they did and seeing where they struggled.

Finalized Batch 1 Designs

We made some changes to the designs to address issues uncovered in user testing. Some were easy to address, but one has been a particular thorn.

Lane has a lot of different offerings, and people are confused by them. We have degrees, 2 year certificates, 1 year certificates, less than 1 year certificates, career pathways certificates, and non-credit credentials. There’s even more variety within the certificates. Some are financial aid eligible, some are not. Some are stackable with a degree, some are independent. Some are stackable, but you choose between multiple options. Some are technically stackable, but are marketed to a different market segment than the degree. We’ve gone several rounds with trying to balance standardization of design (to reduce confusion) with the flexibility to accommodate all our programs (to stay accurate). We’ve landed on a layout we think will work, and we hope to test it again, but it’ll be difficult to know if it’s worked for all programs until well after launch.

Reviewed Batch 2 Mockups

Our batch 2 pages included some Registration and Tuition related pages. While we’re pretty happy with the design of these pages, they’ve helped highlight a problem for us: our internal organization doesn’t always match how people think about us. For example, consider how students pay for college. We have a lot of departments that deal with money: a Financial Aid office, a scholarship and student employment office, a veterans benefits office, a bursar, and several people that work with sponsored accounts. There’s probably more. There’s really good reason for splitting them apart, and each requires a ton of very specific expertise. But if I have a question, and I’m not sure which of those areas can answer my question, who do I call?

Started Batch 3

Our Batch 3 designs relate to the application sorter and steps to enroll pages. We’ve done quite a few versions of these since our last redesign in 2013. For instance, our sorter page swapped from being person type oriented to goal oriented. Yet, despite all those changes, our sorter continues to be one of the least liked pages on the site. Our new design is going to try to leverage some of that experience, and include information that can help you navigate either way, while simultaneously emphasizing the most commonly used enrollment pathways.

Content planner

Our greatest amount of work has been the content planner. This maps content on our current website to the new website, and identifies where the gaps are. We’ve got a bunch of folders and empty documents set up in google docs right now where we’ve been starting to develop new content and rewrite some old content. There were more than a hundred pages which we need to keep, but which don’t have an obvious home in the new website, and I’ve been slowly making my way through. Some of the rewritten content will be launched before we launch, while most of the new stuff won’t be launched until the whole site is ready.

Meanwhile, as we continue our review of every page on the website, Lori’s been aggressively working on some of the recommended page merging and deletion. Thank you to the dozens of you that have helped us delete old pages!

What’s next?

After we finalize batch 3 this week, we’re hoping to do another round of prospective student testing. Very soon development will start, and while the site is being built, we’ll continue our work on content.

One of our big challenges will be photography. Normally for a website redesign you’d schedule a couple of professional photo sessions on campus, but due to COVID-19, that’s tricky. Before launch, it’s unlikely campus will look quite as busy as it would normally, we won’t see groups of people together, and the people we do see may be wearing masks. I’ve been trying to make it out to campus once in a while to get some photos, but there’s only so many empty shots of campus we can use. If you have any amazing photos – ideally where everyone in the picture has signed a photo release – and you’d be willing to let us use them, send them our way!

One of the campus turkeys in front of the center building
One of the photos from my weekend adventures shooting photos on campus

More accessible phone numbers

In the last post, I learned that not only does phone number format matter from an SEO perspective, but phone numbers can be really annoying to the blind. Depending on the screen reader, a phone number like 541-463-3000 could be read as “five hundred forty-one dash four hundred sixty-three dash three thousand”. That seems terribly annoying.

I started out trying to implement the solution at the end of this blog post, but then my curiosity got the best of me, and I got digging deep into CSS speech modules. It looks like support is limited even though they’re so cool! But the limited support means I’m going to stay away.

Instead, we’re back to the regular expressions replacements, using the Drupal custom filter module. Currently, we look for

/\((\d{3})\) (\d{3}-\d{4})/

And then replace it with

 <a class="telephone_link" href="tel:+1-${1}-${2}">${0}</a>

Over the last few days, we’ve changed that to grab each number individually:

/\(((\d)(\d)(\d))\) ((\d)(\d)(\d)-(\d)(\d)(\d)(\d))/

and replace it with something much, much longer:

<a class="telephone_link" href="tel:+1-${1}-${5}" aria-label="${2} ${3} ${4}. ${6} ${7} ${8}. ${9} ${10} ${11} ${12}">${1}-${5}</a>

It’s a bit of an ugly regular expression, but not only will this hopefully make a better experience for screen reader users, it’ll also introduce a new phone number format as currently recommended by the AP: 541-463-3000.

Progress on the Website Redesign

We’ve been working on the website redesign for a while, but I’m afraid that I’ve totally dropped the ball at posting updates to this blog. Things have been much busier than anticipated. Though I’m sure I’m missing some parts, here’s a quick overview of what’s happened so far.

Completed a brand and identity inventory

In order to help iFactory get to know Lane as a college, we answered a multi-page inventory covering basic items like what our roles are, questions on our market, our programs offerings, and even our guided pathways efforts.

Hosted an on-site visit by the iFactory team

Three iFactory employees came to campus to get to know us even better, eat some delicious Eugene food, and conduct focus groups with students and employees to learn more about what the campus thinks is important in the website. Afterward, they surveyed more than one hundred current students for their thoughts about our website.

Developed four personas to make sure our web content meets everyone’s needs

Well, at least as many needs as we can. Think of personas as pretend people which you can use to evaluate the site. For instance, we have Colleen, a traditional high school student interested in taking some classes at Lane to save money before transferring to a 4-year college. The other three are even more complicated, with tricky backstories. While we’ll never capture every unique situation at Lane, our personas are different enough to make sure we look at every piece of this redesign from at least four very different perspectives.

Evaluated six different mood boards to see which images and designs most feel like Lane

Having collected a lot of information about the college, we were presented with six different mood boards. You can think of these like Pinterest boards for the college, with different collections of pictures and screenshots of other college websites. We provided feedback on each one, and explained why they did or didn’t feel like Lane.

Evaluated three different mockups of potential homepage elements, to get a feel for the design language which will eventually build our site

From the mood boards, some simulated pieces of a  new site were created for us to critique. We provided feedback again on which directions we wanted to pursue.

Provided feedback on two rounds of information architecture for the new site.

While working on some of the design tasks, we were presented with two iterations of an information architecture (IA). The IA is how the site is going to be structured, and starts to provide some structure to the navigation on our site. While we’re pretty confident the IA we’re going to use is roughly correct, it’s still being polished.

Completed a content inventory

We were provided with a spreadsheet of more than ten thousand different URLs that are a part of the Lane domain. While they weren’t all part of the Lane website, they were each linked somehow from the Lane website and a part of our domain. Our job was to determine what to do with each page. Was the content correct? Could it be merged elsewhere? Should it be archived? This task took several weeks of near full time work, and resulted in our cleaning a lot of content. Due to the sheer number of pages to look at, we weren’t able to consult with everyone on each page, but I did talk to dozens of people about their content throughout December and January.

Provided feedback on several rounds of wireframes of possible college pages

One common step in website development is to draw a rough layout of content, without putting any color or pictures in it. The goal is to get you to stop thinking about the appearance of the content and instead think about the layout and the flow of the text. Some wireframing software will even make the lines look like they were drawn with a crayon or thick marker, just so that you know immediately that we’re just roughing in content elements.

Evaluated two different homepage mockups (with help from 44 of you!) to see what direction we want to go with the college homepage.

This is when things got really exciting. Finally, in the last month, we’re starting to see some fairly polished concepts of what the new homepage might look like. We’re still finalizing some of the language, so they’re not quite ready to share, but we’re getting close.

What’s next?

We’re currently working through wireframes and mockups for several other types of pages, and have started preliminary conversations with their developer. Soon, we’re going get an outside perspective on the actual content of our website, and see where we have some gaps. Quite a bit of time this spring is likely to be occupied with content development, since we know we have some content gaps.

I’d also like to share the first change that we’re confident that is going to impact our web editors. On the current site, almost all of your content is in one field called “Body”. This is great, in that it’s very customizable, and terrible, in that it’s very customizable, leading to broken, inconsistent pages. Best practices developed a few years after our previous launch suggest  providing reusable components that you can plug into any part of your site: a slideshow here, a callout quote there, some text over there. They also suggest making them remixable, so you can lay out your page however you’d like, using a common language of elements, letting your page be instantly familiar to everyone as a Lane page, but also customized to your content.

We’re going to be adopting that approach as a part of this website launch, which I hope will help meet some of the website customization needs I haven’t been able to meet over the last few years!

More details soon, honest!

Evaluating Goal progress, 17-18

All year we’ve been tracking progress on our web team goals. But now the year is over, and it’s time to reflect. We definitely made a lot of progress on some of our goals, but on others there’s only bad news.

1. Reduce the total number of pages on the Lane website by 5% (from 5550 to 5273)

We exceeded this goal, reducing the total number of pages by 18.3%, rather than just 5%. But it turns out this was not a well written goal. Of the 1,018 of pages we eliminated, 558 of them were Lane in the News items, which aren’t really pages at all.

This goal had a problem with language versus measurement. Drupal stores content internally as “nodes”. This is fairly easy to count – select count(*) from node. But there’s a number of types of content on the website that aren’t really pages but are nodes. Lane in the News items are one type, but we also have slideshow slides, FAQ questions, and landing page announcements. So while those content types count for the purposes of our metric, they probably shouldn’t.

Fortunately, we still deleted 460 actual pages, so we handily met this goal. But if we set a goal like this again, we’ll probably exclude certain content types (not only the ones previously mentioned, but also news releases and board policies).

2. Reduce the number of pages with more than 15,000 characters by 10% (from 249 to 224)

While we certainly met this goal, this count has increased yet again, from 144 pages last check-in to 145. These pages remain mostly meeting minutes and policy documents. If we do a goal like this again, we should probably limit what content types we look at.

It’d be really nice if there were an easy way to count words, rather than characters, but that ends up being a very difficult problem, especially when our content includes HTML mixed in.

3. Reduce the average character count of our pages by 10% (from 4650 to 4185)

For reasons similar to goal #2, we should probably have limited what content types we looked at. We wound up at 4,194 characters, which is close to our goal. This is likely not a goal we’ll continue though, as longer form content isn’t necessarily a terrible idea.

4. Improve the average age of our pages (the average late updated date) by 4 months (from 16 months to 12 months)

We’ve stayed steady on this goal since last post, at 17 months old. This remains one of our most difficult tasks. Despite the web team making more than 3,000 page revisions in the last year, more than 20% of the pages on the website haven’t been edited in more than 3 years – and many of the revisions we made were just link changes or typos. We’re often not qualified to do content changes. Please give us a hand!

Traffic Goals

We also had two traffic goals:

  1. Increase session counts for during the period 6/14/17-6/14/18 compared to the previous year by 5%, from 3,228,904 to 3,390,349
  2. Decrease the bounce rate for during the period 6/14/17-6/14/18 compared to the previous year by 5%, from 37.05% to 35.19%

Unfortunately, we met neither of these goals. We fell the furthest behind on pageviews, where we fell 14.24%. We did improve our bounce rate by 1.11%, but that’s a long way from our 5% goal. We did have a couple of wins, which seem to indicate a more engaged audience. Average session duration is longer, people are viewing more pages per session, more sessions are from new visitors, and organic search traffic is up.

In retrospect, while these were a good first attempt at goals, future goals should be more carefully targeted to what we’re trying to accomplish on the web at Lane. For instance, we could look at the percentages of traffic that come via organic search or referral, or we could look at tracking the percentage of people who request information about the college.

Web Team goals for 17-18

It’s the end of the academic year, which means it’s time to start thinking about goals for next year. Our first set of goals will be similar to our goals from last year:

  1. Reduce the total number of pages on the Lane website by 5% (from 5550 to 5273)
  2. Reduce the number of pages with more than 15,000 characters by 10% (from 249 to 224)
  3. Reduce the average character count of our pages by 10% (from 4650 to 4185)
  4. Improve the average age of our pages (the average late updated date) by 4 months (from 16 months to 12 months)

We’re also going to add two goals relate to page use:

  1. Increase session counts for during the period 6/14/17-6/14/18 compared to the previous year by 5%, from 3,228,904 to 3,390,349
  2. Decrease the bounce rate for during the period 6/14/17-6/14/18 compared to the previous year by 5%, from 37.05% to 35.19%

We’ve never had page use goals like that, so this will be interesting for us as we really dig into how to increase engagement and findability of our pages.

If you’d like to help us meet our goals, just edit your pages! We’ve made a lot of progress in making our pages more recent – many pages used to be over two years old! We’re happy to help. Just email Lori and she’ll get you pointed in the right direction.

Using all Capital Letters

An instructor asked me the other day, “How does a screen reader read text in ALL CAPITAL LETTERS?”

I didn’t know, and through it was a great question, and had to figure it out. Let’s start with some sample text:

It’s VERY important you remember these:

  • USPS
  • NASA
  • DVD

There’s four words in all caps there. Let’s look at each one, from the bottom to the top:

DVD is an initialism, meaning you read each letter in it, like CPU or FBI. NASA is an acronym, meaning you read it as a word, even though each letter stands for a word. USPS is another initialism. But VERY is just a word, with all capital letters being used for emphasis.

Of course, it’s wrong to use capital letters in this way – you should instead be using an em or strong tag (though which one is complex, and I didn’t find the examples in the specification very helpful). But the instructor’s question wasn’t about what should happen, it was about what does happen. How can a screen reader know which of those words it should treat as words or acronyms (which are like words, in terms of pronunciation), and which it should treat as initialism (and read letters instead of the word)?

I ran each of the examples through the say program on my Mac, and here’s what I got (sentence case was pronounced like lowercase):

Word Uppercase Lowercase
Very word word
USPS letters word
NASA word word
DVD letters letters

There’s some interesting logic there. I think this table shows my Mac will always read dictionary words as words (like “very”). And I think it shows that my Mac also has a list of known acronyms and initialisms, so it knows how to read those. For words that aren’t in either list, but also aren’t in the dictionary (like USPS), it reads all capital letters as initialisms, but lowercase as a word (a reasonable assumption, since most of the time it encounters words that aren’t in the dictionary, it’s probably due to the lang attribute not being set correctly.

Of course, this is just say on my Mac, which isn’t even a screen reader. WebAIM has some general rules for how screen readers read things, but it isn’t really predictable how a screen reader is going to pronounce words in all capitals. Pronouncing typographic symbols is hit or miss as well — some, like @ and % are read correctly. But most others (like the parenthesis, or the mdash in the previous sentence) aren’t read universally. Rare punctuation, like the interrobang (‽) may not be read at all.

I was hoping that abbr would influence how screen readers pronounce words, but that doesn’t appear to be the case (and, if you’ve been around HTML for a while, remember you’re not supposed to use acronym at all — though it probably wouldn’t do anything here anyway).

What does this mean for you at Lane?

Use the abbr tag to specify acronyms and initialisms if possible. Even though screen readers won’t necessarily change how they handle pronunciation, abbr with a title attribute makes it easier for anyone to understand meaning. Try hovering over this: NASA.

If you want to use capital letters for emphasis: don’t. Instead, use either an em or a strong tag, depending on if you’re trying to emphasize something or make it note that it’s more important than surrounding text. And, of course, never use strong in place of a header.

If you want to use capital letter for aesthetic reasons, then you should use a bit of CSS to make it happen:

.all-caps {
  text-transform: uppercase;

Screen readers ignore CSS, so this use is entirely for presentation. Just make sure you don’t confuse presentation with meaning.

I ran a quick search on our website for pages that have a lot of capital letters all in a row:

SELECT entity_id
FROM   field_data_body
WHERE  body_value REGEXP BINARY '[A-Z ]{10}';

There were 748 results. Editing 748 pages obviously won’t happen overnight, and on each one we’ll need to determine if we should instead be using a header, a strong, an em, or just normal text. For now, I’ve queued a task for us to tackle in the future, but if you’re editing your page and notice some misuse of capital letters, we’d be forever appreciative if you’d fix it.

Closing out the year for the Web Team

If you’ll recall from our original goals post, or the update that followed, we had a few goals on the web team the last two months of the year:

  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.

I’m very sorry to report that while we made a lot of progress, we were unable to meet any of our four goals. Here’s the graphs:

Node Count Graph, showing progress from 5768 to 5557We were able to make some progress eliminating nodes even in December, but things slowed down. Part of that is because with so many people on vacation around the holidays, it’s difficult to get permission to delete a page. We’d been shooting for a 5% reduction, but we were only able to get 3.5%.

Graph of nodes wiht more than 20k characters, showing progress from193 to 172As mentioned in the previous goals post, it turns out that many of these really long nodes are pages that are really hard to reduce, like board meeting minutes or transcripts of in-service addresses. I reviewed almost every page and removed a lot of really bad markup: things that we should have removed when initially porting pages to Drupal, boldfaced text that should have been headers, HR tags used improperly, and so very, very many &nbsp; characters. We’ll tackle some of those in a future post.

We’d been looking to make a 20% improvement, but we only managed 10.8%.

Graph of average length of our pages, showing no progress in the last month.Average length was really depressing for me, especially as I’d update statistics after working on these goals for a few hours. I might spend two hours meticulously working my way through the list of really long nodes, since they’d help us meet this goal the most. And I might see a visible improvement on the body length graph. But then I’d work on eliminating some nodes, and inevitably those nodes would be really short, meaning our average body length would go right back up.

Still, we made some gains early on, and the site as a whole is improved. We’d been shooting for a 10.5% reduction, but we only made a depressing 2% improvement – about 100 characters.

Average Age, showing steady progress along our trend lineWe probably made the most progress on this goal, but our failure to make progress early in November really hurt us. Over the two months we tried to meet our goals, pages got about four months newer.

We tried to meet this goal primarily by updating our oldest pages.

Count of pages at least four years old, showing progress from 732 to 513We substantially reduced our really old pages. And while it’s great we made that progress, since we hate ROT, it just wasn’t enough for us to meet our goal.

We still have lots of tasks queued up in Basecamp for us to do related to content, that we just didn’t have time to get to as part of this challenge including reworking some tables that are used improperly, removing even more HR’s, fixing some pages that are using redundant text blocks, eliminating duplicated pages, adding headers, removing improper use of the • character (people use it for bullets, but they should be using the bullet tool), and figuring out what to do with pages where people wrote “check back for content soon” several years ago. So we expect to make more progress in the coming months.

A special things to everyone who helped out with our goals. Here are the ten champions of the last two months, who made the most edits on the site, helping us toward our goals:

Name Number of Revisions
Lori Brenden 545
Kyle Schmidt 179
Amy G 132
Emily M 91
Tammy S 58
Elizabeth P 41
Melanie B 39
Joan A 31
Wendy S 30
Penny M 27

Happy New Year everyone!

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!


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

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

A labeled version of the same page at

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.