Some considerations:

The alt attribute for the img element is often ignored or misused. If it is omitted, the page will fail validation using current Doctypes. If it is "bypassed" using "" it will not be of much use to People with Disabilities or visitors employing text-only Browsers or audio screen readers.

If you are having trouble visualizing what alternate text is needed try this: imagine you are blind and using a reader/interpreter such as JAWS; or have impaired vision and are using a text-only Browser such as Lynx with enlarged text selection and images turned off; or have a disability that requires use of an audio screen reader. Each time an audio output screen reader comes to an image it will announce "image" and then read the alternate text aloud -- if there is none there will just be a silent pause. If it is a text-only Browser (some sighted Web visitors use them for speed of browsing) the alternate text will display for each image -- if there is no alternate text there will just be a blank space (or ""). As you compose the alternate text for an image imagine the questions one of the above described visitors may have about the image: What does it depict? Why is the Web author using it? what kind of image is it? (examples): It is not much use to employ alternate text such as "[picture]" far better to use something like "[photograph of the house I grew up in]" --- not much use to employ "[icon]" far better to use, for example, "[W3C XHTML Validation icon]" -- not much use to employ "[ad gif]" better to say ["animated gif representing the CDs I offer here]" .......... and so on.

Several years ago I was the Senior Technical Advisor (volunteer) for Access World Design and Development, Inc. -- a non-profit organization dedicated to the training and employment of the disabled in accessible Web page authoring. Most members were severely disabled (Deafblind or with respirator dependent Duchenne Muscular Dystrophy) who we trained to become independently proficient Web page authors. It was a most rewarding experience and I remain committed to Web Content Acessibility to this day. It was fashionable at that time to enclose alt text in [square brackets] so that it would be readily discernable in Lynx and screen readers. I still identify my alt text this way.

James

I agree with you completely.

Good SEO practices usually turn out an easily accessible site for the disabled. I had a request to do some updates for the disabled by a company one time and so I just did some SEO friendly stuff and it actually made the site a lot more appropriate for the disabled browsers.

Easy things that Web Authors can do to enhance the Accessibility of their pages:

Provide descriptive text for all images (content & function via the ALT tag and adjacent informational text or captions)

Structure pages utilizing header markup. (use h1 for the page title and h2-h6 for section headings)

Provide a hierarchal Site Map of page links (prominently displayed)

Ensure links make sense out of context (natural language text descriptions - avoid "Click Here" or text within images)

Avoid duplication of link text (for different anchors on the same page)

Insure that there is good contrast between text and background colors

Do not rely on color alone to convey meaning

Use proportional, rather than absolute, sizing and dimensions (% and em rather than pixels)

Author to standards (for interoperability, ease of maintenance, etc.)


James

This post has been edited by jamesicus: Apr 1 2008, 09:30 PM

Not providing meaningful alternative text for images is the most frequent Accessibility error committed by Web Authors - fortunately one that is easily corrected. I think Appropriate Use of Alternative Text by WebAIM is an excellent reference and guide for complying with this essential WCA requirement.

James

Thanks for this it's an interesting read, will definitely think of this whilst designing

Great stuff, Craig! Entering alt="[explanatory text]" for images may seem tedious at first, but it soon becomes an ingrained habit. I could no more forget to include alt="[explanatory text]" for images now than I could forget to tell Beverly (darling wife) I love her each morning -- believe me, that is very important!

James

This post has been edited by jamesicus: Apr 2 2008, 01:35 PM

It's important to think about what the purpose of your image is.

If the image is purely decorative, then the alt attribute should be empty: alt="". Better yet, however, use CSS background images (since this image is presentation not content).

Try to imagine what it would be like to use your website with a screen-reader (better yet, actually test it). When confronted with an image that is missing an alt attribute, screen-readers usually read out the complete filename!

Now, can you imagine how annoying it is to hear this: "image: left border drop shadow...image: right border drop shadow...image: top border drop shadow...image: bottom border drop shadow...image: top left corner graphic...image: top right corner graphic...image: bottom left corner graphic...image: bottom right corner graphic"? If you're going to hard-code decorative images into your HTML, please leave the alt attribute blank!



I don't like that method. The rendering of alt text is a user agent issue. Different UA's will use different methods; but forcing them to announce "open square bracket a photo of my cat close square bracket" is just annoying.

This post has been edited by MikeHopley: Apr 4 2008, 10:13 AM

I think the use of square brackets for enclosing Alt text has great utility in that it clearly differentiates it from the page content in textual Browser ouput -- it avoids confusion. The audio screen readers I use do not function as you describe, in fact, they do not acknowledge bracketry (or other formatting devices) at all. Please refer to this thread for an explanation.

James

This post has been edited by jamesicus: Apr 6 2008, 03:45 PM

Again, this is a user agent issue not a developer issue. The user agent can choose how to display/distinguish alt text. Surrounding it in brackets is poor semantics. First, do no harm.

I understand your reason for doing this. I just don't think it's a good enough reason.



If you're making the "what happens in practice" argument, then you'd better not base your argument on some obscure screen reader.

Jaws (the most popular screen reader) does read out your "bracketry" -- at least, it did last time I used it!

This post has been edited by MikeHopley: Apr 8 2008, 03:58 AM

say no to brackets...

I agree with Mike on that one... Let the browsers identify images for them as that is what they are meant to do.

I surrender on this -- an old idea that had its day. It wasn't well received on the Accessify Forum either.

James