Gentlebeings,
I have read a depressing and recent article suggesting that DOM manipulations are invisible to most screen readers [1]. There are some workarounds suggested in [2], but for the most part it looks like dangerous territory.
What's worse, there seems to be no way to detect screen readers reliably. I am determined to provide some JavaScript in the 'standard' interface, as it will make for enhanced ease-of-use for those sighted people using a modern browser.
(I think it would be good for screen readers, too, if there was just some way for me to control/hint the "focus" of the screen reader, but at the moment there doesn't seem to be. Screen readers don't even seem to support an aural/speech stylesheet, much less provide some JavaScript object that lets me know I'm in one.)
I found a page (that is eluding me at the moment) detailing a method for showing content to screen readers yet hiding it from 'regular' clients. I was thinking of adding a "Screen Reader Support On" link to the top of all pages that would only show to screen readers; does this seem like a good approach?
Note that this would be in *addition* to the ability to get a JS-free version of the interface by using a different URL prefix for any user agent that doesn't want the JS action.
~ethan
Ethan wrote:
Note that this would be in *addition* to the ability to get a JS-free version of the interface by using a different URL prefix for any user agent that doesn't want the JS action.
Speaking only for myself, this is not the kind of approach I'd like to see used. I'd prefer to see the web application auto-detect that JavaScript is not available, and therefore to automatically present the appropriate non-JavaScript interface. Likewise, it should auto-detect that there is a screen reader being used, and present the appropriate screen reader compatible interface.
Of course, the manual options should always be there, but if we're forcing the user to manually select a different page in order to get away from the JavaScript stuff, then I think we're doing something wrong.
Brad Knowles wrote:
Speaking only for myself, this is not the kind of approach I'd like to see used. I'd prefer to see the web application auto-detect that JavaScript is not available, and therefore to automatically present the appropriate non-JavaScript interface.
I will do this for browsers not employing JavaScript. Screen readers employ JavaScript and provide no indication what they do/do not provide feedback to the user for.
Likewise, it should auto-detect that there is a screen reader being used, and present the appropriate screen reader compatible interface.
This is an admirable goal. One "screen reader" in semi-common use is IE 6 via Jaws; another one is Safari with OS X reading turned on.
They present to me no handle, user-agent or otherwise, indicating they're being spoken rather than seen.
Of course, the manual options should always be there, but if we're forcing the user to manually select a different page in order to get away from the JavaScript stuff, then I think we're doing something wrong.
I agree that it is an Ugly Hack; In this case I think the screen readers are misbehaved, but there's not a lot I can do about that.
~ethan fremen
emf wrote:
Likewise, it should auto-detect that there is a screen reader being used, and present the appropriate screen reader compatible interface.
This is an admirable goal. One "screen reader" in semi-common use is IE 6 via Jaws; another one is Safari with OS X reading turned on.
er, I mean via window eyes; other web browsers can be used this way as well.
~ethan fremen
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Jul 4, 2006, at 2:06 PM, emf wrote:
Brad Knowles wrote:
Speaking only for myself, this is not the kind of approach I'd
like to see used. I'd prefer to see the web application auto-detect that
JavaScript is not available, and therefore to automatically present the
appropriate non-JavaScript interface.I will do this for browsers not employing JavaScript. Screen readers employ JavaScript and provide no indication what they do/do not
provide feedback to the user for.
Will this also work for browsers with JS enabled per-page, a la the
Firefox NoScript extension? I use that to control which sites I
allow JS on, and while I generally would enable it (and cookies) for
most Mailman sites, I could definitely see others disabling it.
As for the screen reader issue, well, you gotta work with what they
give you I guess.
- -Barry
Barry Warsaw wrote:
I will do this for browsers not employing JavaScript. Screen readers employ JavaScript and provide no indication what they do/do not provide feedback to the user for.
Will this also work for browsers with JS enabled per-page, a la the Firefox NoScript extension? I use that to control which sites I allow JS on, and while I generally would enable it (and cookies) for most Mailman sites, I could definitely see others disabling it.
I also do this with Firefox, and an equivalent for Safari (using PithHelmet). I would generally turn on JavaScript for those sites I consider to be "safe", such as the mail.python.org or any other Mailman site I help administer, but I can certainly see that others might not feel the same way.
emf wrote:
Gentlebeings,
I have read a depressing and recent article suggesting that DOM manipulations are invisible to most screen readers [1]. There are some workarounds suggested in [2], but for the most part it looks like dangerous territory.
Silly me, I didn't include the links.
[1] http://www.sitepoint.com/article/ajax-screenreaders-work [2] http://juicystudio.com/article/making-ajax-work-with-screen-readers.php
~ethan
participants (3)
-
Barry Warsaw -
Brad Knowles -
emf