accessibile sites "must work in non-javascript browsers
[redux] split from http://www.accessifyforum.com/viewtopic.php?t=3149 [/redux]
Not working in older browsers isn't accessibility problem that web designers should concern themselves about, particulary when technological solutions are widely available.
Interestingly enough, the typical screen reader supports Ajax applications quite nicely.
| Richard Conyard wrote: |
| Use of XHTTPRequest objects might also cause difficulties for older browsers. |
Not working in older browsers isn't accessibility problem that web designers should concern themselves about, particulary when technological solutions are widely available.
Interestingly enough, the typical screen reader supports Ajax applications quite nicely.
| TOOLman wrote: |
| If you rely on 'ajax' your page is not fully accessibly, since not all user agents support JavaScript. |
No. That is not a good reason why Ajax applications are not fully accessible, especially when people have options to upgrade their hardware and software that does support JavaScript and XmlHttpRequest.
What makes the typical Ajax application inaccessible is the current problem of not being able to notify the user of a change has been made to the document. JavaScript can be done in an accessible way.
Accessibility, again, it needs to be stressed, first and foremost is about people. If people chose to use incompatible software, whilst there are compatible options available, that is their choice, not an accessibility obstacle.
| Isofarro wrote: | ||
Not working in older browsers isn't accessibility problem that web designers should concern themselves about, particulary when technological solutions are widely available. Interestingly enough, the typical screen reader supports Ajax applications quite nicely. |
You're right it's not an accessibility problem. It is something that should be kept in mind when designing though.
I for one would love it if I had the luxury of being able to turn around and say that everyone that browses or manages a website that my company produces has to use this browser, on this platform, with this resolution, with this security set-up, with this bandwidth available, etc. It would save us a hell of a lot of time with testing. Unfortunately the web's not like that.
| Isofarro wrote: |
| Interestingly enough, the typical screen reader supports Ajax applications quite nicely. |
No it doesn't
We debated this a while ago, and there are no easy answers -- http://www.accessifyforum.com/viewtopic.php?t=2660
Give it time - over the next couple of years, we and others will hopefully develop accessible AJAX techniques - but for this moment in time, be very very careful with what you do with it.
| brothercake wrote: | ||
No it doesn't |
Its how the dynamic update of the content is done that's the source of the problem. That's the same type of problem as hidden/unhidden content. In some cases that problem is solvable - most particularly when the Ajax update is done as a response to a human-generated event - e.g. clicking a link.
Yes, doesn't immediately solve the problem of an automated frequently updated page - a consistent method of informing of changes and being able to "skip link" to those changes is, IMO, part of the solution.
| Quote: |
| We debated this a while ago, and there are no easy answers -- http://www.accessifyforum.com/viewtopic.php?t=2660
Give it time - over the next couple of years, we and others will hopefully develop accessible AJAX techniques - but for this moment in time, be very very careful with what you do with it. |
There's a couple of conversations going on about bringing modern unobtrusive JavaScript to the fore - accessible JavaScript is on that agenda , including accessible Ajax applications.:
* http://www.boxofchocolates.ca/archives/2005/06/12/javascript-and-accessibility
(feather and I were both at the JavaScript meetup arranged by PPK).
| Isofarro wrote: | ||
No. That is not a good reason why Ajax applications are not fully accessible, especially when people have options to upgrade their hardware and software that does support JavaScript and XmlHttpRequest. |
You and I have very different definitions of the term 'accessibility' then. Can you tell me where I go to download a version of Lynx that supports 'ajax'? I'm on dial-up and I do not have the option to upgrade my hardware to broadband. Or are you saying that only city slickers should have the right to access the Internet?
IMNSHO, no page that relies on a client-side scripting technique can claim to be fully accessible.
Tommy has left the building
| TOOLman wrote: |
| IMNSHO, no page that relies on a client-side scripting technique can claim to be fully accessible. |
NSH indeed
But the problems with RPC applications are far more complex than whether a user does/doesn't support javascript - we have to consider users who *do* support the scripting, but nonetheless can't use the interface, for any of a number of complex and difficult-to-address reasons.
Man .. if we could just rely on everyone who couldn't use the application having Javascript turned off ... that would be easy as pie. But of course we can't - we can't make firm assertions in either direction - and that's the difficulty.
| TOOLman wrote: |
|
You and I have very different definitions of the term 'accessibility' then. Can you tell me where I go to download a version of Lynx that supports 'ajax'? |
Firstly, why is Lynx the only choice of browser you have available?
| Quote: |
| I'm on dial-up and I do not have the option to upgrade my hardware to broadband. Or are you saying that only city slickers should have the right to access the Internet? |
None of the above are accessibility problems, nor even classed as a disability under any legislation I've seen.
| Isofarro wrote: |
| None of the above are accessibility problems, nor even classed as a disability under any legislation I've seen. |
I don't think you will find legislation (although I have seen a few documents on UK Gov guidelines for browser support), that sets a specific accessible speed or browser platform.
I think what is comes down to it the term accessible. IMHO an accessible website is a site that can be "viewed" by the broadest range of readers and still make sense. To do this standards are useful (WAI, PAS, (x)HTML, ECMA), but there are other considerations such as browser compatibility, speed, ease of use, etc. that don't sit neatly into standards but still effect the accessibility of a site.
| Isofarro wrote: | ||||
Firstly, why is Lynx the only choice of browser you have available?
None of the above are accessibility problems, nor even classed as a disability under any legislation I've seen. |
whilst they are not disability problems, the are accessibility problems but some times i have to do without a phoneline
| Richard Conyard wrote: |
| IMHO an accessible website is a site that can be "viewed" by the broadest range of readers and still make sense. |
Accessibility is about people. Hardware and software are incidental.
| Isofarro wrote: | ||
Accessibility is about people. Hardware and software are incidental. |
I have to disagree, but you're welcome to your opinion.
| Richard Conyard wrote: | ||||
I have to disagree, but you're welcome to your opinion. |
You are effectively disagreeing with WCAG1.0, WCAG2.0 as well as a range of notable experts in the field of web accessibility.
No, I'm not. WCAG, WAI etc. are essential to accessibility.
The Cambridge defines something that is accessible as the following:
So if I am on a slow internet connection and I am on a site that requires large bandwidth that site is in effect inaccessible to me.
If I am at work and I have the security locked down on my machine and am running firefox and the site requires IE that site is in effect inaccessible to me.
There is no point running through further examples, the that I am trying to make is in my opinion (I am not saying it is the only opinion or that I am 100% right), accessibility is more than just adhering to the guidelines. The guidelines are a useful step in becoming accessible, but there are other factors like Toolman mentioned that should also be taken into account.
The Cambridge defines something that is accessible as the following:
| Cambridge Dictionary wrote: |
| accessible
adjective 1 able to be reached or easily obtained: The resort is easily accessible by road, rail and air. The problem with some of these drugs is that they are so very accessible. 2 easy to understand: Lea Anderson is a choreographer who believes in making dance accessible. Covent Garden has made some attempt to make opera accessible to a wider public. |
So if I am on a slow internet connection and I am on a site that requires large bandwidth that site is in effect inaccessible to me.
If I am at work and I have the security locked down on my machine and am running firefox and the site requires IE that site is in effect inaccessible to me.
There is no point running through further examples, the that I am trying to make is in my opinion (I am not saying it is the only opinion or that I am 100% right), accessibility is more than just adhering to the guidelines. The guidelines are a useful step in becoming accessible, but there are other factors like Toolman mentioned that should also be taken into account.
| Richard Conyard wrote: |
| No, I'm not. WCAG, WAI etc. are essential to accessibility.
The Cambridge defines something that is accessible as the following: |
You put your trust the Cambridge dictionary on the definition of a technical area of web development? *ROTFL* Take this definition of "markup" from the exact same place:
| Quote: |
| Definition
mark-up [Show phonetics] noun [C] the amount by which the price of something is increased before it is sold again: The usual mark-up on clothes is about 20 percent. |
*lol*


