DHTML/AJAX accessibility

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

DHTML/AJAX accessibility

Aaron Leventhal-3
DHTML/AJAX accessibility:

As the web moves forward we're seeing it move away from documents and
forms into a richer, more dynamic application space. The dynamic
techniques have been around for a while but are just now becoming really
popular because they can lead to extremely compelling user experiences.
These applications combine the best of both the web and desktop software
metaphors, and in turn are being enabled by web browsers such as Firefox
with better support for standards like CSS.

While exciting, this new environment is cause for concern because it can
lock out users with visual and motor impairments. As such, it cannot be
adopted by major institutions because of legal concerns. Can
accessibility be addressed? In fact it can. Firefox 1.5 is the first web
browser that has enabled a newly emerging W3C standard that enables
desktop-style keyboartd navigation and compatibility with 3rd party
assistive technologies.

If you're interested in learning more, take a look at
http://www.mozilla.org/access/dhtml
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: DHTML/AJAX accessibility

Doc-7
Pardon me for whatever posting sins I'm making but
I think that among the many possible contributions perhaps this might help.

In short the problem with MSAA or whatever is that it does not work well
with DOM.

In the end what DHTML does is not any much different than what
the HTML did , except it is done post page load and can be in continuous
flux. Of course the fact that some things that happen in browsers have
no OS equivalent control does not help the screen readers either.

Given the number of browsers that might exist and attempting to
vector these dynamic happenings into a consistent stream that
JAWS or other AT's can lock onto would seem to suggest that
the solution needs to be somewhat global in nature and not require
the co-operation of a specific platform or browser.

So the thought is that the AT would need to function in part as a proxy
server,
so that it could have access to the incoming http streams. With this
access it could
inject a reference to a pseudo javascript file.

This xBrowser javascript file is where the magic can occur
with various event insertions via prototype that would notify the clever
script
of anything that happened in DHTML the clever script then uses
an element known to generate AT friendly messages and
suddenly AT vendors have a known target to lock onto regardless of browser
that receives messages from the javascript that their AT injected via proxy.

Not to say that there is not a lot of coding to be done there, but
it does give a fairly strong lock on DHTML happenings , putting
the authors of AT software back into a familiar terrain of trap and vector.



Aaron Leventhal wrote:

> DHTML/AJAX accessibility:
>
> As the web moves forward we're seeing it move away from documents and
> forms into a richer, more dynamic application space. The dynamic
> techniques have been around for a while but are just now becoming
> really popular because they can lead to extremely compelling user
> experiences. These applications combine the best of both the web and
> desktop software metaphors, and in turn are being enabled by web
> browsers such as Firefox with better support for standards like CSS.
>
> While exciting, this new environment is cause for concern because it
> can lock out users with visual and motor impairments. As such, it
> cannot be adopted by major institutions because of legal concerns. Can
> accessibility be addressed? In fact it can. Firefox 1.5 is the first
> web browser that has enabled a newly emerging W3C standard that
> enables desktop-style keyboartd navigation and compatibility with 3rd
> party assistive technologies.
>
> If you're interested in learning more, take a look at
> http://www.mozilla.org/access/dhtml
> _______________________________________________
> dev-accessibility mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-accessibility
>

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: DHTML/AJAX accessibility

Aaron Leventhal-3
In reply to this post by Aaron Leventhal-3
Doc,

 > In the end what DHTML does is not any much different than what
 > the HTML did, except it is done post page load and can be in
 > continuous flux.

There's more to the problem than that. Authors use DHTML to simulate
widgets that don't exist in HTML, such as menus.

Take a look at http://www.mozilla.org/access/dhtml

- Aaron

Doc wrote:

> Pardon me for whatever posting sins I'm making but
> I think that among the many possible contributions perhaps this might help.
>
> In short the problem with MSAA or whatever is that it does not work well
> with DOM.
>
> In the end what DHTML does is not any much different than what
> the HTML did , except it is done post page load and can be in continuous
> flux. Of course the fact that some things that happen in browsers have
> no OS equivalent control does not help the screen readers either.
>
> Given the number of browsers that might exist and attempting to
> vector these dynamic happenings into a consistent stream that
> JAWS or other AT's can lock onto would seem to suggest that
> the solution needs to be somewhat global in nature and not require
> the co-operation of a specific platform or browser.
>
> So the thought is that the AT would need to function in part as a proxy
> server,
> so that it could have access to the incoming http streams. With this
> access it could
> inject a reference to a pseudo javascript file.
>
> This xBrowser javascript file is where the magic can occur
> with various event insertions via prototype that would notify the clever
> script
> of anything that happened in DHTML the clever script then uses
> an element known to generate AT friendly messages and
> suddenly AT vendors have a known target to lock onto regardless of browser
> that receives messages from the javascript that their AT injected via
> proxy.
>
> Not to say that there is not a lot of coding to be done there, but
> it does give a fairly strong lock on DHTML happenings , putting
> the authors of AT software back into a familiar terrain of trap and vector.
>
>
>
> Aaron Leventhal wrote:
>> DHTML/AJAX accessibility:
>>
>> As the web moves forward we're seeing it move away from documents and
>> forms into a richer, more dynamic application space. The dynamic
>> techniques have been around for a while but are just now becoming
>> really popular because they can lead to extremely compelling user
>> experiences. These applications combine the best of both the web and
>> desktop software metaphors, and in turn are being enabled by web
>> browsers such as Firefox with better support for standards like CSS.
>>
>> While exciting, this new environment is cause for concern because it
>> can lock out users with visual and motor impairments. As such, it
>> cannot be adopted by major institutions because of legal concerns. Can
>> accessibility be addressed? In fact it can. Firefox 1.5 is the first
>> web browser that has enabled a newly emerging W3C standard that
>> enables desktop-style keyboartd navigation and compatibility with 3rd
>> party assistive technologies.
>>
>> If you're interested in learning more, take a look at
>> http://www.mozilla.org/access/dhtml
>> _______________________________________________
>> dev-accessibility mailing list
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-accessibility
>>
>
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: DHTML/AJAX accessibility

Doc-7
Hi Aron

At least in the instance of menus,  the fact that I and so many others
have had to create these
things in javascript sorta begs the question of why there never was one
afforded via HTML.

That being said , making a page work for a screen reader is a
cooperative effort
between the author and the technologies at hand. As with images , you
can provide
opportunities for the author to describe the image , but they do have to
use them.

You really can't force folks to use these features , but if the browser
did something
interesting with the information that made the authors work "look"
better than
one would see more use of descriptive attributes.

In the case of DHTML there really is currently no defined mechanism to
describe what one is doing with it, so any such descriptive information
would need
to be pro actively plumbed through an object that could be seen by AT's

I've had some luck using the javascript prototype to superclass existing
controls
allowing me to tie DHTML widgets to the tab order and to relay events
through an existing
form element. In fact one of my current projects involves using
javascript to
augment form elements with DHTML ui widgets to reflect all the X-Schema
data types.

A variation of this approach packaged as a freely available javascript  
could
be an avenue for navigation and description.

I would think though that this would need to be paired with a big non-AT
centric carrot
to motivate developers in general and to to justify it to those holding
the developmental purse strings.

Probably the biggest motivator for folks to use the alt attribute in
images and such was not
the concern they had for the AT community , but the cool little pop up
bubble that displays the text.

The trick would be to make AT support a byproduct of something
considered useful or cool
in it's own right.


 




Aaron Leventhal wrote:

> Doc,
>
> > In the end what DHTML does is not any much different than what
> > the HTML did, except it is done post page load and can be in
> > continuous flux.
>
> There's more to the problem than that. Authors use DHTML to simulate
> widgets that don't exist in HTML, such as menus.
>
> Take a look at http://www.mozilla.org/access/dhtml
>
> - Aaron
>
> Doc wrote:
>> Pardon me for whatever posting sins I'm making but
>> I think that among the many possible contributions perhaps this might
>> help.
>>
>> In short the problem with MSAA or whatever is that it does not work
>> well with DOM.
>>
>> In the end what DHTML does is not any much different than what
>> the HTML did , except it is done post page load and can be in continuous
>> flux. Of course the fact that some things that happen in browsers have
>> no OS equivalent control does not help the screen readers either.
>>
>> Given the number of browsers that might exist and attempting to
>> vector these dynamic happenings into a consistent stream that
>> JAWS or other AT's can lock onto would seem to suggest that
>> the solution needs to be somewhat global in nature and not require
>> the co-operation of a specific platform or browser.
>>
>> So the thought is that the AT would need to function in part as a
>> proxy server,
>> so that it could have access to the incoming http streams. With this
>> access it could
>> inject a reference to a pseudo javascript file.
>>
>> This xBrowser javascript file is where the magic can occur
>> with various event insertions via prototype that would notify the
>> clever script
>> of anything that happened in DHTML the clever script then uses
>> an element known to generate AT friendly messages and
>> suddenly AT vendors have a known target to lock onto regardless of
>> browser
>> that receives messages from the javascript that their AT injected via
>> proxy.
>>
>> Not to say that there is not a lot of coding to be done there, but
>> it does give a fairly strong lock on DHTML happenings , putting
>> the authors of AT software back into a familiar terrain of trap and
>> vector.
>>
>>
>>
>> Aaron Leventhal wrote:
>>> DHTML/AJAX accessibility:
>>>
>>> As the web moves forward we're seeing it move away from documents
>>> and forms into a richer, more dynamic application space. The dynamic
>>> techniques have been around for a while but are just now becoming
>>> really popular because they can lead to extremely compelling user
>>> experiences. These applications combine the best of both the web and
>>> desktop software metaphors, and in turn are being enabled by web
>>> browsers such as Firefox with better support for standards like CSS.
>>>
>>> While exciting, this new environment is cause for concern because it
>>> can lock out users with visual and motor impairments. As such, it
>>> cannot be adopted by major institutions because of legal concerns.
>>> Can accessibility be addressed? In fact it can. Firefox 1.5 is the
>>> first web browser that has enabled a newly emerging W3C standard
>>> that enables desktop-style keyboartd navigation and compatibility
>>> with 3rd party assistive technologies.
>>>
>>> If you're interested in learning more, take a look at
>>> http://www.mozilla.org/access/dhtml
>>> _______________________________________________
>>> dev-accessibility mailing list
>>> [hidden email]
>>> https://lists.mozilla.org/listinfo/dev-accessibility
>>>
>>
>

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: DHTML/AJAX accessibility

Aaron Leventhal
Doc wrote:
> Hi Aron
>
> At least in the instance of menus,  the fact that I and so many others
> have had to create these
> things in javascript sorta begs the question of why there never was
> one afforded via HTML.
Exactly. Couldn't agree more. Same goes for other widgets like tree
views and tab panels.

>
> That being said , making a page work for a screen reader is a
> cooperative effort
> between the author and the technologies at hand. As with images , you
> can provide
> opportunities for the author to describe the image , but they do have
> to use them.
Not sure what you mean -- the screen readers do make use of alt text.
>
> You really can't force folks to use these features , but if the
> browser did something
> interesting with the information that made the authors work "look"
> better than
> one would see more use of descriptive attributes.
We have screen reader support for the DHTML a11y techniques I described
for Firefox1.5
>
> In the case of DHTML there really is currently no defined mechanism to
> describe what one is doing with it, so any such descriptive
> information would need
> to be pro actively plumbed through an object that could be seen by AT's
Not sure what you mean -- there is a mechanism now -- see
http://www.mozilla.org/access/dhtml

> I've had some luck using the javascript prototype to superclass
> existing controls
> allowing me to tie DHTML widgets to the tab order and to relay events
> through an existing
> form element. In fact one of my current projects involves using
> javascript to
> augment form elements with DHTML ui widgets to reflect all the
> X-Schema data types.
>
> A variation of this approach packaged as a freely available
> javascript  could
> be an avenue for navigation and description.
>
> I would think though that this would need to be paired with a big
> non-AT centric carrot
> to motivate developers in general and to to justify it to those
> holding the developmental purse strings.
>
> Probably the biggest motivator for folks to use the alt attribute in
> images and such was not
> the concern they had for the AT community , but the cool little pop up
> bubble that displays the text.
>
> The trick would be to make AT support a byproduct of something
> considered useful or cool
> in it's own right.
Ah, true. I wish we had new HTML widgets, but we dont' yet. See
whatwg.org for that kind of thing. It will be a while before we get
there through browser support. For one thing, pages need to work in
older/current browsers.

On the bright side there are open source JS toolkits like Dojo and
Zimbra. I want to see the DHTML accessibility techniques added to those
toolkits. Authors that use will get cool widgets, plus a11y "for free".

>
>
>
>
>
>
>
> Aaron Leventhal wrote:
>> Doc,
>>
>> > In the end what DHTML does is not any much different than what
>> > the HTML did, except it is done post page load and can be in
>> > continuous flux.
>>
>> There's more to the problem than that. Authors use DHTML to simulate
>> widgets that don't exist in HTML, such as menus.
>>
>> Take a look at http://www.mozilla.org/access/dhtml
>>
>> - Aaron
>>
>> Doc wrote:
>>> Pardon me for whatever posting sins I'm making but
>>> I think that among the many possible contributions perhaps this
>>> might help.
>>>
>>> In short the problem with MSAA or whatever is that it does not work
>>> well with DOM.
>>>
>>> In the end what DHTML does is not any much different than what
>>> the HTML did , except it is done post page load and can be in
>>> continuous
>>> flux. Of course the fact that some things that happen in browsers have
>>> no OS equivalent control does not help the screen readers either.
>>>
>>> Given the number of browsers that might exist and attempting to
>>> vector these dynamic happenings into a consistent stream that
>>> JAWS or other AT's can lock onto would seem to suggest that
>>> the solution needs to be somewhat global in nature and not require
>>> the co-operation of a specific platform or browser.
>>>
>>> So the thought is that the AT would need to function in part as a
>>> proxy server,
>>> so that it could have access to the incoming http streams. With this
>>> access it could
>>> inject a reference to a pseudo javascript file.
>>>
>>> This xBrowser javascript file is where the magic can occur
>>> with various event insertions via prototype that would notify the
>>> clever script
>>> of anything that happened in DHTML the clever script then uses
>>> an element known to generate AT friendly messages and
>>> suddenly AT vendors have a known target to lock onto regardless of
>>> browser
>>> that receives messages from the javascript that their AT injected
>>> via proxy.
>>>
>>> Not to say that there is not a lot of coding to be done there, but
>>> it does give a fairly strong lock on DHTML happenings , putting
>>> the authors of AT software back into a familiar terrain of trap and
>>> vector.
>>>
>>>
>>>
>>> Aaron Leventhal wrote:
>>>> DHTML/AJAX accessibility:
>>>>
>>>> As the web moves forward we're seeing it move away from documents
>>>> and forms into a richer, more dynamic application space. The
>>>> dynamic techniques have been around for a while but are just now
>>>> becoming really popular because they can lead to extremely
>>>> compelling user experiences. These applications combine the best of
>>>> both the web and desktop software metaphors, and in turn are being
>>>> enabled by web browsers such as Firefox with better support for
>>>> standards like CSS.
>>>>
>>>> While exciting, this new environment is cause for concern because
>>>> it can lock out users with visual and motor impairments. As such,
>>>> it cannot be adopted by major institutions because of legal
>>>> concerns. Can accessibility be addressed? In fact it can. Firefox
>>>> 1.5 is the first web browser that has enabled a newly emerging W3C
>>>> standard that enables desktop-style keyboartd navigation and
>>>> compatibility with 3rd party assistive technologies.
>>>>
>>>> If you're interested in learning more, take a look at
>>>> http://www.mozilla.org/access/dhtml
>>>> _______________________________________________
>>>> dev-accessibility mailing list
>>>> [hidden email]
>>>> https://lists.mozilla.org/listinfo/dev-accessibility
>>>>
>>>
>>
>
> _______________________________________________
> dev-accessibility mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-accessibility
>
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: DHTML/AJAX accessibility

Doc-7
Aaron Leventhal wrote:

> Doc wrote:
>> At least in the instance of menus,  the fact that I and so many
>> others have had to create these
>> things in javascript sorta begs the question of why there never was
>> one afforded via HTML.
> Exactly. Couldn't agree more. Same goes for other widgets like tree
> views and tab panels.
>
>> That being said , making a page work for a screen reader is a
>> cooperative effort
>> between the author and the technologies at hand. As with images , you
>> can provide
>> opportunities for the author to describe the image , but they do have
>> to use them.
> Not sure what you mean -- the screen readers do make use of alt text.
Yes the readers can read alt text them , but only if the page author
uses such attributes

>> You really can't force folks to use these features , but if the
>> browser did something
>> interesting with the information that made the authors work "look"
>> better than
>> one would see more use of descriptive attributes.
> We have screen reader support for the DHTML a11y techniques I
> described for Firefox1.5
>>
>> In the case of DHTML there really is currently no defined mechanism to
>> describe what one is doing with it, so any such descriptive
>> information would need
>> to be pro actively plumbed through an object that could be seen by AT's
> Not sure what you mean -- there is a mechanism now -- see
> http://www.mozilla.org/access/dhtml
Well, when it becomes generally supported in the browsers at large it
will be of great  value. I always have hopes that the future of browsers
holds ever more
possibilities.

>> I've had some luck using the javascript prototype to superclass
>> existing controls
>> allowing me to tie DHTML widgets to the tab order and to relay events
>> through an existing
>> form element. In fact one of my current projects involves using
>> javascript to
>> augment form elements with DHTML ui widgets to reflect all the
>> X-Schema data types.
>>
>> A variation of this approach packaged as a freely available
>> javascript  could
>> be an avenue for navigation and description.
>>
>> I would think though that this would need to be paired with a big
>> non-AT centric carrot
>> to motivate developers in general and to to justify it to those
>> holding the developmental purse strings.
>>
>> Probably the biggest motivator for folks to use the alt attribute in
>> images and such was not
>> the concern they had for the AT community , but the cool little pop
>> up bubble that displays the text.
>>
>> The trick would be to make AT support a byproduct of something
>> considered useful or cool
>> in it's own right.
> Ah, true. I wish we had new HTML widgets, but we dont' yet. See
> whatwg.org for that kind of thing. It will be a while before we get
> there through browser support. For one thing, pages need to work in
> older/current browsers.
>
> On the bright side there are open source JS toolkits like Dojo and
> Zimbra. I want to see the DHTML accessibility techniques added to
> those toolkits. Authors that use will get cool widgets, plus a11y "for
> free".
The trick as I see it is to provide the DHTML/AT support from  an
xbrowser context
using what the current crop of browsers can collectively support.

I think it would be one thing to include a script in my projects that
provided
passive and elective facilities to augment my DHTML activities with AT
support,
but I don't think I would fancy having to build my project around such a
library,
much less having to recode existing libraries.

It's again akin to the alt attribute. I can go through an existing page
and quickly add the
the alt text attribute and such w/o tearing into the structure of the page.

Likewise a useful AT augment would allow me to go through existing code
with about as much effort as the alt attribute in HTML adding  AT vectoring

A useful tool might be something one could include like the google maps api





_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: DHTML/AJAX accessibility

Joe Walker
In reply to this post by Aaron Leventhal
On 4/26/06, Aaron Leventhal <[hidden email]> wrote:
>
> ...  On the bright side there are open source JS toolkits like Dojo and
>
Zimbra. I want to see the DHTML accessibility techniques added to those
> toolkits. Authors that use will get cool widgets, plus a11y "for free".


Which is exactly why I'm here.

I'm the lead dev. for DWR (http://getahead.ltd.uk/dwr/) which is one of the
most used Java/Ajax toolkits (that's my intro by the way).

I want to add features to DWR to ensure that however visually fancy it gets,
it is still clear and audible, but so far I've not found a simple way to
tell a browser that DWR has just changed section of a page yet.

Joe.
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: DHTML/AJAX accessibility

Aaron Leventhal
Do you want the new section to be automatically spoken?

We have something called DHTML alerts, which causes that section of a
page to be spoken

There are some other tricks as well. Email me at let me know what you
want to do.

- Aaron


Joe Walker wrote:

> On 4/26/06, Aaron Leventhal <[hidden email]> wrote:
>  
>> ...  On the bright side there are open source JS toolkits like Dojo and
>>
>>    
> Zimbra. I want to see the DHTML accessibility techniques added to those
>  
>> toolkits. Authors that use will get cool widgets, plus a11y "for free".
>>    
>
>
> Which is exactly why I'm here.
>
> I'm the lead dev. for DWR (http://getahead.ltd.uk/dwr/) which is one of the
> most used Java/Ajax toolkits (that's my intro by the way).
>
> I want to add features to DWR to ensure that however visually fancy it gets,
> it is still clear and audible, but so far I've not found a simple way to
> tell a browser that DWR has just changed section of a page yet.
>
> Joe.
> _______________________________________________
> dev-accessibility mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-accessibility
>
>  
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility