Theo Thank you for that great response, it was very helpful.
Ben On 6/19/07, skyeflye <[EMAIL PROTECTED]> wrote:
I don't disagree with any of the previous posters that the safest bet is to assume that if you are depending on AJAX or JavaScript for your app to function, it will probably not truly comply with the spirit of the "Section 508" accessibility standards. So if 508 compliance is a legal requirement for your app, then it is safest to make sure your app doesn't require any JS whatsoever (screen reader or not). I think that it is important to know that most "screen readers" are merely working in concert with an "off the shelf" web browser (usually IE or Safari from my experience). So the browsers are no different from the ones most people on this list probably use. There is just this extra set of tools called a "screen reader" that works with or "next to" the browser to help translate the web pages (and everything else in the operating system) into an audible medium. So "screen readers" are not really "browser" in and of themselves. In my experience (talking with low/no-vision users) many screen reader users will have disabled all JavaScript execution in their browsers because of all the bad code out there that manipulates focus, opens new windows, etc. without any user prompting. But if the user has not disabled JS in the browser they are using, then the web pages will load in the browser as normal. The experience that these users will have primarily depends on what screen reader product they are using and what the javascript is doing. Using a screen reader is like looking at the web page through a straw. You can only see one small part of the page at a time and you don't really know what's coming next, but as a user, you may remember what you encountered previously. Because of this, when using AJAX (or anything) that dynamically changes a portion of the DOM, controlling and clearly identifying browser's focus with clear audible cues is of primary importance. So, if you were to have a button that loaded in some content with a AJAX call, you might disable the UI and place focus on a "please wait" message. And when the DOM was done updating, you would switch the browser's focus to the beginning of the content that was loaded in and provide some sort of audible cue (perhaps inserted at the beginning of the loaded content that lets the user know "where" they are on the page. This can be as simple as an extra bit of text that is hidden from typical users using overflow:hidden and text-offset. Addressing the important issue of "focus" and clearly letting users know where they are within a given page is really the main usability issue. The main technical question becomes, is the screen reader product being used compatible with the browser product being used to the extent where the screen reader can update its "snapshot" of the browser's currently opened DOM whenever the DOM is dynamically updated with JS. That's a question I don't know the answer to. And that is why I create everything that needs to be 508 compliant in a way that does not require any JavaScript to function. This usually involves making any server-side scripts a bit more flexible. The jQuery Taconite plugin has been enormously helpful in this regard. But ideally, none of our web apps should neeeeed JS to function properly...right? Riiiiight? ;) Cheers, -THEO- On Jun 19, 12:18 pm, "Dan Eastwell" <[EMAIL PROTECTED]> wrote: > I tend to treat screenreaders as Javascript ignorers, but I know in > certain cases this isn't the case. I tend to build my sites as flat > HTML/CSS plus back-end technology and then add the event handlers, > additional buttons etc using scripting. I'd like to know if screen > readers are partially parsing the code and falling flat. It makes much > more sense to hand users a flat text page with additional contextual > headers and description that you then go on to hide for users who get > meaning by visual proximity for example. Hopefully that makes sense. > Thanks, Dan. > On 6/19/07, John Farrar <[EMAIL PROTECTED]> wrote: > > > > > > > My understanding is that with screen readers you need to treat the pages > > like there is no JS on the page. The jQuery modifications would not be > > compliant. (Thus technologies like EXT, again from my understanding, are > > not 508 compliant.) > > > Benjamin Sterling wrote: > > > Hey Guys and Gals, > > > I am doing some research on Ajax and 508 compliance and wanted to get > > > everyone's take on the issue. Does anyone have any experience with > > > getting screen readers to pick up on changes to the DOM? > > > > I am compiling a list of sites that discuss the issue, feel free to > > > see what I find:http://del.icio.us/kenzomedia/screenreaders > > > > I go to the Dept. of Ed in a few weeks to their accessibility > > > department, where the majority of the people that work there are blind > > > or def, to see/hear what some of the website look/sound to them. We > > > had two of our developers go a year ago and it was very eye opening to > > > them. > > > > -- > > > Benjamin Sterling > > >http://www.KenzoMedia.com > > >http://www.KenzoHosting.com > > -- > Daniel Eastwell > > Portfolio and articles:http://www.thoughtballoon.co.uk > > Blog:http://www.thoughtballoon.co.uk/blog
-- Benjamin Sterling http://www.KenzoMedia.com http://www.KenzoHosting.com
