Daily Archives: October 13, 2010

Upgrading ‘Accessible’ to ‘Fully Accessible’

The Internet Archive wants to grant universal access to all knowledge. It’s important to note that ‘universal’ and ‘all’ in that sentence aren’t generalities. When we say ‘universal,’ we mean for everybody, and when we say ‘all,’ we mean everything. To that end, Open Library has been conducting ongoing testing with one of our most important audiences in order to create a website that allows blind and visually impaired visitors access to all available resources, and particularly to downloadable books.

Last Thursday, October 7th, George Oates (Open Library’s lead designer), Mike McCabe (our resident DAISY file specialist) and I visited LightHouse for the Blind and Visually Impaired here in San Francisco and sat down with three extremely patient and helpful volunteers to observe while they used our new site to find and download books to their book readers.

According to Lisamaria Martinez, one of our volunteers, blind and visually impaired readers generally read several times the number of books that sighted readers do, yet have access to only a small fraction of them. Newer titles in particular are hard to find in accessible formats – and these are the titles we’re starting to make available as “protected” DAISY files which can be loaded onto a variety of book reading devices like the Victor Stream or BookSense readers. It’s vitally important that we make them easy to find, easy to download and easy to use.

As a front-end coder and visual designer, I’ve often made assumptions about visitors to websites I’m designing or coding, but have rarely taken the time to consider those who can’t see the pages until now. How do you navigate without vision? How can we convey the same kind of visual codes about the page’s contents (headlines, colors, white space, keylines, and so on) to blind and visually impaired visitors?

We went in without any formal test plans because we wanted to watch as the testers – who hadn’t used the site at all – first encountered it and used its search features to find titles they wanted to read or find out more about. If you’re trying to make your site more accessible, here’s a few of the lessons I learned from just a few hours of observation and that we’ll be implementing in the coming weeks.

  • First, and foremost, code to web standards. This seems obvious and is just good practice, but if you’re ever tempted to cheat a little bit and use tags or elements for unintended purposes, resist that urge or find another solution. Just because a page “looks right” doesn’t mean it is.
  • Headers (H1, H2, etc.) are often used as page navigation in screen readers. Use them! Don’t fall back on resizing text and bolding text to mimic headers visually. Sprinkle them about liberally so visitors can skip down your pages to important parts.
  • Try to set font sizes at relative (em) measurements via style sheets. Visually impaired visitors often want to enlarge text for easier reading, and some browsers refuse to re-size fonts set to absolute pixel (px) sizes.
  • Page headers or sections are often implied by color or placement and don’t always have explanatory text to describe what the information is. For example, on our search results page, we provide search filter lists along the right side of the page with labels like “Authors” and “Subjects” but didn’t implicitly explain what they do. Adding a simple header with a line of explanation about their usage, with a link for search syntax, helps.
  • We often try to compress labels to as few words as possible, believing that the accompanying information was obvious – except if you can’t see the accompanying text and you’re navigating by header. We’re using more explanatory copy in our labels now.
  • As you probably already know, titles and image alternate text (the ALT element in the IMG tag) are extremely important when you can’t see the images – like book covers. We were inserting the book titles as alternate text, but that really didn’t explain that they were covers of the books. Think about what the image is, rather than what it conveys visually.
  • If we’re missing information about a work or one of its editions, we either don’t show the field at all or leave it blank. That’s usually okay, but in one special circumstance it caused some confusion. Editions of a work are originally presented by date of publication – which would be great, except that places editions with no known publication date first. Simply noting those cases by adding in “Published date unknown” rather than no text at all adds meaning.
  • Navigation between pages was sometimes problematic. In particular, in order to download a DAISY file to read the book, we move the site visitor to a dedicated page that provides some necessary explanations about protected DAISYs because anyone can download one, but you need a special license to actually open it. But the page was missing one key feature: a search field. This turns out to be the primary way in which visually impaired visitors (as well as sighted visitors) explore a site. We provide a search field on every page except the DAISY download page, which isn’t obvious if you can’t see it. Adding a link to the search page brought back a sense of comfort to our testers.

We still have some gaps and holes to fill in, and we’ll keep testing the site both formally and informally to further enhance accessibility for every visitor. If you’re in the business of building sites, I heartily recommend that you contact an organization for the blind and visually impaired in your own city or town and give it a run-through with an audience that is often neglected, if not ignored. I’ll bet they’ll be overjoyed to help you out and you’ll wind up with a better site in the end.