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.


Post Script: You ought to add this to your "How To Make Your Blog Accessible" under a 'Be Aware' category.
Thanks for clarifying this. We need some sort of WordPress accessibility working group, unless there is one already.
This has been one of my pet peeves for a long time. It's akin to Dreamweaver's insistence on calling the blockquote button "indent."
Indent?! I had forgotten about that. Way to miss a teachable moment.
For fear of a little too much cross-commenting, I'll condense what I wrote on Glenda's post:
WordPress, and other CMSs, is a Web content authoring tool. Therefore it's important to assess them accordingly against the Authoring Tool Accessibility Guidelines 1.0 (ATAG). This has been done once before, that I know of, three years ago for WordPress 2.01 Alpha. What ATAG says is basically that authoring tools must not only be accessible but support non-expert end users in authoring accessible content
In other news, ATAG is being updated to ATAG 2.0 to be more in sync with WCAG 2.0 and provide a broader coverage to web-based interfaces such as social networking sites that allow users to add and edit Web content.