Accessibility

I've been talking with a friend of mine that is involved with Section 508.
I have been reading about percieved issues with Section 508 accessibility
and developing ajax style applications. I have read percieved problems with
ajax style applications. does anyone have any experience in this area and
what info can you share?

Wally

Any web application that modifies the DOM dynamically faces a few accessibility challenges.

For example, it's not easy to tell the screen reader that parts of the display changed. Some screen readers and browsers will actually cache parts of the page, which makes it almost impossible to get the updated display to be read. We're actively working on this problem.

The postback situation of non-Ajax application is actually not much better as the screen reader is faced with a completely new page all the time and it's difficult for the user to figure out what he needs to re-read.

Keyboard accessibility can actually be made much better by using a framework like Atlas. For example, the listView and itemView controls are keyboard accessible by default and behave like their Windows equivalents as much as possible. Unfortunately, this only works on IE for the moment. We're working on Firefox 1.5 support (other browsers for the moment don't have the necessary infrastructure).

All in all, I'd say that accessibility problems are only starting to get solved on the Web (Firefox only included accessibility features in version 1.5, which is only a few weeks old, and Safari to this day still ignores the issue). There are some cases where the Atlas framework can actually make things much better, but we'll also need improvements in browser and screen reader technology.

Bertrand,

Thanks for the info! :-)

I have had a discussion with Freedom Scientific, the makers of JAWS, about
accessibility with Atlas. They said that JAWS will use what they call
"forms mode." when working with forms. In forms mode, JAWS does not cache
the page. I put together a very small sample at
http://216.187.235.116/atlassection508test/. Some blind friends of mine at
the US Government looked through the application and felt that things were
find. If you have any suggestions regarding things to do, I would love to
hear them.

Wally

wrote in message news:1153749@.66.129.67.202...
> Any web application that modifies the DOM dynamically faces a few
> accessibility challenges.
>
> For example, it's not easy to tell the screen reader that parts of the
> display changed. Some screen readers and browsers will actually cache
> parts of the page, which makes it almost impossible to get the updated
> display to be read. We're actively working on this problem.
>
> The postback situation of non-Ajax application is actually not much better
> as the screen reader is faced with a completely new page all the time and
> it's difficult for the user to figure out what he needs to re-read.
>
> Keyboard accessibility can actually be made much better by using a
> framework like Atlas. For example, the listView and itemView controls are
> keyboard accessible by default and behave like their Windows equivalents
> as much as possible. Unfortunately, this only works on IE for the moment.
> We're working on Firefox 1.5 support (other browsers for the moment don't
> have the necessary infrastructure).
>
> All in all, I'd say that accessibility problems are only starting to get
> solved on the Web (Firefox only included accessibility features in version
> 1.5, which is only a few weeks old, and Safari to this day still ignores
> the issue). There are some cases where the Atlas framework can actually
> make things much better, but we'll also need improvements in browser and
> screen reader technology.
>

That is very interesting information. We're still figuring all this out. I'd also say that with any Web technology, an application that cares about accessibility should be structured differently, more hierarchically, with shorter screens that present less information units at a time.

About Jaws, did your contact mention how to switch to forms mode? Is it something that needs to be enforced by the screen reader authors or something that the page itself can suggest through markup? Is it just triggered by the presence of form fields on the page (because if that's the case I think I have a bug report for them...)?