Accessibility: June 2011 Archives

Elizabeth's Accessibility Testing Protocol

| | Comments (0)

A question that has come up on the TLT "A-Team" (that would be A for accessibility) is how to provide a simplified testing protocol. For a while, we've been trying to come up with one tool to replace the current accessibility.psu.edu Testing Protocol developed a while ago.

In a recent testing session though, I have to confess that I still fell back to my multiple tool scenario because it actually saves time. I did feel a little better that, at the Penn State Web conference, accessibility guru Glenda Sims pretty much recommended a similar protocol, but with different tools.

I'll try to explain what my protocol is, and why I think it saves time. I have to warn you though, that it does require some familiarity with HTML. Before that though, I will explain a very 2-step simple protocol which does work, but will take some time.

The Simple Protocol

Based on what the major issues have been, Penn State has been focusing on screenreader users and the hearing impaired. The simple protocol has been:

  1. Test key pages on a screen reader (no cheating with a mouse!)
  2. Test all videos for captions. Ensure that audio has a transcript

This is a solid protocol and will find almost all the errors we are concerned about. It will miss some color contrast issues and will not necessarily determine if users NOT on a screenreader can use the material with just a keyboard. It is time consuming and does require some familiarity with a screen reader, but does have the advantage that minimal HTML knowledge is required.

More Complex But Faster

However, I do in fact use more tools, to streamline testing to the main hot spots. Once I got familiar with these, I do find that the process goes much faster.

Use Firefox

There are lots plugins and tricks that make Firefox my browser of choice (although Opera is also recommended). One of my favorite Firefox tricks is that you can select part of a page and view the code for just that selection. Very handy for zooming in on tricky areas.

For Firefox, I would install the FAE Toolbar. The FAE Toolbar not only links to some of the tools mentioned below but includes tools to quickly disable image, CSS and other tools.

WAVE It

The first part is to test a "typical" page and the home page on a site. I usually do this with WebAIM Wave. The report not only flags errors, but does a good job of showing you what a screen reader will read out in many areas. Specifically it shows:

  • ALT Tags for all images - You can see if they are present and make sense
  • Form field labels - like ALT tags, you can see if they are present and make sense
  • Location and levels of headers - Proper use of headers is very valuable to screen readers
  • Table structure - If your data table is missing header, summary and captions. It probably needs a redesign

The other benefit of WAVE is that you can spot WHERE you need to fix code.

Disable CSS

This is a good way to test reading flow in a screen reader. Sometimes floats can put the last thing in the code on top visually, but by disabling CSS you will see the "true order" which is the one screen readers access.

Automated Testing

Testing tools like FAE (Illinois) and A-Checker have their place, but it can be hard to identify the location of errors. There are also some ways you can get false positives.

Check the HTML!

If I see a table, image or form, I sometimes just check the code.

Check Color Contrast

An item most reports can't check is color contrast. There are tools to do this automatically, but I find that my eye can find many of the errors. Black and white - good. Dark navy on sky blue, probably good. Light gray on dark gray? Time for a check.

Verify with a Screen Reader

I still test with a screen reader when the other tests don't give surefire results. I check things like new tools (VoiceThread, NBC Learn, Google Forms....), anything requiring interaction beyond the usual HTML.

(Actually a lot of "screen reader" testing was actually done by Michelle McManus and Peggy Hoover who are everyday users of JAWS. If you have access to real users, they are your best source of information).

A Single Tool?

A new tool I am interested in checking is FireEyes from deque. This does put all the protocols I discussed above into one environment. But from what I've seen, you still have to push a lot of buttons.

Mac Office 2011 DOES Have Alt Tagging for Images!!!

| | Comments (0)

One of my back burner issues for accessifying Microsoft Office docs is that, until recently, only the Windows version of PowerPoint, Word and Excal had the tool to add Alt Tags (the text that reads a description of an image or other object). This made it difficult to ask anyone on a Mac (which includes lots of instructors these days) to fully accessify their documents

No more! As of Office 2011 for the Mac, the ALT tag tool is available. To tag an image in Office 2011 (Word, PowerPoint and other Office applications), do the following:

  1. Click on an image to reveal selection handlebars (blue dots on the corner).
  2. Right click or control+click on the image and select Format Picture.
  3. In the "Format Picture" window left menu, select Alt Text (at the bottom)
  4. Enter a short Title.
  5. In the Description field, remove the file name and enter appropriate descriptive text as needed.
  6. Click OK.

By the way, these instructions for Windows Office are similar to these.

Struggling to Simplify Accessibility

| | Comments (0)

An issue that keeps coming up in accessibility discussions if how we can simplify it, but the goal remains elusive, and will probably remain so. I think there is a way it can be done, but you have to understand why it's complex in the first place.

Accessibility is Difficult Because....

One way in which accessibility differs from other technology standards is that the focus is on satisfying human needs versus machine needs. The goal of an XML standard is machine readability, but humans aren't as simple as machines. Humans are not only more complex, but also more varied and you can't just "read their spec", but have to make educated guesses about your audience. This is why issues like usability, accessibility and even learning are so thorny - it's all about the human brain.

Another challenge is that your accessibility audience is varied by design. Right now, we are focusing on the visually impaired audience on screen readers, but when video was coming on the scene in a big way, the audience in focus was hearing impaired. The truth is that both audiences need to be served along with those with motion impairments and cognitive disabilities. This seems complex, but it's the same issue that faces any Gen Ed course at Penn State which may need to serve people of all ages and from all backgrounds. It can be done.

A third challenge is the variety of technologies that need to be accessified. Ten years ago, we worried about HTML a lot, but now we have media, dynamic web services and mobile devices. Right now almost all of it is designed without considering accessibility (that's why lawsuits continually pop up).

And this leads to the final challenge - diversity in training needs. I think one issue with a lot of accessibility info is that it's geared either for techies who need to know it all, but can understand the code snippets out there or for administrators who need to understand the issues, but won't directly make the fixes. I think what's missing is information for those posting content with modern tools (the ones you don't need HTML for). There are steps these content providers need to make, but it can't be too technical or time consuming...or it will never happen.

One Solution

Believe it or not, if you are working with just one set of tools (e.g. PowerPoint or video production), your to-dos are fairly small and simple. Videos need captions, some descriptions for the visually impaired and fed through a player which supports keyboard commands. PowerPoints need titles on slides, descriptions of images (preferably ALT tags) and decent color contrast/font selection.

This reminds me of the Unicode problem (foreign characters on the Web). When I began investigating foreign language on the Web years ago, I began by explaining general principles, then advising people to look up what they needed in tables.

Many, many blank stares later, I realized that people needed a way to find the specific information for their specific problem. I created pages for specific languages and additional pages just for Web masters who could handle some of the encoding theory. I don't claim to have the perfect navigational system yet, but I can honestly say I've been able to filter out information for many people fairly well.

I'm now thinking the same may be true for accessibility. Not everyone at Penn State will need to understand all of the WCAG 2.0, but we may be able to help them understand the fixes that need to be done for specific tools and maybe why it's important. The Accessibility Site from University of Minnesota does this pretty well and it's been suggested that we emulate that.

Other Solutions

Another piece of the puzzle I'm hoping will fall in is better tools for the mid-techie. I've commented/complained before that too many tools for accessibility assume that you are a "specialist" familiar with HTML and the advanced tools of Acrobat or Microsoft Office. In reality though, "content" is being created by just about everyone, including very busy instructors and grad students. It would be nice if more tools integrated accessibility like Dreamweaver does.

And...I am waiting for accurate speech recognition and better reading algorithms from screen readers, but this requires some hardcore theoretical linguistics. Who knew.