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

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

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

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.

Updated Accessibility Requirements

An Update to the Update:

1/23/17 – The new 508 rules are out! You can read the announcement from the Access Board (on a website powered by Drupal!), or read my summary of the rules changes.

Original Post:

As people that maintain content on the web, we’re all responsible for making sure our content adheres to the Section 508 standards. However, as discussed in an earlier post, these rules are a little dated. Fortunately, the government is currently in the process of updating the rules, and a final rule could come any day – although the government has not been successful updating these standards in the past.

The new rules are likely to closely mirror the WCAG 2.0 standards, which are an international, consensus driven standard for accessibility for a wide range of technology formats, including web pages, Word documents, PDFs, and many others. WCAG 2.0 includes three different levels of compliance: A, AA, and AAA. It’s expected that the new 508 ruling will require compliance to the AA level.

During the next few posts, we’ll explore some of the ways the new standards differ from what we currently require of our Drupal pages. If you’d like a head start, you can view a complete comparison table on the Access Board website, which we’ll use as the basis to explore what’s different between 508 and WCAG 2.0.

One final note: although I’ll be writing these posts with a lens toward how it applies to our web pages, 508 rules apply to all the materials we create or purchase, including classroom materials. If you’re an instructor, you may want to get in touch the ATC for help ensuring your class materials comply with accessibility requirements.

All Posts in this Series

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 webmaster@lanecc.edu.

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 http://www.lanecc.edu/esfs, or http://www.lanecc.edu/finaid), 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 http://www.etre.com/tools/colourblindsimulator/

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 www2.lanecc.edu (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 http://www.google.com/accessibility/products/.

(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 http://support.google.com/youtube/bin/answer.py?hl=en&answer=100079).

(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!