March 2009 Archives

I did not attend as many of the web accessibility panels at the South by Southwest conference as I had thought I might. I did make it to the one I was most interested in: Deafness and the User Experience.

The session had originally been titled "Aging, Cognition, and Deafness: The Quirky Corners of Web Accessibility." To be honest, when I saw that title, I had thought "why are they using the word quirky?" I felt like it reinforced the misconception that web accessibility issues are primarily about people with visual impairments. As it happens, the presenters on Aging and Cognition were caught in a schedule conflict between the presentation and the Web Standards Project meeting. Lisa Herrod decided to go ahead and do her part of the presentation, about web accessibility issues for people who are hard of hearing or deaf, whether they identify as culturally Deaf or not. She had previously written an article published on A List Apart on the topic, and the title of her article became the title of the panel.

I did learn a lot from the session, but consider some of her tips for making web content more accessible to people in these groups (from the article, which is a good outline of what she discussed in the session):

  • Use headings and subheadings.
  • Make one point per paragraph.
  • Use bulleted lists.
  • Include a glossary for specialized vocabulary, e.g., medical or legal terminology, and provide definitions in simpler language.

Basically, the session reinforced my feeling that most web accessibility best practices are anything BUT quirky, regardless of whose needs you're trying to meet. These tips would help anyone who is trying to get information from your website or blog. I'm not saying this to downplay what Ms. Herrod presented (and indeed there are some issues specific to the deaf, hard of hearing, and Deaf populations). I just found it inspiring, though, to consider how much you achieve when you do the basic work of writing well and coding well.

I would still love to attend this presentation in its originally conceived form, but big thanks to Ms. Herrod for the inspiration and a good session.

The South by Southwest Interactive (SXSWi) conference starts Friday, and I'm going, hurray! Not that I don't love my home office, complete with toddler who insists on climbing into my lap often no matter what diversions Grandma has arranged, but a few days out of the house to learn new things will be a nice change of pace.

There are quite a few accessibility sessions:

Making Web Widgets Accessible: Tools and Techniques on Saturday at 10:00 a.m. is geared towards developers: "Browser vendors, code library developers, and Ajax gurus demo best practices for making widgets and dynamic web content accessible. You'll also see how they're implementing W3C's new Accessible Rich Internet Applications Suite, WAI-ARIA."

Accessible Flash and Flex Applications on Sunday at 10:00 a.m. is another developer session: "Developers are increasingly interested in delivering accessible applications that use Flash-based technologies but are uncertain as to what is possible and how to develop and test their applications. This panel will look at best practices and examples, and share information on what's new in Flash accessibility."

I may attend AJAX Accessibility: An ARIA Duet on Sunday at 11:30 even though I don't build applications, just because Knowbility director Sharron Rush is on the panel, and she's one of my favorites: "Accessible Rich Internet Applications (ARIAs) are not just possible but freely obtained through open source techniques. ARIA developer Becky Gibson will demonstrate ARIA coding techniques and existing toolkits to solve real world challenges posed by accessible technology advocate Sharron Rush."

Monday at 5:00 p.m. is the one I'm most excited about, though. It's listed as Deafness and the User Experience on the main SXSW site but listed as "Aging, Cognition, and Deafness: The Quirky Corners of Web Accessibility" on the "My SXSW" site. Perhaps the presenter decided she had to pare it down for time? Either way, this is going to be cool: "The user experience for a culturally Deaf audience is a fascinating area, influenced by sign language, history, education and migration. This session looks at the different needs of both the culturally Deaf and post-lingual (non-signing) deaf audience, and discusses what you can do to improve the UX for both groups."

Universal Design for Web Applications is a book reading on Tuesday at noon. It's based on the O'Reilly book of the same name.

If you're heading to SXSWi, take a look at these great learning opportunities! And let me know if I missed anything, the schedule is quite overwhelming!

In Glenda Watson's accessibility review of WordPress 2.7, she had a few things to say about the dialogue box used to upload an image:

The thing that really bugs me is, in the “Add an Image” dialog box, the Title is marked as a required field, not the Caption that becomes the ALT: a crucial piece in web accessibility.

It is the ALT text that enables an individual using a text-to-speech screen reader to hear what an image is; not the TITLE. It is the ALT text that appears on the webpage when an image does not load; not the TITLE.

Confusion about the difference between ALT and TITLE already abounds, and Glenda is right that the WordPress scrambling of all these elements does not help.

The "title" that the WordPress dialogue box is asking for does not perform the same function as the TITLE attribute in HTML. WordPress uses the title as an internal label for the image to help you find it again if you want to re-use it. That's why the default value is the filename. Using that field automatically as the TITLE in the HTML makes little sense, since the purpose of the TITLE attribute in HTML is to convey extra information about the image.

"Caption" is a word that most people associate with print publication captions that appear under photographs, and there is an HTML tag called CAPTION which is for something totally different than what happens with the caption in the WordPress dialogue box, which becomes the ALT text.

The logical place to ask for something that would turn into the ALT text would be in the "description" field, except that it's too long. And why in the world would you need to fill out three separate fields for one image, anyway?

There are similar issues in my beloved Movable Type as well. In Movable Type 3, there wasn't a prompt in the default File Upload process for the ALT attribute, and the filename was used as the ALT text by default. In Movable Type 4, using the asset manager, whatever you include in the Name field becomes the ALT text, but there's no indication that this is the case in the dialogue box. Leaving the Name field blank produces a blank alt attribute and the asset manager uses the filename as the asset's name within the system. If you use the Better File Uploader plugin (which is awesome), you can configure it to ask for alt text during the upload process, but it will still fill in the image's filename by default and you have to replace it with something meaningful.

The beauty of using HTML and CSS together is to separate content from presentation. I would argue that the way both WordPress and Movable Type handle image uploading fails to separate two other things that should be separate: the content added by the user and the internal functions of the blogging tool. When a blogger is presented with a dialogue box because she or he is adding content to their blog, in this case an image, that blogger should be prompted to add the information that will make that image work for the readers and the blogger. The needs of the software for a label to use when filing the image should be secondary, and yet they seem to drive the design of the upload process.

It's a disservice to people with disabilities, but also to bloggers, who aren't being given the information they need to set up their images with full understanding of the consequences for certain decisions. Given that a properly labeled dialogue box would go a long way toward conveying the needed information, it just doesn't seem that hard to fix.

So how about it, Automattic and Six Apart? Care to tweak your tools to encourage accessible blogs with proper use of attributes? There's a pumpkin muffin in it for you.

Powered by Movable Type 4.32-en

Want all the tips?

How to Make Your Blog Accessible is my work in progress.

Get Updates

get updates by feed reader or email

Archives