Working together to produce an accessible site

At the most recent Drupal4Gov,* Zane McHattie and I presented "Considering Accessibility Throughout the Process." This Drupal4Gov was targeted at theming and accessibility, and since I'm a front-end dev, my part of the presentation focuses on what themers can do to make sites more accessible. However, a truly accessible site is the result of developers, designers, and content creators working together.

This was my first presentation to a group of people not in my workplace, so I'll admit that I woke up very nervous the day of and wrote out crazy detailed notes on what I was going to say. Since these notes would otherwise go to waste, I repurposed them to write up the presentation for this blog post.

1. Gather requirements early.

Front-end developers, designers, project managers, and clients all benefit from thinking about where time will have to be spent on accessibility during a project. If you're making a 508-compliant, accessible site, planning for this in your timelines, making sure your team knows how it will affect each member, and testing and revising throughout the process will go a long way toward a successful launch.

Kick off your project with a solid understanding of your agency's or client's requirements. While everyone is subject to Section 508, different agencies can interpret it differently and even enforce more stringent accessibility requirements (HHS is a good example). Some clients who request YouTube videos on their site may not want to spend time skinning the YouTube player to make it more accessible; others may require it.

It also helps to know what third-party content your client intends to serve up on their website (e.g. videos, podcasts, etc.) and whether the services they use for this are accessible. If you have to embed an iframe on your site with inaccessible content inside, all the work in the world won't make it compliant, and communicating that to your client early can prevent you from being held responsible for work outside your control.

Conducting some discovery on the site will help you identify places where you can compromise. Dan Mouyard of Forum One had a great presentation at Drupal4Gov on testing site accessibility; during it, he pointed out that there is no such thing as a 100% accessible site that meets every benchmark. Instead, you're aiming to get sites as accessible as possible, as fast as possible, as efficiently as possible. For example, if your client wants a maps mashup, you may choose to provide that information in an alternative format (more on that below) rather than spending a lot of time and testing on creating a map that screenreader users can browse intuitively.

Finally, remember that accessibility isn't just about screenreader users; it's about all kinds of users, from those with mobility issues to hearing impairments to those who have trouble with content that's not written in plain language. Catherine McNally's Drupal4Gov presentation did a fantastic job of showing the many types of users impacted by poor accessibility. At its heart, accessibility is good usability; everyone benefits from it.

2. Know where themers invest time making things accessible.

Assuming that you’re working from an accessible base theme that already includes basic accessibility features, such as skip navigation, you can expect to spend time on:

  • alternative formats
  • JavaScript fallbacks
  • content type adjustments
  • module markup adjustments
  • heading level adjustments
  • mobile accessibility
  • admin accessibility

This post will go over specific examples of the first five and touch on mobile and admin accessibility.

Alternative formats

During the planning phase of a project, you may identify things you want to build that will be difficult to make fully 508 compliant; knowing where you need to compromise is key here. However, any information you present on your website needs to be accessible by your full audience. You may decide to display some information in an alternative format to make sure that everyone can access it.

I’m showing a basic example of an alternative format above. A search on Google Maps will return a map that would be difficult for a screenreader user to navigate, with markers and even small dots that could be difficult for someone with mobility issues to click. Fortunately, there’s also a text list that shows the restaurant name, address, phone number, website, and reviews. This list can be tabbed through. That’s not to say Google does it perfectly; the lack of a focus indicator is pretty frustrating. But it gets at the heart of showing information in a way your audience can digest.

Knowing we have the option to create an alternative format, it's tempting to declare this an easy option during the planning phase; however, anything you put on your website is going to need time from a front-end developer to build and style appropriately. If you’re creating a view with a long text list of locations to complement a map, you may need to include anchor links to help users skip around more easily. You may want to include icons, as Google Maps does. Your designer will almost definitely have thoughts about how it should look. This means that even your easy option can be time-consuming, and your timeline and estimates should take this into account.

JavaScript fallbacks

If your design has interactive elements, chances are good that you’ll be using JavaScript or modules that rely on JavaScript. The simplest example is a carousel. With JavaScript enabled, it may cycle -- or allow you to move through -- several featured items. With JavaScript disabled, it still needs to allow you to access those featured items, and you probably want it to do that without breaking the look and feel of your homepage.

This screenshots below show the rotator from the Social Security Administration. With JavaScript enabled, it shows 4 slides. With JavaScript disabled, it degrades nicely to a text list. This takes theming and some forethought about what you want the non-JavaScript behavior to be.


For an example of what can happen without fallbacks, see the dropdowns in the boxes underneath the rotators. The Javascript-off version doesn't have these, meaning that someone with Javascript off won't be able to jump to any pages in that dropdown. A simple "More" link replacing the dropdown in a noscript element would make things easier.

As you’re selecting modules that use JavaScript, you might find ones that handle their own fallbacks, but this will require testing. For example, while using an earlier version of Colorbox, I used Colorbox triggers in my views assuming that they would degrade nicely to a simple link (normal Colorbox behavior). But when I tested, I ended up with links that went nowhere. This was fixed in the current version of Colorbox, but it was a valuable lesson in assumptions about module functionality.

The key here is that if you include JavaScript elements in your design, your designer or UX strategist may need to spend some time figuring out how they should work with JavaScript off and then making them work that way; at a minimum, they will have to work iteratively with the themer during development.

Content type adjustments

Whether or not your front-end developer is the one making your content types depends on your team’s workflow, but chances are good that they’ll have to touch them to make changes that affect the markup. I once worked on a project that had the alt tag in a separate field from the image due to an issue importing content with Feeds (see http://drupal.org/node/1080386).

Now, if you use the alt tag attribute on the image, it will appear with its alt anywhere it’s used on the site -- most notably in views or teasers. But if you don’t, it appears with null alt. During testing, I had to make an adjustment to the content type (shown below) to add the alt field to the image and then work with the backend developer and a content person to move those alt tags.

Alternatively, you could spend time doing views rewriting (my original approach) or making template files to get that alt tag field associated with the image; in my case, this proved too time-consuming. In short, it would be ideal if we didn’t have to revisit the content types for markup reasons, but it’s a good idea to test things out and identify trouble spots before a large-scale migration; that way you’ll save yourself some work in the long run.

Module markup adjustments

The front-end developer is probably not the person with primary responsibility for modules. But you may find yourself needing to test and override contrib module markup in one way or another -- the most common being by copying their TPLs into the theme and adjusting them. The image below shows a typical example from the Twitter Block module. It has a link wrapped around an image and some text. The link text is the person’s Twitter username, and the image gets the alt text “Twitter Avatar.”

<div class="twitter_block tweet">
<div class="twitter_block_user">
<a class="twitter_block profile_image" href="http://twitter.com/<?php echo $user_image; ?>">
<img src="<?php echo $user_image; ?>" alt="Twitter Avatar" />
<span class="twitter_block_user_name"><?php echo $user_name; ?></span>
</a>
</div>
<div class="tweet_text"><p class="tweet"><?php echo $text; ?></p></div>
</div>

This alt text isn’t really useful to someone with a screenreader, and it’s repetitive for each tweet, so I copied this into my theme and replaced <img src="<?php echo $user_image; ?>" alt="Twitter Avatar" /> with <img src="<?php echo $user_image; ?>" alt="" />. The result is that all screenreaders would encounter is the username, which is much more intuitive.

This is a simple example. A more complex one is a recent update I had to make with Colorbox that didn’t include a TPL. When a Colorbox popped up, it didn’t tab the user into it, so a screenreader could open the modal window and then continue reading the page as if it hadn’t. We had relevant information in the pop-up, so we needed a way to give it focus. Since Colorbox relies on JavaScript anyway, we used JavaScript to give the first link in the pop-up focus when the trigger was clicked. Little adjustments like this are fairly simple, but they add up quickly if you’ve got a lot of contrib modules to work through.

Heading level adjustments

Your headings should be structured semantically: heading 1, then heading 2, then heading 3. Sometimes you’ll encounter modules that don’t respect this. If you use Views and group by a field, it puts a heading above a list of its children; trouble is, that’s always an h3, and sometimes an h3 isn’t appropriate -- for instance, if it’s the first heading underneath your h1, you’d want it to be an h2. Sadly, the normal way of changing HTML elements in views doesn’t work on group headers because it’s hard-coded in the TPL. However, you can hunt down that TPL (views-view-unformatted, usually; will be different if your view format isn't Unformatted) and change the h3 to an h2, globally for a view format or on an individual view basis.

<?php if (!empty($title)): ?>
<h3><?php print $title; ?></h3>
<?php endif; ?>
<?php foreach ($rows as $id => $row): ?>
<div <?php if ($classes_array[$id]) { print 'class="' . $classes_array[$id] .'"'; } ?>>
<?php print $row; ?>
</div>
<?php endforeach; ?>

To change the heading level of the grouping header, change <h3><?php print $title; ?></h3> to <h2><?php print $title; ?></h2>.

You might also use a module like Fences to pick semantically appropriate elements for different fields on your content types. For example, if you’re working on a Biography content type and you want the Role field to appear as an h2 above their responsibilities, Fences will let you pick the h2 from the Manage Fields screen. This is a great module that will save you some work as you’re creating something that’s structured semantically (and strip out a lot of unnecessary markup -- a nice plus).

Mobile and admin accessibility

Depending on the requirements of your site, there are two other areas where themers can sink a lot of time: mobile accessibility and admin accessibility. If you’re building a site that functions differently on a mobile device than on a desktop one (particularly when it involves different JavaScript), you might have to spend some time testing it in that device’s accessibility tools, like Voiceover for the iPhone.

You might also find yourself spending a lot of time on creating an accessible administrative interface, since the admins for government sites should be 508 compliant as well. It’s easy to spend time focusing only on the front-end portion of the site since that’s what the vast majority of users will see, so it bears noting up front that this is a potential trouble spot and getting your team -- or client -- on board with that.

3. Consider design accessibility, not just theme accessibility.

Plenty of people assume that a themer's going to have to spend time on this, but accessibility needs to be considered throughout the process to make sure that the end result is 508 compliant. Few designers appreciate it when a front-end developer starts changing the colors in their approved design; this means that color contrast needs to be considered up front, way before development starts. The design should be checked for color contrast before the people who’ll be approving it ever see it (see color tools at the bottom of this entry).

You’ll also want to spend some time ensuring that information is communicated with more than just color. For example, if the only difference between your links and your regular text is a dark blue color, some people may not be able to identify the links. If you add an underline, there’s an easy way to tell them apart. If your site features infographics or graphs, make sure color isn't the only way distinctions are drawn -- add patterns or, even better, clear labels.

Accessible designs go beyond color; you’ll also want to make sure that your fonts are large enough -- preferably 12pt, 10pt minimum. Your fonts should be either web-safe, or can be purchased from a service like FontSpring and embedded. This ensures that you won’t have to use images for your headings, which are worse for accessibility and much worse for your content creators to maintain. Changing a stylized image heading can become nearly impossible if you don't have the font or the original PSD.

If your designers have an opinion about how focus indicators look, they should specify them up front; otherwise the usual dotted gray box will be used when users tab through or click links. Removing the focus indicator during development should not be an option.

Finally, if your design has a lot of interactive elements that will require JavaScript, you should start thinking during the design stage about how you want the fallbacks to work and how much time you’re prepared to spend making the experience the same for users with JavaScript disabled.

4. Consider content accessibility.

If the developer receives content that isn’t accessible, the site won’t be accessible no matter how much work he or she does. Most obviously, content creators should create alt text at the time of image selection. If an image is just decorative, it’s okay to have null alt text, but if it conveys meaning -- like a photo of an agency administrator testifying before Congress -- it needs to be communicated to the user.

Both video transcripts and video captions should be provided. Contrary to popular belief, both are necessary for 508 compliance. If only video transcripts are available, make sure you budget extra time to add captioning to videos. If you're providing audio files, make sure you include an audio transcript.

Content should be structured semantically. This goes beyond just theming; content creators are going to continually interact with your WYSIWYG and will need to be trained on proper heading order (h2, then h3; no h1s, since the h1 is reserved for the page title). When possible, content should be written in plain language so it's easily understandable.

5. Test iteratively.

There are a lot of ways a site can be inaccessible, and getting a big list of deficiencies right before launch can derail a project. To avoid this, you can educate content creators early and test iteratively throughout design, development, and migration to identify problems early and correct them as they arise. The result is a more cohesive site with graceful fallbacks where they're necessary.

If someone outside your team will be evaluating the site before launch, it's a good idea to reach out to him or her early. We've had success with submitting prototypes of potentially tricky functionality for testing before heavy development begins. When you do encounter problems, these evaluators can be a resource since they often have a breadth of experience with these issues and know the quirks of their testing software enough to provide some guidance.

6. Know your tools.

There are way too many testing tools for all of them to be listed, but here are a few that we use at Rock Creek to get a jump on testing.

Color tools

Markup tools

  • WAVE (website and Firefox extension; the Firefox extension offers more thorough testing results)
  • AMP (proprietary Windows tool; there's also an express version)

Notes

Original Article: