Accessibility: February 2009 Archives

Disabled by Technology?

| | Comments (0)

When presenting accessibility issues to the "normally enabled", I think it helps to present scenarios when anyone could need the same accommodation as provided for "disabled" users.

For example...if you are on Adobe Connect and the audio is acting weird, you would really appreciate live captioning. I know I did when I attended an accessibility seminar over Adobe Connect. The audio was out for quite a while, but ironically they had included captioning for the hearing impaired audience, so I was set!

That was the seminar that mentioned that lots of students used captions when available - because of forgotten headphones, bad initial recording or they had a roommate sleeping in the next bunk.

This week I realized we had a new tech "disability" called the iPhone. The iPhone is great, but there's no denying that the screen real estate is much smaller than standard monitor. You have to zoom and move around the page a lot ...unless the site is designed to accomodate the iPhone.

Believe it or not the iPhone screen very closely mimics what a low vision user on 500% zoom is experiencing. Jakob Nielsen just conformed this in a recent Alertbox article on the Mobile Web. An interface designed to work for low vision users will probably be optimized for the iPhone.

It's possible to find tech scenarios for all sorts of "real" disabilities :

  • Requiring color-coding to be supplemented with shape helps if you only have a black and white printer.
  • ALT text for graphics is great when the graphic is slow to download...or missing.
  • Designing alternate to pop-up windows can help users who use pop-up blockers.

Accessibility can seem like a huge effort to accommodate only a small number of people, but when you realize that many "accommodations" can actually benefit many people beyond the target audience, it begins to seem much more reasonable.

Ordered Lists and CSS - Are we losing semantics?

| | Comments (4)

I'm about to question a pearl of standards/accessibility conventional wisdom and ask if we need to rethink how ordered lists are coded in terms of CSS. That is, are we putting too much semantic information in the CSS?

The standard mantra for ordered list OL standards is to use stylesheets to change list numbering types as in the examples below. Another is to make sure that nested lists change numbering schemes between levels to mark a change in list level.

Capital Alphabetical
Lower Roman
  1. Item 1
  2. Item 2
  3. Item 3
  1. Item A
  2. Item B
  3. Item C
  1. Item i
  2. Item ii
  3. Item iii

This is a change from the old days when you would specify numbering schemes and start points with embedded attributes (e.g. <list type="A"> if you wanted capital letters).

From a processing level it makes sense because all ordered lists are numbered lists in disguise. And since modern screen readers appear to recognize the new styles, it appears that a major hurdle is cleared.

On the other hand, this means that all numbering scheme information is in a CSS? That's fine...unless a user chooses to ignore your stylesheet and use a custom style sheet. Then the potential is for a nested listed with distinct numbering levels to become an inaccessible nested list using the same numbering scheme at all levels. Hmmm.

Nested List with CSS Nested List, CSS Disabled
  1. Top Level Item 1
    1. Second Level 1
    2. Second Level 2
      1. Third Level 1
      2. Third Level 2
  2. Top Level Item 2
  3. Top Level Item 3
  1. Top Level Item 1
    1. Second Level 1
    2. Second Level 2
      1. Third Level 1
      2. Third Level 2
  2. Top Level Item 2
  3. Top Level Item 3

I'm not sure how serious a problem this is, but it is a possible gotcha. The line between "presentation" and "semantics" can be a little fuzzy at times. Of course, if I want my Hebrew numbered lists, I have to rely on the new styles.

Postscript (Feb 13)

This issue is being discussed on one of the language tech list, and someone else made the same objection (I'm glad it's not just me).

WebAIM Screen Reader Usage Survey

| | Comments (0)

The WebAIM organization recently published results of a screen reader usage survey with 1121 responses.

I do have a summary below, but I recommend reading the WebAim results since they have their own interpretations to add.


1. The survey confirms the generalization that almost all screen reader users (mostly visually impaired) are on the Windows platform. The two most popular screen reader packages are Jaws (74%) and Window-Eyes (23%).

2. As might be expected, most prefer Internet Explorer (only 2/3 have upgraded to IE 7), but many are also willing to use Firefox.


1. About 3/4 of reader base used lists of header tags (e.g. Outline of H1,H2, etc) as a navigation device. Since header structure also improves search engine rankings, this is one of the most powerful tools in the Standards arsenal.

2. Users will look for a search function once they have skimmed the home page. Frighteningly, 61% just jump to the first form field and hope it's search. Site Maps are not widely used (although they are good for search engine rankings).

3. Skip links are used by a healthy percentage of the user base (38%), so may be worth implementing. When asked for a preference, most wanted "skip to content" instead of "skip navigation"

Which Technology is "Difficult"

  • Flash is considered "difficult" by 72% of respondants
  • Pop Up windows are "difficult" by 53% of respondants
  • PDF is labeled "difficult" by 48% of respondants
  • Frames are labeled "difficult" by only 27% of respondants

Labeling Images

1. Another surprise is that 59% do want "atmospheric" images described, but I suspect that context is important.

2. If a photo is of the "White House" it should be identified as "Photo of White House" (80%) instead of just "White House". Results are more mixed for logos.