How changes in visibility are dealt with

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

How changes in visibility are dealt with

Aaron Leventhal-3
Alexander Surkov asked some very good questions about how visibility is
dealt with in Mozilla, and I thought I'd provide the information for
everyone.

DOM objects can dynamically become hidden or invisible at any time. We
treat creation/deletion the same as an object that simply becomes
visible/hidden via style but still exists in the tree. Either way we
only expose accessibility nodes for objects that are visible.

Accessibility nodes need to be dynamically created or destroyed in both
cases.

First, if a DOM node is inserted or deleted, we get a notication in
nsDocAccessible in one of these methods:
http://lxr.mozilla.org/seamonkey/source/accessible/src/base/nsDocAccessible.cpp#885
Then it ends up at InvalidateCacheSubtree()
http://lxr.mozilla.org/seamonkey/source/accessible/src/base/nsDocAccessible.cpp#1071

Second, if style changes cause visibility changes for a node, layout
calls here:
http://lxr.mozilla.org/seamonkey/source/accessible/src/base/nsAccessibilityService.cpp#1942
Which also ends up at the same place -- InvalidateCacheSubtree()

So all visibility changes end up at InvalidateCacheSubtree(). This has
several purposes:
1) To invalidate part of the Mozilla accessibility object cache, which
is a hash table. We don't need to keep objects in it that are no longer
relevant.
2) To fire a show, hide and reorder events to notify assistive
technologies that a part of the data model in has changed.
3) To call Shutdown() on all objects we don't care about anymore. The
object won't actually be deleted unless the assistive tech also releases
it, which it should do if it's listening to the reorder and hide events.

If the AT still holds onto the node (perhaps it didn't listen to those
mutation events), the the object is still refcounted so we can't delete
it. The AT is not left with an invalid pointer but we release as much
memory as we can. Internally we call Shutdown() on all accessible
objects which are no longer important. Part of Shutdown() is to do:
mDOMNode = nsnull;
mWeakShell = nsnull;
and cut ties to everything else internally it might be holding onto or
that might be holding onto it. Each kind of accessibility object can
also override the Shutdown() method but must upcall to get the base
Shutdown() behavior.

So in that case the assistive technology will still have a valid
pointer, but the memory used up by the object is minimal and any method
calls on it will return errors.

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

Re: How changes in visibility are dealt with

Bill Haneman
Aaron and all:

On Linux/Unix at least, the ATK interface has the concept of
STATE_VISIBLE, and supports state-change events; thus a persistant
instance of an object can become invisible and then visible again.
There may be instances in which this is more convenient (for user agent,
or assistive technology) than destroying and re-creating the object peer
being exposed to the AT.

best regards,

Bill

On Fri, 2006-04-28 at 15:07, Aaron Leventhal wrote:

> Alexander Surkov asked some very good questions about how visibility is
> dealt with in Mozilla, and I thought I'd provide the information for
> everyone.
>
> DOM objects can dynamically become hidden or invisible at any time. We
> treat creation/deletion the same as an object that simply becomes
> visible/hidden via style but still exists in the tree. Either way we
> only expose accessibility nodes for objects that are visible.
>
> Accessibility nodes need to be dynamically created or destroyed in both
> cases.
>
> First, if a DOM node is inserted or deleted, we get a notication in
> nsDocAccessible in one of these methods:
> http://lxr.mozilla.org/seamonkey/source/accessible/src/base/nsDocAccessible.cpp#885
> Then it ends up at InvalidateCacheSubtree()
> http://lxr.mozilla.org/seamonkey/source/accessible/src/base/nsDocAccessible.cpp#1071
>
> Second, if style changes cause visibility changes for a node, layout
> calls here:
> http://lxr.mozilla.org/seamonkey/source/accessible/src/base/nsAccessibilityService.cpp#1942
> Which also ends up at the same place -- InvalidateCacheSubtree()
>
> So all visibility changes end up at InvalidateCacheSubtree(). This has
> several purposes:
> 1) To invalidate part of the Mozilla accessibility object cache, which
> is a hash table. We don't need to keep objects in it that are no longer
> relevant.
> 2) To fire a show, hide and reorder events to notify assistive
> technologies that a part of the data model in has changed.
> 3) To call Shutdown() on all objects we don't care about anymore. The
> object won't actually be deleted unless the assistive tech also releases
> it, which it should do if it's listening to the reorder and hide events.
>
> If the AT still holds onto the node (perhaps it didn't listen to those
> mutation events), the the object is still refcounted so we can't delete
> it. The AT is not left with an invalid pointer but we release as much
> memory as we can. Internally we call Shutdown() on all accessible
> objects which are no longer important. Part of Shutdown() is to do:
> mDOMNode = nsnull;
> mWeakShell = nsnull;
> and cut ties to everything else internally it might be holding onto or
> that might be holding onto it. Each kind of accessibility object can
> also override the Shutdown() method but must upcall to get the base
> Shutdown() behavior.
>
> So in that case the assistive technology will still have a valid
> pointer, but the memory used up by the object is minimal and any method
> calls on it will return errors.
>
> - Aaron
> _______________________________________________
> 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: How changes in visibility are dealt with

Aaron Leventhal-3
What's the difference in AT behavior between something that is hidden
vs. something that is not there at all?

- Aaron

Bill Haneman wrote:

> Aaron and all:
>
> On Linux/Unix at least, the ATK interface has the concept of
> STATE_VISIBLE, and supports state-change events; thus a persistant
> instance of an object can become invisible and then visible again.
> There may be instances in which this is more convenient (for user agent,
> or assistive technology) than destroying and re-creating the object peer
> being exposed to the AT.
>
> best regards,
>
> Bill
>
> On Fri, 2006-04-28 at 15:07, Aaron Leventhal wrote:
>  
>> Alexander Surkov asked some very good questions about how visibility is
>> dealt with in Mozilla, and I thought I'd provide the information for
>> everyone.
>>
>> DOM objects can dynamically become hidden or invisible at any time. We
>> treat creation/deletion the same as an object that simply becomes
>> visible/hidden via style but still exists in the tree. Either way we
>> only expose accessibility nodes for objects that are visible.
>>
>> Accessibility nodes need to be dynamically created or destroyed in both
>> cases.
>>
>> First, if a DOM node is inserted or deleted, we get a notication in
>> nsDocAccessible in one of these methods:
>> http://lxr.mozilla.org/seamonkey/source/accessible/src/base/nsDocAccessible.cpp#885
>> Then it ends up at InvalidateCacheSubtree()
>> http://lxr.mozilla.org/seamonkey/source/accessible/src/base/nsDocAccessible.cpp#1071
>>
>> Second, if style changes cause visibility changes for a node, layout
>> calls here:
>> http://lxr.mozilla.org/seamonkey/source/accessible/src/base/nsAccessibilityService.cpp#1942
>> Which also ends up at the same place -- InvalidateCacheSubtree()
>>
>> So all visibility changes end up at InvalidateCacheSubtree(). This has
>> several purposes:
>> 1) To invalidate part of the Mozilla accessibility object cache, which
>> is a hash table. We don't need to keep objects in it that are no longer
>> relevant.
>> 2) To fire a show, hide and reorder events to notify assistive
>> technologies that a part of the data model in has changed.
>> 3) To call Shutdown() on all objects we don't care about anymore. The
>> object won't actually be deleted unless the assistive tech also releases
>> it, which it should do if it's listening to the reorder and hide events.
>>
>> If the AT still holds onto the node (perhaps it didn't listen to those
>> mutation events), the the object is still refcounted so we can't delete
>> it. The AT is not left with an invalid pointer but we release as much
>> memory as we can. Internally we call Shutdown() on all accessible
>> objects which are no longer important. Part of Shutdown() is to do:
>> mDOMNode = nsnull;
>> mWeakShell = nsnull;
>> and cut ties to everything else internally it might be holding onto or
>> that might be holding onto it. Each kind of accessibility object can
>> also override the Shutdown() method but must upcall to get the base
>> Shutdown() behavior.
>>
>> So in that case the assistive technology will still have a valid
>> pointer, but the memory used up by the object is minimal and any method
>> calls on it will return errors.
>>
>> - Aaron
>> _______________________________________________
>> 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: How changes in visibility are dealt with

Jonathan Chetwynd
Aaron,

It seems one can tab to a link that's hidden**.

regards

Jonathan Chetwynd



On 28 Apr 2006, at 20:39, Aaron Leventhal wrote:

What's the difference in AT behavior between something that is hidden  
vs. something that is not there at all?

- Aaron

**

please let me know if you believe this is a bug ~:" I'll file it.


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

Re: How changes in visibility are dealt with

Bill Haneman
In reply to this post by Aaron Leventhal-3
On Fri, 2006-04-28 at 20:39, Aaron Leventhal wrote:
> What's the difference in AT behavior between something that is hidden
> vs. something that is not there at all?

If an object disappears, it makes sense for an AT to purge any cached
information it holds about the object.  If the object's visibility
changes to "false", it may be reasonable to keep the cache if the object
is likely to re-appear.

Bill

>
> - Aaron
>
> Bill Haneman wrote:
> > Aaron and all:
> >
> > On Linux/Unix at least, the ATK interface has the concept of
> > STATE_VISIBLE, and supports state-change events; thus a persistant
> > instance of an object can become invisible and then visible again.
> > There may be instances in which this is more convenient (for user agent,
> > or assistive technology) than destroying and re-creating the object peer
> > being exposed to the AT.
> >
> > best regards,
> >
> > Bill
> >
> > On Fri, 2006-04-28 at 15:07, Aaron Leventhal wrote:
> >  
> >> Alexander Surkov asked some very good questions about how visibility is
> >> dealt with in Mozilla, and I thought I'd provide the information for
> >> everyone.
> >>
> >> DOM objects can dynamically become hidden or invisible at any time. We
> >> treat creation/deletion the same as an object that simply becomes
> >> visible/hidden via style but still exists in the tree. Either way we
> >> only expose accessibility nodes for objects that are visible.
> >>
> >> Accessibility nodes need to be dynamically created or destroyed in both
> >> cases.
> >>
> >> First, if a DOM node is inserted or deleted, we get a notication in
> >> nsDocAccessible in one of these methods:
> >> http://lxr.mozilla.org/seamonkey/source/accessible/src/base/nsDocAccessible.cpp#885
> >> Then it ends up at InvalidateCacheSubtree()
> >> http://lxr.mozilla.org/seamonkey/source/accessible/src/base/nsDocAccessible.cpp#1071
> >>
> >> Second, if style changes cause visibility changes for a node, layout
> >> calls here:
> >> http://lxr.mozilla.org/seamonkey/source/accessible/src/base/nsAccessibilityService.cpp#1942
> >> Which also ends up at the same place -- InvalidateCacheSubtree()
> >>
> >> So all visibility changes end up at InvalidateCacheSubtree(). This has
> >> several purposes:
> >> 1) To invalidate part of the Mozilla accessibility object cache, which
> >> is a hash table. We don't need to keep objects in it that are no longer
> >> relevant.
> >> 2) To fire a show, hide and reorder events to notify assistive
> >> technologies that a part of the data model in has changed.
> >> 3) To call Shutdown() on all objects we don't care about anymore. The
> >> object won't actually be deleted unless the assistive tech also releases
> >> it, which it should do if it's listening to the reorder and hide events.
> >>
> >> If the AT still holds onto the node (perhaps it didn't listen to those
> >> mutation events), the the object is still refcounted so we can't delete
> >> it. The AT is not left with an invalid pointer but we release as much
> >> memory as we can. Internally we call Shutdown() on all accessible
> >> objects which are no longer important. Part of Shutdown() is to do:
> >> mDOMNode = nsnull;
> >> mWeakShell = nsnull;
> >> and cut ties to everything else internally it might be holding onto or
> >> that might be holding onto it. Each kind of accessibility object can
> >> also override the Shutdown() method but must upcall to get the base
> >> Shutdown() behavior.
> >>
> >> So in that case the assistive technology will still have a valid
> >> pointer, but the memory used up by the object is minimal and any method
> >> calls on it will return errors.
> >>
> >> - Aaron
> >> _______________________________________________
> >> 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: How changes in visibility are dealt with

Aaron Leventhal-3
In reply to this post by Aaron Leventhal-3
You should not be able to.

You mean visibility: hidden or display: none?

- Aaron

Jonathan Chetwynd wrote:

> Aaron,
>
> It seems one can tab to a link that's hidden**.
>
> regards
>
> Jonathan Chetwynd
>
>
>
> On 28 Apr 2006, at 20:39, Aaron Leventhal wrote:
>
> What's the difference in AT behavior between something that is hidden
> vs. something that is not there at all?
>
> - Aaron
>
> **
>
> please let me know if you believe this is a bug ~:" I'll file it.
>
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

RE: How changes in visibility are dealt with

Sina Bahram
I can verrify this with at least window eyes and jaws that this is indeed
the case ... Hidden is hidden is hidden, whether you're sighted or blind.

Oh by the way: hi all *waves*, I recently joined. I'm a visually impaired
user of Firefox ... Maybe hopefully a contributer?

Take care,
Sina

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Aaron
Leventhal
Sent: Friday, April 28, 2006 9:26 PM
To: Jonathan Chetwynd
Cc: Bill Haneman; [hidden email]
Subject: Re: How changes in visibility are dealt with

You should not be able to.

You mean visibility: hidden or display: none?

- Aaron

Jonathan Chetwynd wrote:

> Aaron,
>
> It seems one can tab to a link that's hidden**.
>
> regards
>
> Jonathan Chetwynd
>
>
>
> On 28 Apr 2006, at 20:39, Aaron Leventhal wrote:
>
> What's the difference in AT behavior between something that is hidden
> vs. something that is not there at all?
>
> - Aaron
>
> **
>
> please let me know if you believe this is a bug ~:" I'll file it.
>
_______________________________________________
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
|

Welcome new contributors [was Re: How changes in visibility are dealt with]

Aaron Leventhal-3
Sina and other new people,

Welcome -- we would love to get some developers who actually use
assistive technologies involved in Mozilla. I admit that getting it
built the first time is pretty hard, getting into the codebase is hard.
It's all pretty difficult sometimes but it's a very rewarding project in
that it touches tens of millions of people and is such an interesting
and useful piece of software.

Many developers get started by just using the technologies in it and
then, after a while, knowing what they want to improve. Some get started
by writing an extension. I imagine that many developers will soon get
involved via creating applicatios with xul runner.

- Aaron



Sina Bahram wrote:

> I can verrify this with at least window eyes and jaws that this is indeed
> the case ... Hidden is hidden is hidden, whether you're sighted or blind.
>
> Oh by the way: hi all *waves*, I recently joined. I'm a visually impaired
> user of Firefox ... Maybe hopefully a contributer?
>
> Take care,
> Sina
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Aaron
> Leventhal
> Sent: Friday, April 28, 2006 9:26 PM
> To: Jonathan Chetwynd
> Cc: Bill Haneman; [hidden email]
> Subject: Re: How changes in visibility are dealt with
>
> You should not be able to.
>
> You mean visibility: hidden or display: none?
>
> - Aaron
>
> Jonathan Chetwynd wrote:
>  
>> Aaron,
>>
>> It seems one can tab to a link that's hidden**.
>>
>> regards
>>
>> Jonathan Chetwynd
>>
>>
>>
>> On 28 Apr 2006, at 20:39, Aaron Leventhal wrote:
>>
>> What's the difference in AT behavior between something that is hidden
>> vs. something that is not there at all?
>>
>> - Aaron
>>
>> **
>>
>> please let me know if you believe this is a bug ~:" I'll file it.
>>
>>    
> _______________________________________________
> 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: Welcome new contributors [was Re: How changes in visibility are dealt with]

Sina Bahram
Thanks for the warm welcome.

What I'm going to be doing quite soon is looking up the instructions on how
to build this thing, and hopefully be able to jump right in.

I do have one more specific question about this list:

I noticed that the "reply" goes to the sender and not the whole list.

Since I always wish to send my responses to the list on an ongoing thread,
does that mean I should delete the person's email, or is it just commonly
accepted that people will get duplicates?

Take care,
Sina

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Aaron
Leventhal
Sent: Friday, April 28, 2006 9:57 PM
To: [hidden email]
Subject: Welcome new contributors [was Re: How changes in visibility are
dealt with]

Sina and other new people,

Welcome -- we would love to get some developers who actually use assistive
technologies involved in Mozilla. I admit that getting it built the first
time is pretty hard, getting into the codebase is hard.
It's all pretty difficult sometimes but it's a very rewarding project in
that it touches tens of millions of people and is such an interesting and
useful piece of software.

Many developers get started by just using the technologies in it and then,
after a while, knowing what they want to improve. Some get started by
writing an extension. I imagine that many developers will soon get involved
via creating applicatios with xul runner.

- Aaron



Sina Bahram wrote:
> I can verrify this with at least window eyes and jaws that this is
> indeed the case ... Hidden is hidden is hidden, whether you're sighted or
blind.

>
> Oh by the way: hi all *waves*, I recently joined. I'm a visually
> impaired user of Firefox ... Maybe hopefully a contributer?
>
> Take care,
> Sina
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of
> Aaron Leventhal
> Sent: Friday, April 28, 2006 9:26 PM
> To: Jonathan Chetwynd
> Cc: Bill Haneman; [hidden email]
> Subject: Re: How changes in visibility are dealt with
>
> You should not be able to.
>
> You mean visibility: hidden or display: none?
>
> - Aaron
>
> Jonathan Chetwynd wrote:
>  
>> Aaron,
>>
>> It seems one can tab to a link that's hidden**.
>>
>> regards
>>
>> Jonathan Chetwynd
>>
>>
>>
>> On 28 Apr 2006, at 20:39, Aaron Leventhal wrote:
>>
>> What's the difference in AT behavior between something that is hidden
>> vs. something that is not there at all?
>>
>> - Aaron
>>
>> **
>>
>> please let me know if you believe this is a bug ~:" I'll file it.
>>
>>    
> _______________________________________________
> 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: Welcome new contributors [was Re: How changes in visibility aredealt with]

Visually Insane Genetically Modified Organism
I just joined as well. I design and build web sites. So I do not know what
or if I can contribute. I use Firefox 1.5 with JAWS 6.2 and love it. I am
using Firefox with the web developer toolbar more and more. The only reason
I still use IE6, is for the list of links. Thunderbird is more accessible
than it has been in the past. I found setting JAWS WindowsManager to MSAA
makes Thunderbird fairly accessible.

----
Angus MacKinnon
MacKinnon Crest Saying
Latin -  Audentes Fortuna Juvat
English - Fortune Assists The Daring
Web page http://www.infoforce-services.com
Choroideremia Research Foundation Inc. 2nd Vice president
http://www.choroideremia.org

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

Re: [Bulk] Re: How changes in visibility are dealt with

Jonathan Chetwynd
In reply to this post by Jonathan Chetwynd
Aaron,

Why should the tab order be effected by the value of hidden, as  
someone not using a screen wont be effected, otherwise.

Anyway for firefox 1.5 the following demonstrates that at present the  
hidden value doesn't effect the tab order:


<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/ 
Graphics/SVG/1.1/DTD/svg11.dtd">
<svg width="200px" height="200px" viewBox="0 0 100 100"
      xmlns="http://www.w3.org/2000/svg" version="1.1"
      xmlns:xlink="http://www.w3.org/1999/xlink"
      xmlns:html="http://www.w3.org/1999/xhtml">
   <a xlink:href="http://www.peepo.com">
      <rect width="40px" height="40px" fill="green"  
visibility="hidden" />
   </a>
   <a xlink:href="http://www.mozilla.org">
      <rect x="40px" width="40px" height="40px" fill="green" />
   </a>
</svg>

apologies for my error, hadn't appreciated that attachments were  
stripped

regards

Jonathan Chetwynd



On 28 Apr 2006, at 22:15, Jonathan Chetwynd wrote:

Aaron,

It seems one can tab to a link that's hidden**.

regards

Jonathan Chetwynd



On 28 Apr 2006, at 20:39, Aaron Leventhal wrote:

What's the difference in AT behavior between something that is hidden  
vs. something that is not there at all?

- Aaron

**
please let me know if you believe this is a bug ~:" I'll file it.

_______________________________________________
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: How changes in visibility are dealt with

David hilbert Poehlman
In reply to this post by Aaron Leventhal-3
Hi Aaron and all,

I've been following the list activity over the past days with a lot  
of interest.  This is by the way also my introduction to the rest of  
the group many of whom I know and respect but some I do not know but  
surely respect.

I'm a multi browser, Mac, linux, jaws and window eyes consumer and  
tester and also a member of two Web Accessibility Initiative working  
groups as well as an accessibility QA engineer well sort of.  I've  
been around this field since 1980 if I remember correctly and  
probably before that in some ways.

My answer to the question of what AT does though is that as others  
have mentioned, it is possible to tab to a link which is hidden.  
Going beyond that though to what happens in the dynamic world is an  
interesting conundrum in thatt what I've experienced is that often,  
stuff gets yanked before I can get to fully examine it if I can  
examine it at all.  I hope that once we establish what AT does, we  
can move to establishing what AT needs to do?

Thanks for reading.

On Apr 28, 2006, at 3:39 PM, Aaron Leventhal wrote:

What's the difference in AT behavior between something that is hidden  
vs. something that is not there at all?

- Aaron

Bill Haneman wrote:

> Aaron and all:
>
> On Linux/Unix at least, the ATK interface has the concept of
> STATE_VISIBLE, and supports state-change events; thus a persistant
> instance of an object can become invisible and then visible again.  
> There may be instances in which this is more convenient (for user  
> agent,
> or assistive technology) than destroying and re-creating the object  
> peer
> being exposed to the AT.
>
> best regards,
>
> Bill
>
> On Fri, 2006-04-28 at 15:07, Aaron Leventhal wrote:
>
>> Alexander Surkov asked some very good questions about how  
>> visibility is dealt with in Mozilla, and I thought I'd provide the  
>> information for everyone.
>>
>> DOM objects can dynamically become hidden or invisible at any  
>> time. We treat creation/deletion the same as an object that simply  
>> becomes visible/hidden via style but still exists in the tree.  
>> Either way we only expose accessibility nodes for objects that are  
>> visible.
>>
>> Accessibility nodes need to be dynamically created or destroyed in  
>> both cases.
>>
>> First, if a DOM node is inserted or deleted, we get a notication  
>> in nsDocAccessible in one of these methods:
>> http://lxr.mozilla.org/seamonkey/source/accessible/src/base/ 
>> nsDocAccessible.cpp#885
>> Then it ends up at InvalidateCacheSubtree()
>> http://lxr.mozilla.org/seamonkey/source/accessible/src/base/ 
>> nsDocAccessible.cpp#1071
>>
>> Second, if style changes cause visibility changes for a node,  
>> layout calls here:
>> http://lxr.mozilla.org/seamonkey/source/accessible/src/base/ 
>> nsAccessibilityService.cpp#1942
>> Which also ends up at the same place -- InvalidateCacheSubtree()
>>
>> So all visibility changes end up at InvalidateCacheSubtree(). This  
>> has several purposes:
>> 1) To invalidate part of the Mozilla accessibility object cache,  
>> which is a hash table. We don't need to keep objects in it that  
>> are no longer relevant.
>> 2) To fire a show, hide and reorder events to notify assistive  
>> technologies that a part of the data model in has changed.
>> 3) To call Shutdown() on all objects we don't care about anymore.  
>> The object won't actually be deleted unless the assistive tech  
>> also releases it, which it should do if it's listening to the  
>> reorder and hide events.
>>
>> If the AT still holds onto the node (perhaps it didn't listen to  
>> those mutation events), the the object is still refcounted so we  
>> can't delete it. The AT is not left with an invalid pointer but we  
>> release as much memory as we can. Internally we call Shutdown() on  
>> all accessible objects which are no longer important. Part of  
>> Shutdown() is to do:
>> mDOMNode = nsnull;
>> mWeakShell = nsnull;
>> and cut ties to everything else internally it might be holding  
>> onto or that might be holding onto it. Each kind of accessibility  
>> object can also override the Shutdown() method but must upcall to  
>> get the base Shutdown() behavior.
>>
>> So in that case the assistive technology will still have a valid  
>> pointer, but the memory used up by the object is minimal and any  
>> method calls on it will return errors.
>>
>> - Aaron
>> _______________________________________________
>> 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: [Bulk] Re: How changes in visibility are dealt with

Jonathan Chetwynd
In reply to this post by Jonathan Chetwynd
slightly embarrassing, but evidently I forgot to include <title>  
attributes
~:"

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/ 
Graphics/SVG/1.1/DTD/svg11.dtd">
<svg width="200px" height="200px" viewBox="0 0 100 100"
      xmlns="http://www.w3.org/2000/svg" version="1.1"
      xmlns:xlink="http://www.w3.org/1999/xlink"
      xmlns:html="http://www.w3.org/1999/xhtml">

   <a xlink:href="http://www.peepo.com">
      <rect width="40px" height="40px" fill="green"  
visibility="hidden" >
        <title>hidden link</title>
      </rect>
   </a>
   <a xlink:href="http://www.mozilla.org">
      <rect x="40px" width="40px" height="40px" fill="green" >
      <title>visible link</title>
      </rect>
   </a>
</svg>



regards

Jonathan Chetwynd

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

RE: [Bulk] Re: How changes in visibility are dealt with

Sina Bahram
The link does not appear to me when I use jaws at all.

I have enough vision to see that the rect does indeed show up in firefox.

Also, when I removed the visibility="hidden" ... The link still did not show
up to jaws.

Take care,
Sina

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Jonathan
Chetwynd
Sent: Saturday, April 29, 2006 5:23 AM
To: Jonathan Chetwynd
Cc: Bill Haneman; [hidden email]; Aaron Leventhal
Subject: Re: [Bulk] Re: How changes in visibility are dealt with

slightly embarrassing, but evidently I forgot to include <title> attributes
~:"

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/
Graphics/SVG/1.1/DTD/svg11.dtd"> <svg width="200px" height="200px"
viewBox="0 0 100 100"
      xmlns="http://www.w3.org/2000/svg" version="1.1"
      xmlns:xlink="http://www.w3.org/1999/xlink"
      xmlns:html="http://www.w3.org/1999/xhtml">

   <a xlink:href="http://www.peepo.com">
      <rect width="40px" height="40px" fill="green"  
visibility="hidden" >
        <title>hidden link</title>
      </rect>
   </a>
   <a xlink:href="http://www.mozilla.org">
      <rect x="40px" width="40px" height="40px" fill="green" >
      <title>visible link</title>
      </rect>
   </a>
</svg>



regards

Jonathan Chetwynd

_______________________________________________
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: [Bulk] RE: [Bulk] Re: How changes in visibility are dealt with

Jonathan Chetwynd
Sina,

There should be one green square displaced by a hidden square, both  
are links, though to different locations.
when I tested with jaws and firefox, it wasn't possible to visit  
http://www.peepo.co.uk using jaws, however I did once visit http://
www.mozilla.org.

Naturally one cannot visit http://www.peepo.co.uk using a mouse,  
however one can tab to either. using the tab key, provided jaws is  
switched off.

regards

Jonathan Chetwynd



On 29 Apr 2006, at 18:30, Sina Bahram wrote:

The link does not appear to me when I use jaws at all.

I have enough vision to see that the rect does indeed show up in  
firefox.

Also, when I removed the visibility="hidden" ... The link still did  
not show
up to jaws.

Take care,
Sina

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of  
Jonathan
Chetwynd
Sent: Saturday, April 29, 2006 5:23 AM
To: Jonathan Chetwynd
Cc: Bill Haneman; [hidden email]; Aaron Leventhal
Subject: Re: [Bulk] Re: How changes in visibility are dealt with

slightly embarrassing, but evidently I forgot to include <title>  
attributes
~:"

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/
Graphics/SVG/1.1/DTD/svg11.dtd"> <svg width="200px" height="200px"
viewBox="0 0 100 100"
       xmlns="http://www.w3.org/2000/svg" version="1.1"
       xmlns:xlink="http://www.w3.org/1999/xlink"
       xmlns:html="http://www.w3.org/1999/xhtml">

    <a xlink:href="http://www.peepo.com">
       <rect width="40px" height="40px" fill="green"
visibility="hidden" >
        <title>hidden link</title>
       </rect>
    </a>
    <a xlink:href="http://www.mozilla.org">
       <rect x="40px" width="40px" height="40px" fill="green" >
      <title>visible link</title>
       </rect>
    </a>
</svg>



regards

Jonathan Chetwynd

_______________________________________________
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: [Bulk] RE: [Bulk] Re: How changes in visibility are dealt with

Sina Bahram
But I didn't see either link at all with jaws and the latest Firefox ... Do
I need to be running off the dev version of Firefox?

If so, then forgive my mistake.

Take care,
Sina

-----Original Message-----
From: Jonathan Chetwynd [mailto:[hidden email]]
Sent: Saturday, April 29, 2006 3:56 PM
To: Sina Bahram
Cc: [hidden email]
Subject: Re: [Bulk] RE: [Bulk] Re: How changes in visibility are dealt with

Sina,

There should be one green square displaced by a hidden square, both are
links, though to different locations.
when I tested with jaws and firefox, it wasn't possible to visit
http://www.peepo.co.uk using jaws, however I did once visit http://
www.mozilla.org.

Naturally one cannot visit http://www.peepo.co.uk using a mouse, however one
can tab to either. using the tab key, provided jaws is switched off.

regards

Jonathan Chetwynd



On 29 Apr 2006, at 18:30, Sina Bahram wrote:

The link does not appear to me when I use jaws at all.

I have enough vision to see that the rect does indeed show up in firefox.

Also, when I removed the visibility="hidden" ... The link still did not show
up to jaws.

Take care,
Sina

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Jonathan
Chetwynd
Sent: Saturday, April 29, 2006 5:23 AM
To: Jonathan Chetwynd
Cc: Bill Haneman; [hidden email]; Aaron Leventhal
Subject: Re: [Bulk] Re: How changes in visibility are dealt with

slightly embarrassing, but evidently I forgot to include <title> attributes
~:"

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/
Graphics/SVG/1.1/DTD/svg11.dtd"> <svg width="200px" height="200px"
viewBox="0 0 100 100"
       xmlns="http://www.w3.org/2000/svg" version="1.1"
       xmlns:xlink="http://www.w3.org/1999/xlink"
       xmlns:html="http://www.w3.org/1999/xhtml">

    <a xlink:href="http://www.peepo.com">
       <rect width="40px" height="40px" fill="green"
visibility="hidden" >
        <title>hidden link</title>
       </rect>
    </a>
    <a xlink:href="http://www.mozilla.org">
       <rect x="40px" width="40px" height="40px" fill="green" >
      <title>visible link</title>
       </rect>
    </a>
</svg>



regards

Jonathan Chetwynd

_______________________________________________
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: How changes in visibility are dealt with

Jonathan Chetwynd
Sina,

to be honest I once managed to tab to the mozilla link using jaws,  
but this may have been a glitch.
this is a jaws issue, nothing to to with hidden, they just dont  
currently support SVG.
Otherwise the relatively simple issue of speaking title attributes  
might be present.

It might be worth taking up with Freedom Scientific.....

regards

Jonathan Chetwynd



On 29 Apr 2006, at 21:04, Sina Bahram wrote:

But I didn't see either link at all with jaws and the latest  
Firefox ... Do
I need to be running off the dev version of Firefox?

If so, then forgive my mistake.

Take care,
Sina

-----Original Message-----
From: Jonathan Chetwynd [mailto:[hidden email]]
Sent: Saturday, April 29, 2006 3:56 PM
To: Sina Bahram
Cc: [hidden email]
Subject: Re: [Bulk] RE: [Bulk] Re: How changes in visibility are  
dealt with

Sina,

There should be one green square displaced by a hidden square, both are
links, though to different locations.
when I tested with jaws and firefox, it wasn't possible to visit
http://www.peepo.co.uk using jaws, however I did once visit http://
www.mozilla.org.

Naturally one cannot visit http://www.peepo.co.uk using a mouse,  
however one
can tab to either. using the tab key, provided jaws is switched off.

regards

Jonathan Chetwynd



On 29 Apr 2006, at 18:30, Sina Bahram wrote:

The link does not appear to me when I use jaws at all.

I have enough vision to see that the rect does indeed show up in  
firefox.

Also, when I removed the visibility="hidden" ... The link still did  
not show
up to jaws.

Take care,
Sina

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of  
Jonathan
Chetwynd
Sent: Saturday, April 29, 2006 5:23 AM
To: Jonathan Chetwynd
Cc: Bill Haneman; [hidden email]; Aaron Leventhal
Subject: Re: [Bulk] Re: How changes in visibility are dealt with

slightly embarrassing, but evidently I forgot to include <title>  
attributes
~:"

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/
Graphics/SVG/1.1/DTD/svg11.dtd"> <svg width="200px" height="200px"
viewBox="0 0 100 100"
        xmlns="http://www.w3.org/2000/svg" version="1.1"
        xmlns:xlink="http://www.w3.org/1999/xlink"
        xmlns:html="http://www.w3.org/1999/xhtml">

     <a xlink:href="http://www.peepo.com">
        <rect width="40px" height="40px" fill="green"
visibility="hidden" >
        <title>hidden link</title>
        </rect>
     </a>
     <a xlink:href="http://www.mozilla.org">
        <rect x="40px" width="40px" height="40px" fill="green" >
        <title>visible link</title>
        </rect>
     </a>
</svg>



regards

Jonathan Chetwynd

_______________________________________________
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

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

Re: Welcome new contributors [was Re: How changes in visibility aredealt with]

Aaron Leventhal-3
In reply to this post by Sina Bahram
If you use JAWS you really need to upgrade to JAWS 7.x for use with
Firefox. Much, much improved.

Since you design and use websites, please please take a look at the
DHTML accessibility work. That's really a place where Firefox shines and
is leading the future of web accessibility. But, it is totally in need
of developers who will start playing with it, understanding it, using it
and evangelizing it.
http://www.mozilla.org/access/dhtml

Let me know what you think.
- Aaron


Visually Insane Genetically Modified Organism wrote:

> I just joined as well. I design and build web sites. So I do not know
> what or if I can contribute. I use Firefox 1.5 with JAWS 6.2 and love
> it. I am using Firefox with the web developer toolbar more and more. The
> only reason I still use IE6, is for the list of links. Thunderbird is
> more accessible than it has been in the past. I found setting JAWS
> WindowsManager to MSAA makes Thunderbird fairly accessible.
>
> ----
> Angus MacKinnon
> MacKinnon Crest Saying
> Latin -  Audentes Fortuna Juvat
> English - Fortune Assists The Daring
> Web page http://www.infoforce-services.com
> Choroideremia Research Foundation Inc. 2nd Vice president
> http://www.choroideremia.org
>
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Welcome new contributors [was Re: How changes in visibility aredealt with]

Visually Insane Genetically Modified Organism
Aaron

Thank you for the link. Alot of information to digest. What I read gets me
more and more excited. And what a suprise about Microsoft (M$). M$ doing
what they want and not shareing. Does JAWS 7.1 have more DHTML support?
----
Angus MacKinnon
MacKinnon Crest Saying
Latin -  Audentes Fortuna Juvat
English - Fortune Assists The Daring
Web page http://www.infoforce-services.com
Choroideremia Research Foundation Inc. 2nd Vice president
http://www.choroideremia.org

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

Re: Welcome new contributors [was Re: How changes in visibility aredealt with]

Aaron Leventhal-3
In reply to this post by Aaron Leventhal-3
Visually Insane Genetically Modified Organism wrote:
> Thank you for the link. Alot of information to digest.
Feel free to ask questions right on this list.

> Does JAWS 7.1 have more DHTML support?
I'm not sure -- all I can say as that we'd like to get a bigger piece of
Freedom Scientific's agenda.

- Aaron
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
12