E-mail List Archives
Thread: Ajax
Number of posts in this thread: 10 (In chronological order)
From: smithj7
Date: Sat, Oct 07 2006 12:10PM
Subject: Ajax
No previous message | Next message →
I'm a humble web person who works for division in a large agency (Blind Services, DOE) that SHOULD have the answers on accessiblity. I'm way below the learning curve. But we (myself the alledge coding expert, and MIS manager who is a programmer as well as a Jaws user whom Freedom Scientific periodically attempts to take from our agency) are working with a great group of folks making a web application using visual basic. They are trying to do it right the first time. One of the main issue is how to handle forms validation. They wanted to use AJAX cause of problems with the ASP validation and am going to recommended strongly Ajax is not the way to go. But I will need to explain why. (next email is about alternatives) I understand the javascript issue, the browers issues with XMLHttpRequest object (or similar), but even after reading w3 on what is DOM I don't know how to explain the DOM issue. In one of the articles it says: There doesn't appear to be any reliable way to no
tify screen readers of an update in the DOM.
>From my understanding screen readers can read DOM, if I understand what DOM is. I am writing up my negative recommendation on using AJAX with referrals to other sites including the ones listed below. But I don't have a grasp of the why. I saw it not work, user I highly compent JAWS user, so I know it didn't read update info.
Articles read and will recommend.
http://webaim.org/techniques/ajax/ (and links)
http://www.sitepoint.com/article/ajax-screenreaders-work
http://www.standards-schmandards.com/index.php?2005/03/01/16-ajax-and-accessibility
Any info on the why will help me help people that want to make their application accessible. Note: Please don't be shy if you think Ajax is not problemetic to accessiblity. I have mainly made this determination by reading articles on the net. I feel there are better alternatives.
From: Tim Beadle
Date: Mon, Oct 09 2006 3:20AM
Subject: Re: Ajax
← Previous message | Next message →
On 07/10/06, smithj7 < = EMAIL ADDRESS REMOVED = > wrote:
> Any info on the why will help me help people that want to make their application
> accessible. Note: Please don't be shy if you think Ajax is not problemetic to
> accessiblity. I have mainly made this determination by reading articles on the net. I feel
> there are better alternatives.
Have a look at Jeremy Keith's (author of DOM Scripting: Web Design
with JavaScript and the Document Object Model, pub. by Friends of Ed)
Hijax manifesto/blog post:
http://domscripting.com/blog/display/41
Ajax, like Flash, is only bad if done badly. It can be done well, with
progressive enhancement to ensure that it still works with javascript
turned off. I know there's a problem with screen readers not
understanding DOM/partial page updates, but (apparently) that's a
problem with any behavioural javascript, not just Ajax (which
specifically refers to grabbing data remotely from a server and using
it to update the page, using javascript).
I found this, too:
"AJAX is a great tool for creating rich internet applications,
however, when improperly implemented it can cause huge accessibility
issues. The good news is that most of these issues can be fixed so
your websites are viewable by a much wider audience. Great resources
on accessibility have been around for years, however, many web 2.0 and
AJAX websites ignore all of the research that went into turning
website accessibility into a movement followed by most professional
web developers. Below you'll find a list of 40 best AJAX accessibility
tutorials and articles that I have found on the web in the last year."
http://www.maxkiesler.com/index.php/weblog/comments/how_to_make_your_ajax_applications_accessible/
Best regards,
Tim
From: John Foliot
Date: Mon, Oct 09 2006 3:00PM
Subject: Re: Ajax
← Previous message | Next message →
smithj7 wrote:
> They wanted to use AJAX cause of problems with the ASP validation and
> am going to recommended strongly Ajax is not the way to go. But I
> will need to explain why.
There are a number of reasons why using an *AJAX only* solutions is a recipe
for problems. Based on some internal discussions and coincidental timing:
10 "Must Read" articles on AJAX, Accessibility and Web 2 technology
- http://soap.stanford.edu/show.php?contentid=65
JF
---
John Foliot
Academic Technology Specialist
Stanford Online Accessibility Program
http://soap.stanford.edu
Stanford University
560 Escondido Mall
Meyer Library 181
Stanford, CA 94305-3093
From: Alastair Campbell
Date: Tue, Oct 10 2006 3:50AM
Subject: Re: Ajax
← Previous message | Next message →
> There are a number of reasons why using an *AJAX only*
> solutions is a recipe for problems.
Assuming you went with the Hijax method (as Tim mentioned:
http://domscripting.com/blog/display/41) and provided an obvious option
to turn off the 'advanced' features, would there be any accessibility
issues there?
I've tested James Edwards AJAX test cases with recent versions of JAWs
and Voiceover with good results (a few caveats), so things are
improving.
Kind regards,
-Alastair
--
Alastair Campbell | Director of User Experience
Nomensa Email Disclaimer:
http://www.nomensa.com/email-disclaimer.html
From: John Foliot
Date: Tue, Oct 10 2006 9:30AM
Subject: Re: Ajax
← Previous message | Next message →
Alastair Campbell wrote:
>
> Assuming you went with the Hijax method (as Tim mentioned:
> http://domscripting.com/blog/display/41) and provided an obvious
> option to turn off the 'advanced' features, would there be any
> accessibility issues there?
Hijax currently seems to be the "Best Practice" answer for times when AJAX
is *needed* [1], and the need for an "obvious" option to turn off the
advanced feature is obviously important.
I suspect however that the bigger issue/requirement is that the AJAX widget
simply degrades gracefully without the requirement of the end user to
indicate "turn it off". Often, it may not even be an issue of turning
something On or Off, as Robert Nyman discovered one day
[http://soap.stanford.edu/show.php?contentid=65#ajax2]
>
> I've tested James Edwards AJAX test cases with recent versions of
> JAWs and Voiceover with good results (a few caveats), so things are
> improving.
>
And testing with various Adaptive Technologies is always important. But as
us "old fellers" are always reminding - this web accessibility thing is for
more than just the blind/visually impaired. Yes, AJAX appears particularly
vexing to the visually impaired, but it also impacts users of alternative
user-agents (our oft quoted "cell phones/PDA's"). And while "recent"
versions of AT are getting better at dealing with the sophisticated web
stuff that is tossed at them, what about users who are restrained from
up-grading their software? Again, a graceful fall-back is mandatory (IMHO).
Alastair, this discussion is important - AJAX isn't going away. You
mentioned that there are a few caveats based on your current testing - care
to share?
[1] "It appears to be the "must-have" technology at the moment, and a lot of
uses for it seem to be contrived. I do see a need for it, but its strength
is for web applications, rather than traditional web documents. It reminds
me a bit of when Flash first arrived on the scene, and everyone felt the
need to learn Flash in order to showcase their skills, with little regard to
the true usability of what they were doing." - Gez Lemon
Cheers!
JF
---
John Foliot
Academic Technology Specialist
Stanford Online Accessibility Program
http://soap.stanford.edu
Stanford University
560 Escondido Mall
Meyer Library 181
Stanford, CA 94305-3093
From: Alastair Campbell
Date: Tue, Oct 10 2006 10:10AM
Subject: Re: Ajax
← Previous message | Next message →
John Foliot wrote:
> I suspect however that the bigger issue/requirement is that
> the AJAX widget simply degrades gracefully without the
> requirement of the end user to indicate "turn it off".
> Often, it may not even be an issue of turning
> something On or Off, as Robert Nyman discovered one day
> [http://soap.stanford.edu/show.php?contentid=65#ajax2]
Presumably if the app works without JavaScript (i.e. unobtrusive/hijax)
then that situation (where the JavaScript was removed) should be fine?
> And testing with various Adaptive Technologies is always
> important. But as us "old fellers" are always reminding -
> this web accessibility thing is for
> more than just the blind/visually impaired.
No argument from me there, it's just that the issues for just about
everyone except screen reader users tend to be of the usability kind,
affecting *everyone* except maybe the technically gifted. With screen
readers, it can go from difficult to impossible, and a pretty clear
accessibility issue.
I assume there are also issues when things update away from the current
focus for people using screen magnifiers, are there any other common
issues?
> it also impacts users of alternative
> user-agents (our oft quoted "cell phones/PDA's").
Definitely, my old phone's browser choked so badly on JavaScript it
became unusable, and I couldn't turn it off.
However, I've been meaning to post about the webkit based browser (that
safari is built on), as my current phone has excellent JavaScript
support, I even managed drag and drop on my Google home page!
> You mentioned that there are a few caveats based on your
> current testing - care to share?
Sure, sorry for being cryptic. I need to gather together the JAWs
testing (i.e. talk to my colleague who completed it), I'll publish that
when I get the chance.
Using Voiceover (OSX), AJAX is not intrinsically difficult at all, the
changes within the page are updated and available to the user.
The first caveat is that updates via JavaScript aren't announced, and if
you click a link, you are often redirected to the top of the page as
though it had reloaded (although it hadn't). From that point, you can
then navigate and get to the updated content as though the page had
simply refreshed.
The second caveats are that within page links simply don't work in
Voiceover. The screen scrolls, but the cursor doesn't move (although one
person on the MacVisionaries list came up with a very impressive but
difficult workaround). One of Brothercake's tests worked as intended,
and a couple almost worked as intended (i.e. the text updated, was read
out and left the cursor there).
I'll write up the results when I get a chance.
Kind regards,
-Alastair
--
Alastair Campbell | Director of User Experience
Nomensa Email Disclaimer:
http://www.nomensa.com/email-disclaimer.html
From: smithj7
Date: Tue, Oct 10 2006 11:50AM
Subject: Re: Ajax
← Previous message | Next message →
I am very happy to hear of the on-going improvements. Things can only get
better when everyone works together to assure equal access.
At this point, I am still recommending not using AJAX. The target
population, for the most part, of this particular application will be people
working at the local level Florida school systems.
I work for the Florida state agencies that is the sole state agency that
provides services that assist people who are blind or severely visually
impaired get jobs. When we purchase their initial licenses for JAWS or
another speech software we include 3 free updates.
What we have consistently found is that even when other employee software is
updated (which is by the way lagging within state government, especially at
the local level), that people who are using the access technology's software
is NOT updated until they cannot access something. The person ends up
getting with our Mandersfield Technology Center or one of our district
offices when their job is jeoporized because the powers that be and often
the individual herself/himself does not realize that the problem is
technology based!
Access technology is still expensive, unlike some of the other accomodations
for people with disabilities. People and businesses need time to afford the
newest versions of the access technology. Users need to be able to have
time to learn how to use the newer versions of software technology.
Because technology is so rapidily developing, it seems that tech folks are
going to need to remember that users may still not have the means to have
the equal access only because they don't have the right tools, skills, or
time and money to assure that in happening. Does that make sense?
----- Original Message -----
From: "Alastair Campbell" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Tuesday, October 10, 2006 5:44 AM
Subject: Re: [WebAIM] Ajax
>> There are a number of reasons why using an *AJAX only*
>> solutions is a recipe for problems.
>
> Assuming you went with the Hijax method (as Tim mentioned:
> http://domscripting.com/blog/display/41) and provided an obvious option
> to turn off the 'advanced' features, would there be any accessibility
> issues there?
>
> I've tested James Edwards AJAX test cases with recent versions of JAWs
> and Voiceover with good results (a few caveats), so things are
> improving.
>
> Kind regards,
>
> -Alastair
>
> --
> Alastair Campbell | Director of User Experience
>
> Nomensa Email Disclaimer:
> http://www.nomensa.com/email-disclaimer.html
>
>
>
>
From: Hoffman, Allen
Date: Tue, Oct 10 2006 1:30PM
Subject: Re: Ajax
← Previous message | Next message →
see www.bindows.net.
From: smithj7
Date: Fri, Oct 13 2006 12:00AM
Subject: Re: Ajax
← Previous message | Next message →
This discussion was very helpful.
----- Original Message -----
From: "Alastair Campbell" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Tuesday, October 10, 2006 12:04 PM
Subject: Re: [WebAIM] Ajax
> John Foliot wrote:
>> I suspect however that the bigger issue/requirement is that
>> the AJAX widget simply degrades gracefully without the
>> requirement of the end user to indicate "turn it off".
>> Often, it may not even be an issue of turning
>> something On or Off, as Robert Nyman discovered one day
>> [http://soap.stanford.edu/show.php?contentid=65#ajax2]
>
> Presumably if the app works without JavaScript (i.e. unobtrusive/hijax)
> then that situation (where the JavaScript was removed) should be fine?
>
>> And testing with various Adaptive Technologies is always
>> important. But as us "old fellers" are always reminding -
>> this web accessibility thing is for
>> more than just the blind/visually impaired.
>
> No argument from me there, it's just that the issues for just about
> everyone except screen reader users tend to be of the usability kind,
> affecting *everyone* except maybe the technically gifted. With screen
> readers, it can go from difficult to impossible, and a pretty clear
> accessibility issue.
>
> I assume there are also issues when things update away from the current
> focus for people using screen magnifiers, are there any other common
> issues?
>
>> it also impacts users of alternative
>> user-agents (our oft quoted "cell phones/PDA's").
>
> Definitely, my old phone's browser choked so badly on JavaScript it
> became unusable, and I couldn't turn it off.
>
> However, I've been meaning to post about the webkit based browser (that
> safari is built on), as my current phone has excellent JavaScript
> support, I even managed drag and drop on my Google home page!
>
>> You mentioned that there are a few caveats based on your
>> current testing - care to share?
>
> Sure, sorry for being cryptic. I need to gather together the JAWs
> testing (i.e. talk to my colleague who completed it), I'll publish that
> when I get the chance.
>
> Using Voiceover (OSX), AJAX is not intrinsically difficult at all, the
> changes within the page are updated and available to the user.
>
> The first caveat is that updates via JavaScript aren't announced, and if
> you click a link, you are often redirected to the top of the page as
> though it had reloaded (although it hadn't). From that point, you can
> then navigate and get to the updated content as though the page had
> simply refreshed.
>
> The second caveats are that within page links simply don't work in
> Voiceover. The screen scrolls, but the cursor doesn't move (although one
> person on the MacVisionaries list came up with a very impressive but
> difficult workaround). One of Brothercake's tests worked as intended,
> and a couple almost worked as intended (i.e. the text updated, was read
> out and left the cursor there).
>
> I'll write up the results when I get a chance.
>
> Kind regards,
>
> -Alastair
>
> --
> Alastair Campbell | Director of User Experience
>
> Nomensa Email Disclaimer:
> http://www.nomensa.com/email-disclaimer.html
>
>
>
>
From: smithj7
Date: Fri, Oct 13 2006 12:50AM
Subject: Re: Ajax
← Previous message | No next message
I enjoyed trying out some of the tests... I wish there were more hours in a
day.
----- Original Message -----
From: "Hoffman, Allen" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Tuesday, October 10, 2006 3:26 PM
Subject: Re: [WebAIM] Ajax
> see www.bindows.net.
>
>
>
>
>