WebAIM has just published the preliminary results of a survey of screen reader users. With over 1,100 respondents — among whom over 1,000 used a screen reader due to a disability — the survey shows promise of revealing an interesting and valuable perspective on the practical usage of screen readers among disabled populations.

Obviously, no survey is perfect — but observing the overall scope of responses can effectively expose some aspects of screen reader usage.

In fact, the preliminary results evidence a number of interesting conclusions. Among the statistics are indications that screen reader and web site evaluators who do not have a disability sometimes have a very disparate idea of what is more accessible than those with disabilities — an issue possibly connected to the evaluator’s lack of sophisticated familiarity with the screen readers.

It’s not altogether surprising that we in the web accessibility industry do not always choose the path which is actually most preferred — our impressions are necessarily biased by our own understanding of the technology, our presumptions of what is sufficient information, and our lack of ability to fully ignore the visual input we do receive.

That’s what makes this survey so particularly valuable: it begins to expose the difference between common misconceptions of what is accessible and those which are truly of benefit.

In the evidence in this study are included indications that disabled users would prefer that photos which are part of a page should be fully identified: as a photograph, and as the object depicted. There are indications that while site maps may be valuable, they are not in fact widely used by disabled users. There are indications that on-site search and navigation by headings are two of the most important navigation methods on a site for the disabled.

And, unsurprisingly, there’s fairly definitive confirmation that Flash is difficult for the disabled to use.

Nonetheless, the conclusions drawn from this information aren’t really that simple. With Flash, for example: the problem with Flash is almost certainly that the Flash web sites visited were not designed with accessibility in mind. Flash can be used accessibly, but in 9 cases out of 10 (a number I’m making up for hyperbolic purposes) it’s been developed with no regard whatsoever for accessibility issues. So the issue is not precisely with Flash — rather, the problem is with Flash developers.

The preliminary observations from this survey are well worth reading; and I’m definitely looking forward to seeing further analysis of the results.

Thank you, WebAIM!

Thanks to an off-hand comment from Steve Green while discussing a forthcoming Accessites article, I’ve spent some time today thinking about what it takes to write for accessibility.

Most of the time, the primary focus of information about accessibility has to do with making non-text information available as text. Captioning and audio description for video, transcriptions for audio, simple text alternatives for static images. Next in the list tends to be availability of functionality: progressive enhancement for client-side scripting, ability to navigate the page via skip links or semantic HTML headings, and so on.

But what about the content itself?

Disregarding issues concerning the use of abbreviations, typography, headings, and other semantic structures in HTML, the simple use of punctuation can be a significant barrier. This is a problem which applies to all text content for any user of a screen reader, in particular, although following these suggestions will benefit any reader of your content.

The issue isn’t precisely correctness. A sentence can be punctuated with perfect correctness but still lose clarity when spoken by a screen reader. It’s a matter of the lack of refinement in screen reader voice interpretation.

As a human speaker or writer, aware of the meaning and context of a sentence, it’s easy to speak a sentence and convey the meaning you expect in that sentence. A slight emphasis on one word or another is highly significant. However, in HTML, as in normal writing, there’s no means to indicate this kind of special emphasis which is readily understood by current screen reader technology. As important as strong and emphasis are semantically, they are not interpreted meaningfully by screen readers.

Punctuation is left as the sole means to refine and polish the meaning of a sentence for screen readers.

How do screen readers use punctuation?

Screen readers read most punctuation by default, such as parentheses, dashes, asterisks, and so on, but not all screen readers choose to read the same pieces of punctuation. Some do not read asterisks by default, for example. Periods, commas, and colons are usually not read out loud, but screen readers generally pause after each. Users can set their preferences so that screen readers read every punctuation mark and character. Web AIM, “Designing for Screen Reader Compatibility”

So common sentence punctuation marks, such as periods and commas, are indicated by pauses. However, special punctuation, including dashes and parentheses, are read as characters. This should immediately tell you how difficult it could be to understand a sentence containing numerous subclauses or parenthetical statements!

Only a few years ago, it was common to see pages that explained quote this page best viewed in Internet Explorer quote left paren or Netscape right paren. Web AIM, “Designing for Screen Reader Compatibility”, as rendered by Fangs

Although this is a relatively simple example, containing a single quoted passage and a single parenthetical statement, it could readily be very confusing to follow a more convoluted sentence structure, regardless of the correctness of the sentence.

So what’s the solution? Simply speaking, to write simply. Keep your sentences on the short side, avoid excessive parenthetical statements, and avoid excessive subclauses. Above all, try reading the sentence without giving any particular emphasis to the terms and see how easy it is to understand the statement. It’s easy to write an ambiguous sentence if you’ve assumed it will be pronounced in a particular manner.

Ultimately, the expectations when writing with a screen reader in mind aren’t that hugely different than without. After all, it’s not as if you intend to write confusing and ambiguous statements. However, the line drawn between “confusing” and “clear” is not necessarily in the same place for a computerized reader.

“WebAnywhere” is a new screen reading product (available in May of 2008) from the University of Washington and the WebInSight project. The basic concept is simple: it’s a web-based service which provides a proxy service as a screen reader. Fantastic tool for anybody requiring a screen reader at a computer which they don’t control: at a public library, a friend’s house, or any imaginable situation where your normal setup isn’t available.

The project is designed with minimal requirements, and is supposed to be usable from any web-enabled device with a sound card.

On top of that, the software is open-source and available through Google Code.

It’s impossible to say at this point how the user interface and power available to the screen reader will compare to a mainstream screen reader. Will this be a usable tool for web developers to use as a testing device, for example?

The project information is available at the WebInsight project page. The principle feature is a demonstration video, showing the basic use and value of the service.

There’s no information available concerning the features of the service beyond a few comments during the video concerning keyboard shortcuts. I’m looking forward to seeing the service and discovering what tools and features it provides.