Click to Expand

A few days ago, an astute employee over in Enrollment Services pointed out that our steps to enroll pages weren’t completely accessible to the blind. This is an important problem, and a surprisingly tricky one.

The current legal requirements for web accessibility (including §1194.22, which we’re most interested in) are referred to as Section 508. These standards provide some useful guidance on how to help folks with an impairment of some kind. For instance, they describe how images should have an alt text field, except for when that image doesn’t support understanding of the content (e.g. a background or filler image).

On the other hand, these standards are now old enough to vote, meaning they’re older than Facebook, Twitter, selfie sticks, Google Chrome, iPhones, the Columbus Blue Jackets, and Windows XP. Needless to say, they’re showing their age.

There’s no way to make click to expand text accessible under current 508 guidelines. Our best option would be to duplicate the page and provide a text only version. Unfortunately, that could lead to a screenreader having to read a lot of unnecessary text.

The solution relies in the proposed new standards. These are still in progress, but the web community is confident they’re going to heavily include something called WAI-ARIA. WAI-ARIA provides a way to mark up your pages with extra attributes that screen readers know how to recognize, so the blind can better use interactive pages.

Returning to our original problem, starting this evening we’re now using the hide-show accessible plugin on those pages. This plugin lets you write some fairly simple markup in your page which will then get converted to a click to expand box like on the steps to enroll.

To use, you’ll first want to click the blue link below the edit box in Drupal that says “disable rich text”. Then, if you want a simple button with some text below it, you’ll want to paste this in:

 <p class="js-expandmore">Click on me</p>
 <div class="js-to_expand">
     here is the hidden content!

Then replace “Click on me” and “to show me!” with whatever works for your page. You’ll get something like this:

plus sign with some latin text that'd normally be clickable

And when you click to expand, you’ll see this:

minus sign, with the same text as before, but now with more text shown below it

If you’d like a little bit of color, you can also use an h3 element, which would place that text in an orange box:

    <h2 class="js-expandmore">Lorem dolor si amet</h2>
    <div class="js-to_expand">
       here is the hidden content

Exactly the same as before, but now it’ll look like this:

same plus with text, but now with an orange background

This is actually the more correct use – you nearly always want to use an h element of some kind when it describes the text after it.

For really advanced use, you can also add a full class to make the button full width. Or you can add the blue class to make the orange background blue instead. Or both!

    <h3 class="js-expandmore blue full">Lorem dolor si amet</h2>
    <div class="js-to_expand">
       here is the hidden content

would look like this:

blue background, full width, with same plus and text

This is definitely getting into advanced content editing in Drupal, so if you’re stuck don’t hesitate to contact us at

Remember, we should always try to use the right tool. For instance, these kinds of show and hide buttons might seem like they’d be perfect for an FAQ. But we already have a different setup for FAQ questions, that takes care of alphabetizing and tracking changes to each question. And remember that many of the visitors to your page won’t bother clicking the button at all. Always spend time simplifying your content to make sure the important message is apparent even without clicking to show your other text.

Common Pitfalls – Alt Text

Recently we updated our link checking script to hunt for some common mistakes in image alt text.

As you may recall from your initial Drupal training, alt text is very important for accessibility, as it’s the text that’s read to the visually impaired to describe what’s in the image. Close your eyes for a second and pretend whatever you put in the alt text is being read to you. Is what’s being read so short that it’s meaningless? So long that you get bored just listening to it? Does it repeat something that you already say in the text, making it redundant?

But we’re interested in even worse problems today. Sometimes people put in alt text that doesn’t event attempt to describe the image. For example, some people use the file name as the alt text. Like this:

<img src="/dog.png" alt="dog.png">

If you were using a screen reader, your software would get to that image and read you “dog dot p n g”, which is summarily unhelpful. Reading the file name won’t help anyone better understand what’s in that image. Also unhelpful is this:

<img src="/dog.png" alt="goldenRetrieverPuppy">

which we haven’t seen recently, but has come up in the past. That’d just cause the program to attempt to read goldenRetrieverPuppy as a word, possibly completely unintelligibly.

And then some people are just lazy:

<img src="/dog.png" alt="picture">

Completely unhelpful.

Remember, for us (as it should be for everyone) being accessible isn’t optional. Starting today, we’ll be scanning for these errors automatically, and emailing content editors that need to touch up their alt tags a bit.


More New Features

Two more new features to report.

First, you can now add a caption to your images. When you insert an image, as always, you’re prompted with a dialog where you can enter a title, and where you can enter a description. At the end of last week, we started automatically converting whatever you put in as the title of your image to be a caption, appearing in boldface just below the image.

It’s important that these two fields – title and description – are used correctly. When implementing this feature, we found close to two hundred images where they were exactly the same text. Imagine a screen reader comes across this picture:

A cat chewing on a monitor
A cat chewing on a monitor


Since both the alt text and the caption are the same, and it wants to make sure to read all the text to you, it’ll actually read the exact same thing to you twice! And don’t get me started with the people that used the file name (“cat123.jpg”) as the alt text, or even worse, the word “picture” as the alt text.

So what to do?

In a conversational blog post like this one, it’d be perfectly fair to make the alt text descriptive (“A cat, chewing on a monitor”), and to use an amusing title/caption (“Delicious!”). But if you have a more serious picture, say a picture of some people, you’re actually allowed to explicitly set the alt text to empty, since the description now lives on as a caption. That way the screen reader knows to skip the alt text and just read the text  (caption) surrounding the picture. So if you have a picture of two people, Alice and Bob, you could make the alt text be “” (that’s literally what’s called an ’empty string’, meaning there’s nothing inside the quotes, but the quotes are present), and the title be “Pictured, left to right, Alice and Bob.”.

The second feature we’ve implemented is FAQ questions. If your department has, or would like a FAQ page, contact us for a quick crash course in how to use the FAQ module.

DrupalCon Portland, and the evils of and

Last week, two Lane Web Team members went up to DrupalCon Portland.

The Drupal "Drop" under a pendulum at the Portland Convention Center
Did you know Oregon has the world’s largest Foucault Pendulum?

In addition to opportunities to network with other institutions running Drupal around the state and world, there were a ton of awesome speakers and “Bids of Feather” sessions, where groups of like minded people got together to talk about issues relevant to them. Take a look:

A whiteboard, showing a grid of different sessions at various times, including such sessions as "Pantheon and HigherEd" and "Higher Ed Content Strategies"
This seems like a weird thing to take a picture of, but the BOF listing couldn’t be found on the web anywhere – wifi at conferences is notoriously poor, so it wouldn’t have done us much good.

The second day’s keynote, by Karen McGrane, was about user experience and design, and provided some excellent insights for us (watch it here!). The one that will impact you most is our removal of the <i> (italics) and <b> (boldface) elements from the list of allowable elements on Drupal content pages.

As per why, it has to do with two things: Future Proofing, and Accessibility. Back in the day, when content was designed for paper, boldface and italics made a lot of sense. So the <b> and <i> HTML elements were used to replicate this on the web. But, not too long later, people realized that these elements didn’t actually convey any semantic information – they were purely visual. So they added the <strong> and <em> (emphasis) elements.

Now, here’s the thing. Strong text, and emphasized text look exactly the same as boldfaced and italicized text – this sentence actually uses <strong> and <em> tags. So the average web user won’t notice any difference. But what happens if you’re using some futuristic wearable computing device that reads web pages to you? With <strong>, your device would know to read a certain word or sentence strongly, and to emphasize text in <em> tags. But if they were <b> or <i> tags, you wouldn’t have even known they were there . Turns out this is the same way screen readers work.

As of this morning, we’re filtering out <i> tags and <b> tags. There’s a 99% chance this doesn’t impact you at all – using the buttons in the WYSIWYG on Drupal automatically uses <em> and <strong> instead. But if you’ve been doing something fancy after disabling the rich text editor, you might need to change your page some.


Color Blindness Testing

As we prepared to launch the new design, one of the things we were sure to focus on was accessibility. While that’s been covered in previous posts, there’s another area of web accessibility that’s often forgotten that I’d like to highlight here: Color Blindness.

Color Blindness is a complex condition, manifesting one at least ten different ways, and  affecting some ten million Americans. Although most color blind individuals are actually color weak – meaning some vision of a color, but trouble distinguishing it from nearby colors – we chose to do our tests on the more severe form, rationalizing that if we can design a website that works for true color blindness, it will also work for weakness.

Here’s some simulations of different areas of our site for different types of color blindness:


Future Students:

Current Students:


Content Page:

The primary thing to look for in those images is contrast. Do the color choices of our design ever create a situation where a color blind person wouldn’t be able to find some of the text? For example, if the design had adjacent green and orange elements, a person with Protanopia would probably be unable to tell them apart. From what I can see, we’re in pretty good shape. And just to make sure, I double checked with a colorblind coworker.

Another thing to think about with Color Blindness is the use of color to convey important information. For example, say you receive a message on a website, “The email was not sent”. If that message is in red, most of us would assume that it was a bad thing – the email we were trying to send didn’t make it. But if that message was in green, then most of us would assume it was a good thing – the message we desperately didn’t want to send was canceled. For this reason, Drupal includes a checkbox next to “good” messages, and an X next to “bad” messages, so that the intent of the message is always clear, even if the color isn’t apparent.

Although we tried our best to test a few regular content pages (like, or, with over 4000 pages, it isn’t possible for me to hand check every one. For that reason, if you’re a content editor, please try to keep contrast and intent in mind when you’re working on your pages.

I created those images using GIMP, a free software program, using the Color Deficiency Filter (under Views). If you’d like to try seeing your page, there’s a number of color blindness simulators online. I’d recommend

Website Accessibility Improvements

As an educational institution (and as responsible web developers!), we’re very concerned with the accessibility of our website. Although our primary concern is following the Section 508 guidelines, there’s a number of other best practices we’re trying to follow.

Before I get going, I’d like to note that this post only applies to our Drupal redesign, and to the pages on (though we’ll soon be moving www2 to www).

Section 508

508 contains sixteen standards that directly address web content. I think it’s worth looking at each of these standards in detail.

(a) A text equivalent for every non-text element shall be provided (e.g., via “alt”, “longdesc”, or in element content).

Through a combination of limiting editing functionality and filtering tags when pages are saved, we’re only allowing four non-text elements on pages: images, YouTube videos, Flickr slideshows, and Google Maps. This is a significant improvement over our old site, where we had no method to limit tags, allowing any number of non-text elements to be introduced.

When a user editing a page in Drupal inserts an image, they are prompted to add an Alt Tag, with a note about its importance in improving usability. Just to make sure no images escape our attention, we run a weekly report that checks all of the images on the site for alt tags, and alerts us if improvements are needed. Additionally, the importance of Alt tags and accessibility in general, is discussed with Drupal users during our normal Drupal training.

Unfortunately, there are some accessibility concerns with Flickr. For this reason, Flickr is not intended to be our final image slideshow solution, and is only a temporary measure while we explore alternate solutions. We’ll be rolling out an alternate slideshow solution, with a goal to be totally away from Flickr by the time we upgrade to Drupal 8. In the mean time, users are responsible for providing relevant accessibility information for their own Flickr accounts.

For more information on the accessibility of YouTube videos, see guideline b, below. More information on Google Maps accessibility can be found at

(b) Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation.

Unfortunately, there is no automated method for us to ensure compliance with this standard. To improve the likelihood of compliance, we have removed the ability to embed videos on pages from sites other than YouTube, which has the best closed captioning support, sometimes providing them automatically. During our media training, we make a special note of pointing Drupal users toward captioning resources (which can be found at

(c) Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup.

As part of standardizing the appearance of our website, we’ve tried to reduce the role of color in providing information. Generally, users are unable to modify the colors of their pages, and where color is used to convey information, such as tables and alert notices, markup is provided to convey its purpose (through thead tags and alert classes, respectively).

(d) Documents shall be organized so they are readable without requiring an associated style sheet.

When developing the new Drupal site, one of our goals was to make each page’s content work independently of style, not only for accessibility, but also to facilitate easily modifying page style in the future. We’ve tried our best to ensure that pages use ordered, semantic HTML, to provide hierarchy that’s easy for screen readers to navigate, and we’ve added helpful links to allow screen readers to jump over or directly to the page navigation.

(e) Redundant text links shall be provided for each active region of a server-side image map.

We do not use image maps on our site.

(f) Client-side image maps shall be provided instead of server-side image maps except where the regions cannot be defined with an available geometric shape.

We do not use image maps on our site.

(g) Row and column headers shall be identified for data tables.

When using the table wizard in our Drupal page editor (TinyMCE), table headers are automatically provided. Row headers are not always relevant, and as such are not automatically inserted. If we notice a pattern of missing row headers, we’ll add a test to our weekly accessibility and 404 check script and assist the owners of problem pages.

(h) Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers.

At this time we are unaware of any tables on the site with more than one row of header information. Multiple header rows should automatically be incorporated into a single thead tag, however at this time we depend on our users to be aware of table header accessibility issues. Again, if we notice our users are misusing table or row headers, we’ll add a check to our script.

(i) Frames shall be titled with text that facilitates frame identification and navigation.

We do not use framesets on our site, and where iframes are used (rare), they are automatically tagged with titles.

(j) Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz.

Our pages should flicker at the rate set by end users (refresh rate). For most users on LCD screens, this should be around 60Hz, though it’s important to note this isn’t something we can control.

(k) A text-only page, with equivalent information or functionality, shall be provided to make a web site comply with the provisions of this part, when compliance cannot be accomplished in any other way. The content of the text-only page shall be updated whenever the primary page changes.

As we are unaware of any areas of our site where we’re out of compliance, we’re planning to discontinue our existing text-only site, which was unfortunately often out of data with our main site.

(l) When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.

Due to security concerns, the use of JavaScript is actually disabled for Drupal content editors. Javascript is only used as an integral part of two pages: The SAP Calculator and the Tuition Estimator. The Tuition Estimator is provided to us, and thus we’re dependent on the makers of that software to ensure accessibility. Neither page uses JavaScript to render interface elements. Although the SAP Calculator does depend on JavaScript to perform calculations, instructions for calculating SAP independent of the calculator are provided, as is contact information for help if needed.

(m) When a web page requires that an applet, plug-in or other application be present on the client system to interpret page content, the page must provide a link to a plug-in or applet that complies with §1194.21(a) through (l).

Java is not required to use our website, so applets do not apply. Flash elements should prompt the user automatically if needed.

(n) When electronic forms are designed to be completed on-line, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.

Form elements are automatically assigned names, and labels are automatically created to associate those labels with the appropriate elements. This is a significant improvement, as our old site relied on hand created forms that may or may not have had accessible elements.

(o) A method shall be provided that permits users to skip repetitive navigation links.

The first two links on every page are hidden to most users, but should be read by screen readers. The first will allow a user to skip directly to the main page content. The second will allow a user to skip directly to the main navigation.

(p) When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.

There are no timed responses required on our site.

Additional Accessibility Practices

Proper use of Structured HTML

As part of migrating content to the Drupal site, our content migrators were instructed to insert header tags where possible, providing a structured outline to many pages. This was a dramatic improvement, as many of our old pages simply used bold or large text to denote a new section.

Additionally, we’re developing our pages in HTML5. Although not fully supported by all screen readers, our pages are now marked up with meaningful divisions, such as nav and article, which help screenreaders to automatically find important sections of the page.

Retraining of users

As part of moving to a CMS, all of our content editors were retrained in a series of one to four trainings. Accessibility information was distributed at each of these trainings, and linked help documentation throughout the site includes accessibility guidelines.

Text Size

One common request we’ve had is to increase the default size of the text, in order to make it easier to read. This is actually an unwinnable battle, as the size of the text is actually dependent on a lot of things other than the styles we set. For example, the resolution of your screen has a tremendous impact (I know I have difficulty reading text on my 1920×1080 laptop screen that I didn’t have on my old 1440×900 laptop).

But it is reasonable for us to increase the text size some, as on the whole devices have been increasing in resolution. We will be exploring different options with CSS Media Queries to use a larger size than you may be used to seeing, even after we launch the new site. The most important change we’ll be making is to ensure pages look good regardless of the zoom level you use at home. If you increase the size of the text in your local browser, it should continue to flow correctly on our page, rather than overlap with other elements.

Color Blindness

Although I’m not able to show them here yet (coming in a future post!), we’ve run mock-ups of our new website through color blindness simulators to make sure there’s enough contrast in our content to make it visible to all sighted users. You can get an idea of what we’re talking about online.

Use of Tables

For a long time in HTML, tables were used not only to display tabular data but also to lay out pages, which violates the idea of semantic HTML. Unfortunately, our site was very guilty of this practice. We’ve since removed all the tables that were used for layout, and instead replaced them with appropriate block level elements.

Tables are tricky on mobile devices, as they force a width that will accommodate their contents. We tried a few different solutions, and settled on one that provides an alternate visual layout while preserving the existing table structure, which should allow screen readers to work even from mobile devices.

Because tables can be so difficult, we’ve also sought places where tables were improperly used to list data, and have converted most of those to ordered or unordered lists.

Drupal User Accessibility

Although we are not aware of any accessibility concerns for our users at this time, we also make an effort to improve accessibility for our content editors. Drupal has some accessibility resources, as well as a group dedicated to accessibility concerns that can be helpful. The WYSIWYG editor that our users use to make changes to pages has a similar page for accessibility information. We’ve also made a conscious decision to avoid administrative modules that rely heavily on the use of javascript to provide functionality.


Possibly the most important thing we’ve done is to refocus ourselves around constantly improving accessibility. We regularly share articles about site accessibility with each other, and try to stay current on things like WAI-ARIA. We’ve also started including disability demographic information in our surveys, to get a better picture of our audience. Accessibility factors into every decision we make as a webteam.

As with any other current technology, accessibility on the web is a moving target, changing every year. We do our best to make our site accessible, and try to continually improve troublesome areas. Of course, if you notice something on our site that isn’t accessible, please let me know!