Comments on: Assessing Accessibility (Part Two in a Trilogy) http://coffeeonthekeyboard.com/assessing-accessibility-part-two-in-a-trilogy-67/ Technical 2.0 Tue, 06 Jan 2009 03:38:23 +0000 http://wordpress.org/?v=2.7 hourly 1 By: James http://coffeeonthekeyboard.com/assessing-accessibility-part-two-in-a-trilogy-67/comment-page-1/#comment-28 James Mon, 04 Feb 2008 22:15:00 +0000 http://coffeeonthekeyboard.com/assessing-accessibility-part-two-in-a-trilogy-67/#comment-28 Ben,<br/><br/>You're right. What I really want is for people to use self-voicing (braille) browsers. (And I'd like them to pass an aural [braille] Acid2-type test.) But they don't, as you say. So we need to assume people are using JAWS or worse.<br/><br/>And in that case, I maintain a well-structured, linear HTML document with no "display" style sheet is the easiest to read.<br/><br/>I do like the Opera voice capabilities. I wish more people used them.<br/><br/>~james Ben,

You’re right. What I really want is for people to use self-voicing (braille) browsers. (And I’d like them to pass an aural [braille] Acid2-type test.) But they don’t, as you say. So we need to assume people are using JAWS or worse.

And in that case, I maintain a well-structured, linear HTML document with no “display” style sheet is the easiest to read.

I do like the Opera voice capabilities. I wish more people used them.

~james

]]> By: Benjamin Hawkes-Lewis http://coffeeonthekeyboard.com/assessing-accessibility-part-two-in-a-trilogy-67/comment-page-1/#comment-27 Benjamin Hawkes-Lewis Mon, 04 Feb 2008 21:45:00 +0000 http://coffeeonthekeyboard.com/assessing-accessibility-part-two-in-a-trilogy-67/#comment-27 Screen readers are tools that present a non-visual interface to applications: they aren't web browsers any more than they're word processors, email clients, or spreadsheet programs. It makes no more sense for a screen reader to parse a DOM than to dig into an Excel document, though in fact many screen readers are forced to query bits of the DOM via the accessibility APIs used and provided by browsers, due to the inadequacy of typical APIs to directly represent some of the subtleties of the web technology stack.<br/><br/>What you're talking about is more like a self-voicing (or self-brailling) browser that applies aural (or braille) CSS to its speech (or braille) output. Actively developed projects include the following:<br/><br/>1. <a HREF="http://www.opera.com/voice/index.dml" REL="nofollow">Opera can be turned into a self-voicing browser on Windows</a>.<br/><br/>2. <a HREF="http://emacspeak.sourceforge.net/" REL="nofollow">Emacspeak</a> turns Emacs and Emacs/W3 into a self-voicing environment.<br/><br/>3. The <a HREF="http://firevox.clcworld.net/" REL="nofollow">Fire Vox</a> add-on turns Firefox into a self-voicing browser.<br/><br/>All three solutions support some speech CSS. None of them are widely employed by users with visual impairments. Screen readers are tools that present a non-visual interface to applications: they aren’t web browsers any more than they’re word processors, email clients, or spreadsheet programs. It makes no more sense for a screen reader to parse a DOM than to dig into an Excel document, though in fact many screen readers are forced to query bits of the DOM via the accessibility APIs used and provided by browsers, due to the inadequacy of typical APIs to directly represent some of the subtleties of the web technology stack.

What you’re talking about is more like a self-voicing (or self-brailling) browser that applies aural (or braille) CSS to its speech (or braille) output. Actively developed projects include the following:

1. Opera can be turned into a self-voicing browser on Windows.

2. Emacspeak turns Emacs and Emacs/W3 into a self-voicing environment.

3. The Fire Vox add-on turns Firefox into a self-voicing browser.

All three solutions support some speech CSS. None of them are widely employed by users with visual impairments.

]]>