AJAX and Screenreaders: When Can it Work?

[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!

[brothercake]

To me the conclusion of this article that AJAX does not change anything. Since AJAX is dependant on JavaScript, we have to stick with: "Only use JavaScript for embellishments, not for core functionality." I could not see anything in this article that had anything to do with AJAX itself, just problems that are already known about with DHTML. There are probably ways of using AJAX that do not update the display in this way, and they are probably okay. For example, Google Suggest barely uses the DOM at all, and only as an enhancement to the basic service, so (in my opinion) does not cause a problem.

Well yes and no

Yes, what we're talking about here is updates to the DOM, which may or not be specifically AJAX, they could be any kind of DOM scripting that changes the page; and by the same token, AJAX scripting may not change the page, and that's fine.

But AJAX is the buzzword, and is increasingly being used to refer to any DOM scripting which changes the page asynchronously, so it made sense to write the article in these terms - so it would get through, as it has

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.

[Majglow]

Yeah, what a bizarre concept that would be!

Are you for real?

Um, I am well aware of laws that apply to websites for federal agencies, however, my prior posts were all focused on business, and business decisions based on ROI. As I said in my first post "unless one would have a good reason to", which would cover working on federal agency sites. This is just a tiny set of websites on the internet. Now, if you could please refrain from the "Are you for real?" comments, I would appreciate it.

As the original article plainly stated, it would be quite difficult (impossible?) at this point to create a rich user interface.Sometimes, this rich UI is required to have the edge over competitors. The question I posed is, given limited resources, is it WORTH creating a whole second UI for people with these disabilities.

I believe this is quite a pertinent question. What market share do people utilizing screen readers take up? As one previous poster mentioned, it isn't only people with disabilities, but the group of everybody they have a relationship with. I still think this is a tiny group.

For example, a company has a web application already developed, but it doesn't support screen readers. They have some money for development. Do they a) create a new UI in order to support screen readers or b) translate the application into spanish.

Both options make the application available to another market share, however I have a feeling that the spanish speakers take up more of the market.

Another question might be, do they put the money into supporting screenreaders or do they put it into enhancing the current UI?

In order to really make an educated decision on this, one would have to be educated on the statistics of each different market.

[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.

[JVLB]

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!

[kyberfabrikken]

The question I posed is, given limited resources, is it WORTH creating a whole second UI for people with these disabilities.

Fair point, if we put the moral issues aside. Clearly there can be benefits to creating an application in such a way that it can degrade properly. Most notably of course, is that spiders and other "machine" users can access it. This includes regression-testing suites.
But generally if your application can degrade to a fully standard-compliant level, it means that you cover virtually all web minorities, which may together mass up to a large minority or even a majority in some cases.

[Buddy Bradley]

Um, I am well aware of laws that apply to websites for federal agencies, however, my prior posts were all focused on business, and business decisions based on ROI. As I said in my first post "unless one would have a good reason to", which would cover working on federal agency sites. This is just a tiny set of websites on the internet.

From your comments I'm assuming you're based in the US (I can't tell from your location description) - here in the UK, there is a legal requirement that websites (all websites, not just government ones) have to be accessible, so your comment about there being no legal imperative is nonsense.

I thought there was also some clause in the ADA that covered non-federal sites as well - what legislation are Target being sued under?

[Majglow]

From your comments I'm assuming you're based in the US (I can't tell from your location description) - here in the UK, there is a legal requirement that websites (all websites, not just government ones) have to be accessible, so your comment about there being no legal imperative is nonsense.

Are you saying that any person in the UK that creates a website has to make it accessible to the disabled? How is accessible defined in this legislation?

I thought there was also some clause in the ADA that covered non-federal sites as well - what legislation are Target being sued under?

I looked into it and Target is being sued under laws that have nothing to do with the internet. It'll be interesting to see what happens. I am no lawyer, so I can't say, but I have a feeling it'll come down to interpretation of the law.

[Buddy Bradley]

Are you saying that any person in the UK that creates a website has to make it accessible to the disabled?

Not quite - anyone providing 'services' has to ensure that the manner in which those services are accessed does not discriminate against people with disabilities. This includes websites, including websites that just provide content (as this is a service).

How is accessible defined in this legislation?

The legislation (DDA) does not define accessibility, it would be up to the courts to establish whether a website owner was in breach of their legal obligations in that respect.

[Hal9k]

Good article highlighting--I guess--what a lot of us would find more convenient to overlook.

Oh and thumbs up to the "in the dark" article graphic.

[Michael]

Honestly, how many people really care about accessibility? Before you answer, think about it.

[xris_s]

The legal case I remember seeing was about a blind user who couldn't book a flight using a screen reader. Im not sure how the case unfolded though.

Disability discrimination is lumped into racial, and sex discrimination. Its not a business decision.

Whats wrong with this....?

"Best viewed by a)Male a)white anglo-saxon c)sighted people"

So did you have a sharp intake of breath at a), b) and/or C) ????

[Enoch Root]

>So did you have a sharp intake of breath at a), b) and/or C) ????

Not b), certainly - there wasn't one. :-)

[JVLB]

Honestly, how many people really care about accessibility?

I hate to be the one to have to break this to you, but, honestly, the answer is: Vast, vast numbers more than care about your opinion.

Plato: "Opinion is greater than ignorance but less than knowledge."

[commontags]

James, about the Modified Second Test, who at least works well for Jaws:
what about adding a "back to the point you were before" mechanism?
I mean, when the user is redirected to the updated content, js could generate a temporary anchor in the place he was before, and then he could be asked after reading the new content if he wants to return to that place (so, the temporary anchor would be removed). Would this approach works in Jaws?

Regarding the subsequent debate:
In Italy the public sector has a big role in the IT market. So, most of the main web agencies are heavily involved in developing products for public companies.
Since the last August a very discussed law (the so called "legge Stanca", from the name of the IT minister who has signed it) has defined a set of mandatory and severe requirements regarding accessibility of public (or public-involved) web sites, far more restrictive than Section 508 (see http://www.pubbliaccesso.gov.it/bibl...tudy/index.htm).

So, here's the business value, in this context: wouldn't your agency be able to re-use part of the solutions already developed for previous customers? If a significant part of your customers are under strong requirements of accessibility, it becomes economic for you to develop accessibility-aware solutions by default, even for private clients.

I'm following with interest the english evolution of the accessibility laws.
Anyway, I must sadly report that, regarding the impact in Italy of all those efforts:
1) The italian law substantially define no consequences at all for those infringing it, and is anyway designed to minimize any risk for those trying to walk around the requirements, who are so badly written to result ineffective (if you can read italian, I've collepted a long list of objections from the italian community of accessibility experts: http://commontags.com/test/domandecnipa01.rtf);
2) There hasn't been any significative impact of this law on the level of accessibility of italian public sites. This could be, anyway, due to the fact that no italian law has, historically, have been impact on the way people do things :-(

[Mpdreamz]

Just as we developers should provoke Browser fabricants to be 100% standard compliant i feel we should also force them to support AJAX perfectly. Browsers that dont support these are just bad browsers, if we stop supporting bad browsers users of those bad browsers will notice the browser their using is holding them back.
As for screen notifying theres loads of ways they can be notified using javascript animations and sounds even.

I dont agree with your conclusion that AJAX updates cant be silent. Lets not forget AJAX prime goal is to lose Postback and let your webapps run more silently.

[brothercake]

Browsers that dont support these are just bad browsers, if we stop supporting bad browsers users of those bad browsers will notice the browser their using is holding them back.

Rrright, and always assuming that they're technically literate users who know exactly what component has failed (rather than, as is usually the case, averagely technical users who only know whether "it works" or not), what then do they do? What if (as in the case of JAWS 7) they're already using the latest, most technically advanced version of their device, and it cost them £1,000 to upgrade?

Sure, vendors should and we hope will rise to this challenge, but we can't just pass the buck and say it's all up to them.

As for screen notifying theres loads of ways they can be notified using javascript animations and sounds even.

For example ...?

[brothercake]

what about adding a "back to the point you were before" mechanism?
I mean, when the user is redirected to the updated content, js could generate a temporary anchor in the place he was before, and then he could be asked after reading the new content if he wants to return to that place (so, the temporary anchor would be removed). Would this approach works in Jaws?

Yes I think it would. If the reader can reliably get the updated content (as was sometimes the case ... for some versions!) then that kind of approach would work very well. It could probably be designed into a central "updates" area, which contains information about the last thing or few things that happened, and then had a dynamic # link back to where the user was before.

But when it comes to moving focus around ... I've had trouble in JAWS with that before as well - like, you send the focus to a link, and it doesn't go to that link, it goes to some spurious other part of the page that's nowhere near it. This is shown in some of the JAWS results where it reads a heading again instead of the response text.

nb - I've seen a couple of other interesting discussions going on elsewhere on this topic at the moment:

http://www.brucelawson.co.uk/index.p...en-technology/
http://www.webstandards.org/2006/05/...d-of-the-dark/

[Mark]

Why aren't screen readers more advanced in general. Given the legal obligations for equal access, especially in the pubic sector, there should be a big driver for screen readers to be more advanced in terms of what features they support (iframes, AJAX etc).

Just my 2 cents

[Sander]

So then, if the support of screenreaders of this technology is this imperfect, can we reliably test for Ajax-capability as we test for other javascript functionality?

If this is possible we can reliably point non-capable browsing devices to the non-javascript fallback code, and assume that because they told us they are ajax-capable the other browsers can handle it.

Whether they then mess up is because of their implementation which is based on lies, not really the fault of the web developer?

(in an ideal world)

[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.

[Sander]

Ah maybe you slightly misunderstood my intention. I don't propose "testing for screenreaders", I was quering about if we can test for "ajax feature support", similarly to the testing of support for document.getElementById before we use it. If we can say: if the device tells us they do not support this and this feature, we better skip the rest of the script and present the traditional content (with form submit), then there wouldn't be any additional accessibility issue at all. We already test with javascript disabled. It would just simplify the situation.

[cloosley]

I hardly think ...

This may be the problem.

[brothercake]

I was quering about if we can test for "ajax feature support", similarly to the testing of support for document.getElementById before we use it.

Testing for feature support is as unreliable as any other kind of test. This is just the problem - the reader does support it, because the browser supports it, but its users can't actually use it.