Jump to content

Cre8asiteforums Internet Marketing
and Conversion Web Design


Photo

Beyond Alt Text: Making The Web Easy To Use For Users With Disabilities


  • Please log in to reply
14 replies to this topic

#1 cre8pc

cre8pc

    Dream Catcher Forums Founder

  • Admin - Top Level
  • 13365 posts

Posted 01 January 2008 - 05:06 PM

It's rare that Jakob Nielsen offers his case studies and reports for free. However, at the moment one is.

Nielsen Norman Group Report Beyond ALT Text: Making the Web Easy to Use for Users With Disabilities 75 Best Practices for Design of Websites and Intranets, Based on usability Studies with People Who Use Assistive Technology is free to download.

It's 148 pages PDF format, 7 MB

The report contains:

* Results of usability tests of 19 websites with users with several different types of disabilities who are using a range of assistive technology:
o blind users using screen readers
o blind users using Braille readers
o low-vision users using screen magnifiers
o motor-impaired users
* Test data collected mainly in the United States, with some additional studies in Japan to ensure the international applicability of the recommendations
o A total of 104 users participated in the usability studies:
o 84 users with disabilities
o 20 non-disabled users who served as a control group
* 75 detailed design guidelines



#2 Guest_Autocrat_*

Guest_Autocrat_*
  • Guests

Posted 01 January 2008 - 05:11 PM

Any information on the level of experience of the users with disabilities?

Still, shall consume it rapidly :)


LMAO - and after all the effort of compiling the research, they use a stright link to a pdf file with no warning!
:D

Edited by Autocrat, 01 January 2008 - 05:13 PM.


#3 AbleReach

AbleReach

    Peacekeeper Administrator

  • Admin - Top Level
  • 6457 posts

Posted 01 January 2008 - 09:11 PM

LMAO - and after all the effort of compiling the research, they use a stright link to a pdf file with no warning!

Not so.

Screenshot:
Posted Image

#4 kulpreet_singh

kulpreet_singh

    Mach 1 Member

  • Members
  • 438 posts

Posted 01 January 2008 - 11:50 PM

Thanks, Kim! I look forward to reading it.

#5 Guest_Autocrat_*

Guest_Autocrat_*
  • Guests

Posted 02 January 2008 - 04:03 AM

erm...

...AbleReach...
try using IE to view the page, and see what happens when you click the link.
It is a straightlink, which means it will attempt to load the item in the browser... something that is nearly always advised against, unless you "tell" people.
One of the oldest "usability" points I've encountered.

Thats what made it so funny :)

#6 cre8pc

cre8pc

    Dream Catcher Forums Founder

  • Admin - Top Level
  • 13365 posts

Posted 02 January 2008 - 08:23 AM

Autocrat, the text from my post:

It's 148 pages PDF format, 7 MB


was taken directly from the page where the download link is.

#7 Guest_Autocrat_*

Guest_Autocrat_*
  • Guests

Posted 02 January 2008 - 09:31 AM

I'm obviously doing a bad job of pointing out what I consider to be the foible... so I'll try for a last one, then I'll give in.

I've seen it explained that loading a PDF straight into a browser, without warning the visitor of this occuring, is considered as bad form. This is something that I total agree with, as I find it annoying/frustrating when it takes ages to load something.
If it is not an actual "download" link, (that being something that automatically calls up the download box), then it should clearly indicate that it may load in the browser window if clicked. If the visitor wishes to download, they may wish to use the right menu and select 'Save Target As' in the context menu.

Does that make more sense.

#8 cre8pc

cre8pc

    Dream Catcher Forums Founder

  • Admin - Top Level
  • 13365 posts

Posted 02 January 2008 - 12:32 PM

The usability warning is when there is no indication whatsoever the link goes to a PDF. Nielsen's page has several warnings, as well as lots of good content about what will be found if the download link is clicked on, including how large the file is.

The link doesn't offer a browser warning about an executable file being accessed. It's an instant display of the PDF in the browser. This is a bit different I agree (I use FF). However, his page gives sufficient information the download will be calling Adobe's reader.

How browser's treat links will differ depending on the browser, OS and personal settings.

#9 yannis

yannis

    Sonic Boom Member

  • 1000 Post Club
  • 1634 posts

Posted 02 January 2008 - 01:05 PM

I downloaded the report and is very informative. If you have been around these forums there is not much that you shouldn't have encountered before, but nevertheless having actual people with disabilities describe the problems they encounter is valuable in itself.

Some of the recommendations which I haven't been implementing I would put into use immediately (such as the LONGDESC attribute. I remember we had a discussion about it sometime back (sorry I couldn't find it) and I used it for a while and then dropped it as I thought the browser support was not there yet. However, from what I understand it is quiet possible that some screen readers already use it.

One item that he was silent about was using ALT="", that is an empty ALT attribute for images that would add nothing to the meaning of the page. My own understanding is that screen readers such as Jaws just skip these. Another comment I have about images - also couldn't see anything in the report about this - is the use of background images rather than <IMG> for 'design' images. Screen readers do not read background info i.e since it is in the CSS file.

Last comment is he was also silent about validation. (His download page has over 20 validation errors and has been designed using tables). IMHO validation is important as a bad (X)HTML structure can throw screen readers out.

However, this is a great report and to be honest although somewhat dated should be a required read for anyone involved with web development.


Yannis

PS Also amazing is the money he charges to create a report for a site! Probably 50K by now!

#10 iamlost

iamlost

    The Wind Master

  • Admin - Top Level
  • 4457 posts

Posted 02 January 2008 - 03:38 PM

It is an old (2001) study but the suggested practices are still largely valid. Regrettably many of the latest (2007) sites, especially those based on an out-of-the-box CMS, fail as horribly as any in the study.

This is also an example of serial marketing - take an old but still valid study that due to age likely has few current buyers, add advertising/links for other reports and events, and offer it up as a free download. Nothing to lose. Much to gain: enhanced reputation and print/web mentions from something that paid for itself long ago all while trolling for new customers. Nice.

What I always find amazing is the significant number of control, i.e. 'normal', users who fail tasks:
* 10% (2 of 20) were unable to finish in time allotted.
* 40% (8 of 20) quit trying (out of frustration).
To my mind this 50% failure rate by 'normals' is far more critical than whatever might be the handicapped rate. And it was glossed over because the study is not about the control group. I noticed this when I first read the study. After paying for it. Ah well, being years ahead of the competition is priceless. I think an ad told me so.

There are several ways of looking at this:
1. NN/g selected an extremely lazy dumb control group.
2. the average user actually is quite lazy and rather dumb.
3. NN/g selected extremely badly done sites.
4. the average website is designed to fail.
5. a site should be usable by all the 'normal' visitors before worrying about those with handicaps.
6. a site designed to be usable by those with handicaps will also be found usable by 'normal' visitors.

I tend to believe 2, 4, and 6.
Also that when best practices become normal practice success is more easily found.

#11 AbleReach

AbleReach

    Peacekeeper Administrator

  • Admin - Top Level
  • 6457 posts

Posted 02 January 2008 - 09:41 PM

Some of the recommendations which I haven't been implementing I would put into use immediately (such as the LONGDESC attribute. I remember we had a discussion about it sometime back (sorry I couldn't find it) and I used it for a while and then dropped it as I thought the browser support was not there yet. However, from what I understand it is quiet possible that some screen readers already use it.

I've developed an opinion that if longdesc is needed to understand a page the real problem is not enough descriptive text on that page.

The clincher for me was the site for a large blindness organization. They have two versions of their site - one with pictures and one for screen readers. The screen reader version has more information, real descriptive text. The with-pictures version assumes that images provide much more information than they do. The with-pictures version might have a picture of a hallway with a brief caption "children in the hallway" or "approaching the orientation center." The text version might say something like "Upon entering the south door of our campus the visitor is greeted by the happy sound of children exploring tactile art on the hallway wall opposite the orientation center." I learned more about the organization by reading the text version. Separating them felt like an inference that the two versions and their audience should be separated because their needs are so different they can't live on the same page. That doesn't fly with me.

If the longdesc information adds in any way to understanding the page, I think it should be integrated within the text of that page. "Should" is vague, I know. So often online as in life, specific directives are tempting, but not entirely practical.

Also, though it doesn't pass muster with validators, I've gradually moved away from using the title attribute for anchors, IF the link text is the same as what I would use for the title attribute. If screen reader users have turned on the reading of titles and the link text is the same as the title, they hear repetition, not improved access to information.

Edited by AbleReach, 02 January 2008 - 09:42 PM.


#12 joedolson

joedolson

    Eyes Like Hawk Moderator

  • Technical Administrators
  • 2902 posts

Posted 03 January 2008 - 12:34 AM

Also, though it doesn't pass muster with validators, I've gradually moved away from using the title attribute for anchors, IF the link text is the same as what I would use for the title attribute. If screen reader users have turned on the reading of titles and the link text is the same as the title, they hear repetition, not improved access to information.


How does not using title attributes with anchors fail to pass validation?

I very rarely use title attributes on anchors for the very simple reason that I consider it to be better practice to use anchor text which is logical: title attributes should ONLY be provided if the information they add is important to understanding the context of the link.

And, following logically, if it's that important...why isn't it in the text already?

You're absolutely right about minimizing the use of title attributes --- I'm curious about what validators you're using which are troubled by this!

#13 AbleReach

AbleReach

    Peacekeeper Administrator

  • Admin - Top Level
  • 6457 posts

Posted 03 January 2008 - 02:04 AM

You're absolutely right about minimizing the use of title attributes --- I'm curious about what validators you're using which are troubled by this!


Bobby used to. Today's WebXact doesn't.
ATRC still does.

It's not about the error warning so much as it is about the intent behind the warning.

#14 Guest_Autocrat_*

Guest_Autocrat_*
  • Guests

Posted 03 January 2008 - 05:37 AM

...iamlost... 2/4/6... yup ... and don't forget 2.5, most visitors don't want to think.

It is interesting that the report has so many other things in it, yet they are generally ignored.
All in all, it is a rather handy list... but I cannot help but wonder just how applicable it all is considering things have moved on a little since then.

Interesting to see about the Title attribute.
Do you not use it to provide additional information, (not just on links)?
You don't include a very brief detail of what can be found on that page/section?
I don't view it as a tool for certain user types, but as a tool for everyone due to the tool-tip/pop-up that goes with it. I find adding a little extra details seems to be appreciated by some users, and it comes in handy for things like Forms etc.

#15 joedolson

joedolson

    Eyes Like Hawk Moderator

  • Technical Administrators
  • 2902 posts

Posted 03 January 2008 - 03:03 PM

Do you not use it to provide additional information, (not just on links)?
You don't include a very brief detail of what can be found on that page/section?


Occasionally, when I feel it's necessary. Personally, I find tool tips to be annoying: I prefer to not need them.

I simply see little reason to make use of an attribute which conceals the information unless they're a) using a mouse, B) using a screen reader with verbose title settings or c) examining the source code. If the additional information is critical, it should be on the page. If it's optional, I'd prefer NOT to provide it.

This isn't a carefully worked out and tested theory, however --- I don't know, from a user preference perspective, what might be generally preferred. However, I really dislike having things popping up all over the screen. There are worse things than title attributes as tooltips, though...

From WCAG 1.0:

1.1.1 TITLE: The document title.

Note that the (mandatory) TITLE element, which only appears once in a document, is different from the "title" attribute, which applies to almost every HTML 4.01 element. Content developers should use the "title" attribute in accordance with the HTML 4.01 specification. For example, "title" should be used with links to provide information about the target of the link.


6.1 Link text

Checkpoints in this section:

* 13.1 Clearly identify the target of each link. [Priority 2]

Good link text should not be overly general; don't use "click here." Not only is this phrase device-dependent (it implies a pointing device) it says nothing about what is to be found if the link if followed. Instead of "click here", link text should indicate the nature of the link target, as in "more information about sea lions" or "text-only version of this page". Note that for the latter case (and other format- or language-specific documents), content developers are encouraged to use content negotiation instead, so that users who prefer text versions will have them served automatically.

In addition to clear link text, content developers may specify a value of the "title" attribute that clearly and accurately describes the target of the link.

If more than one link on a page shares the same link text, all those links should point to the same resource. Such consistency will help page design as well as accessibility.

If two or more links refer to different targets but share the same link text, distinguish the links by specifying a different value for the "title" attribute of each A element.


In general, these specification only _require_ a title attribute in contexts where the link text is repeated. Better practice, of course, is to avoid link text which is repeated.

I will use the title attribute when I don't see another option: but if at all possible, I prefer to provide explanations, needed details, or descriptions in context.

The important thing, however, is to realize when you really must not use the title attribute: when you're duplicating link text, duplicating alt text, or creating any other type of content redundancy on the page.



RSS Feed

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users