AJAX and Screenreaders: When Can it Work?

[ArticleBot]

This is an article discussion thread for discussing the SitePoint article, "AJAX and Screenreaders: When Can it Work?"

[Majglow]

This was quite an interesting article and answered a lot of questions.

However, these leaves the question slightly addressed towards the end of the article. Unless one has a good reason, why try to make applications accessible? How big of a market share does the group consisting of people using screenreaders to browse the internet have? Even making a JS disabled version of the application seems like an awful lot of trouble to go through for development groups with low resources. Judging from the statistics gathered on the collection of sites I run that don't have any AJAX or anything fancy, 98%+ of the users would be able to browse AJAX enabled sites.

If I had an extra $x to devote to development, wouldn't it make more sense to spend it make more revenue from the 98% group than from the tiny 2%?

[foofoonet]

Well lets imagine we have to create a SR friendly version becuase the law says we have to, and its the right and responsible thing to do...

So, is there a way of detecting that a SR is viewing the page?

(no JS is quite simple, create a noscript-ed hyperlink... I guess)

Is it back to browser sniffers to redirect to the POST (non-AJAX) version?

Nice article BTW

[JVLB]

Perhaps testing for the implementation of the CSS property "speak" through either the implementation property or the supports() method would offer some utility, though some ambiguity would remain as to whether the particular user was actually using the functionality.

On a more hopeful note, from what I've read about the HTML 5 initiative, it may offer some relief in the future. Then again, maybe coding for Lynx is the answer.

[brothercake]

A real problem with getting accessibility issues to be taken more seriously, is that it's being viewed in terms of cost/benefit; as Joe Clark has recently said, accessibility is being viewed as a "feature" -- http://joeclark.org/ice/iceweb2006-notes.html

But it's not a feature, and it's not okay to think of it in terms of metrics. If we all did that, then no services would be accessible at all, because people with disabilities will probably always be in the minority.

And now, because so many people do think like that, the law has no choice but to step in and say "you must do this". I don't like that at all, but what's the option? As long as people view access in terms of their own convenience, rather than the convenience of the people who actually need help, this dichotomy will persist.

<steps down from soapbox>

Re: JavaScript detection: screenreaders don't expose themselves to the language, except in the very specific case of Home Page Reader 3.04, which has "navigator.IBM_HPR". In fact detecting a screenreader is very difficult, almost impossible; the only way I know of is by inference - by careful analysis of the events reported by different devices compared with their host browser, it is possible after some manual interaction to infer that a user is probably using a screenreader. But it's a real hack, and something you'd only use in emergencies; it's not really a go-er.

Have a look here for more raw data on which such inferences can be based - http://www.access-matters.com/index/...ascript-tests/


RE: Speak support / aural CSS - none of the tested devices support aural CSS. It's funny actually .. a screen reader is a "screen" reader, not a "text" or "source" reader - it's designed to provide information about the visible screen that would otherwise not be available to someone who's blind - so in a sense it's perfectly correct that its media type should be "screen" and not "aural".

Opera + Voice supports aural CSS, but its intention is different. It's designed to provide additional speech input and output for someone who's not (or not completely) blind - it helps more with cognitive and motor disabilities, or low vision, and isn't a screenreader in the same sense at all, as it isn't useable if you're completely blind.

But there is a Linux screenreader called Emacspeak which supports aural CSS, though that's all I know - just the name!

[JVLB]

Originally Posted by brothercake

Re: JavaScript detection: screenreaders don't expose themselves to the language . . .

Okay, so in other words screen readers are inaccessible to developers. Let's sue!

[foofoonet]

As to using scripting only for enhancement, well - how do you do that? How do you know that your script isn't breaking the interface for some people, or that your non-script alternative is getting to the people who need it? This is the point of the article - progressive enhancement fails this group of users, because as far as a script can tell, the device can handle it; yet actually it can't.

Well how about the equivalent of a reverse CAPTCHA? "If you can see this image, click now for updates." How about we make all the sighted people positively identify themselves? If the image isnt clicked within 10 seconds then redirect (eek) to the POST friendly version?

Dont shoot me, its just an off the cuff observation - really I want to try and find a way round this.

Against the law? the Australian Olympic Committee got fined AU$20,000 in 2000 for discriminating against a partially sighted man, in the UK so far similar parties have settled "out of court"... if you are running a .gov.uk website, you risk losing your domain if it isnt accessible to all, so yes, we had better find a way round it.

[brothercake]

We can't reliably test for screenreaders; we can infer their use after an amount of interaction has taken place by reference to the differences in what events are generated, but that's not really reliable - it's a precarious hack.

But it's not really fair to say that screenreaders are "lying". Put the shoe on the other foot - why should a screenreader announce its presence? The purpose of the the device is to open up inaccessible material to someone who would otherwise not be able to use it; it's a retrospective device analogous to a search robot, the job of which is to extract and convey meaningful content from an unpredictable source. The last thing a device like that needs is for the source to start second-guessing the reader - that leads to a vicious circle like we have with search-engine optimisation, so in one sense it's far better that the source content doesn't know who the reader is, and has no means of knowing, so that the reader can feel confident it's starting from the same baseline as everybody else.

Except of course, we know with hindsight that that's not realistic either; clearly the optimum is a point somewhere between the two - it's a transaction. So we do need to know about devices in order to give them content they can handle, and devices need to trust content authors more not to abuse the privelege of knowing who they are.

(But you can't exactly blame device manufacturers for being reticent in that respect ...)


I also don't think it's fair to say that readers are "broken" for not already supporting this stuff. I mean in real terms, how long has ajax been around? The blink of an eye ... things take time, and most of the world is not so caught up in the hype as to care about this technology over and above what it can actually do for us.

[Buddy Bradley]

Some more information on the subject: Making AJAX Work With Screenreaders by Gez Lemon and Steve Faulkner:

...we explain the fundamental issues; how to inform users of assistive technology that a change has taken place, and how they can interact with the content.

[deisgni]

I enjoy these type of articles. Thank you.
_
Dizionario dei sogni
Dream dictionary

[jashua01]

It’s interesting to read ideas, and observations from someone else’s point of view… makes you think more.
So please keep up the great work.Greetings...

NBA | Dj Tiesto | Adsense | Alonzo Mourning