Longer term fix for bug 591363 and bug 722248 etc. For whatever reason, our gecko a11y engine has historically exposed what I call "rendered visibility". I think what AT really care about is "intended visibility" (AKA "programmatic visibility"). See for example, bug 591363 comment 6. This seems to imply that 'being in the background, occluded' should not necessarily mean invisible. If we agree to go this route we'll likely need heavy QA and AT outreach.

Handy URL from Alexander: http://blogs.msdn.com/b/vsaccessibility/archive/2004/09/20/232157.aspx

Aside: in my previous outreach no AT vendors indicated they utilize the offscreen state, but I haven't heard back from all.

(In reply to David Bolter [:davidb] from comment #2) > Aside: in my previous outreach no AT vendors indicated they utilize the > offscreen state, but I haven't heard back from all. We use offscreen differently to invisible. To us, invisible means the object is intentionally hidden, where offscreen means the object is obscured, in the background, out of visible range, etc. According to this idea, documents (and their descendants) in inactive tabs should be offscreen, not invisible.

As part of this bug make sure we don't set INVISIBLE/OFFSCREEN states outside VisibilityState() method.

David, are you working on this bug?

(In reply to alexander :surkov from comment #5) > David, are you working on this bug? Not right now. If anyone takes it please keep me in the loop for feedback and reviews.

Think of INVISIBLE as, this object is not ever intended to be visible. Think of OFFSCREEN as, this object can happily be visible but happens to not be (perhaps because it is in a background tab for example).

Sigh I should amend that. Think of INVISIBLE as, this object is not intended to be visible even if it is not in the background, is scrolled into the viewport etc.

What I should do here ?

Stuff to do: 1. Read docs in comment 1 and understand offscreen and invisible states. You can ping me on IRC to be sure. 2. Review the existing code: Accessible::VisibilityState 3. Understand how we are currently calculating these states differently from comment 1 + comment 7 + comment 8. 4. Fix it :) Let me know when you are really stuck. As you fix things you may see some test failures which we'll need to update.

Michał, do you work on this?

Yes, but If its need to be done asap, feel free to take it, I've lot of work in my job and it will take me long time to make it done.

Ok, then I can give you hints how to fix the bug. After bug 686821 is fixed there's no much to do with the bug as it was originally reported but you can do here comment #4, i.e. VisibilityState should be responsible for invisible and offscreen states. 1) it seems DocAccessible::NativeState() should call VisibilityState() instead of managing invisible/offscreen styles itself. You need to extend a test introduced in bug 686821 to test a document accessible. 2) It's quite possible that HTMLSelectOptionAccessible::NativeState() don't need to manage invisible/offscreen styles. Having offscreen state off for selected item in combobox might be needed for JAWS only, we can hack it on platform layer. 3) similar things for XULMenuitemAccessible::NativeState 4) I'm not sure whether we should expose offscreen for XULMenupopupAccessible::NativeState(). Invisible state is enough. It makes sense to check hg/cvs history. 5) XULTreeItemAccessibleBase::NativeState() should expose offscreen state rather than invisible state. Override VisibilityState() for that. Each part can be handled in own bug. Let me know what parts do you like to work on. If you wouldn't want to handle all of them then I can file good first bugs for those you don't wanna hack and let others to fix them.

I'll try all of them ;)

is this bug still valid? My heart hurts so badly because I didnt make it. I would like to finish it now.

(In reply to Michał Frontczak :fxa90id from comment #15) > is this bug still valid? My heart hurts so badly because I didnt make it. > I would like to finish it now. It is. Thanks.

Comment on attachment 756585 [details] [diff] [review] preview Review of attachment 756585 [details] [diff] [review]: ----------------------------------------------------------------- Too much removed you have.

Comment on attachment 756585 [details] [diff] [review] preview Review of attachment 756585 [details] [diff] [review]: ----------------------------------------------------------------- Too much removed you have. ::: accessible/src/generic/DocAccessible.cpp @@ -235,5 @@ > - > - // Expose stale state until the document is ready (DOM is loaded and tree is > - // constructed). > - if (!HasLoadState(eReady)) > - state |= states::STALE; Why did you remove this? @@ -240,5 @@ > - > - // Expose state busy until the document and all its subdocuments is completely > - // loaded. > - if (!HasLoadState(eCompletelyLoaded)) > - state |= states::BUSY; And this?

I have setup my env on new pc :) so I will be able to fix it soon, I dont remember now why I removed this thing I will now this next week.

1) it seems DocAccessible::NativeState() should call VisibilityState() instead of managing invisible/offscreen styles itself. You need to extend a test introduced in bug 686821 to test a document accessible. That's why I removed so much code. But it is maybe because of not understanding what surkov wrote.

What about elements that are obscured by a sibling (or distant sibling) element? I think those should be considered invisible, no? Since they have no "intended visibility". There are a lot of borderline cases, for example, partially obscured elements, or elements obscured by non-opaque elements. How about: An element is invisible if it entirely obscured by another element that is not styled with "pointer-events: none;" AND has an opacity greater than 0.5.

(In reply to Eitan Isaacson [:eeejay] from comment #22) > How about: An element is invisible if it entirely obscured by another > element that is not styled with "pointer-events: none;" AND has an opacity > greater than 0.5. this sounds reasonable. but regardless the summary this bug was cleaning-up bug (see comment #1 which was mostly addressed by other bugs), the expected work was scoped by comment #13. So we need to split this bug into few bugs.

Ok, so I will work now on 1) (In reply to alexander :surkov from comment #13) > Ok, then I can give you hints how to fix the bug. > > After bug 686821 is fixed there's no much to do with the bug as it was > originally reported but you can do here comment #4, i.e. VisibilityState > should be responsible for invisible and offscreen states. > > 1) it seems DocAccessible::NativeState() should call VisibilityState() > instead of managing invisible/offscreen styles itself. You need to extend a > test introduced in bug 686821 to test a document accessible. > > 2) It's quite possible that HTMLSelectOptionAccessible::NativeState() don't > need to manage invisible/offscreen styles. Having offscreen state off for > selected item in combobox might be needed for JAWS only, we can hack it on > platform layer. > > 3) similar things for XULMenuitemAccessible::NativeState > > 4) I'm not sure whether we should expose offscreen for > XULMenupopupAccessible::NativeState(). Invisible state is enough. It makes > sense to check hg/cvs history. > > 5) XULTreeItemAccessibleBase::NativeState() should expose offscreen state > rather than invisible state. Override VisibilityState() for that. > > Each part can be handled in own bug. Let me know what parts do you like to > work on. If you wouldn't want to handle all of them then I can file good > first bugs for those you don't wanna hack and let others to fix them.

I'm going to remove the mentor field because this bug is tricky and involves vendor collaboration.

(In reply to alexander :surkov from comment #23) > (In reply to Eitan Isaacson [:eeejay] from comment #22) > > > How about: An element is invisible if it entirely obscured by another > > element that is not styled with "pointer-events: none;" AND has an opacity > > greater than 0.5. > > this sounds reasonable. But see comment 3.

(In reply to David Bolter [:davidb] from comment #26) > (In reply to alexander :surkov from comment #23) > > (In reply to Eitan Isaacson [:eeejay] from comment #22) > > > > > How about: An element is invisible if it entirely obscured by another > > > element that is not styled with "pointer-events: none;" AND has an opacity > > > greater than 0.5. > > > > this sounds reasonable. > > But see comment 3. I think tabs do not fall into this category. Iirc that's how we treat them now and, yeah, no reason to change that.

I would love to see movement/clarity on these kinds of issues. Is this a similar bug to bug 922751? I guess it is documented there what I started, and why I abandoned it after roc's input.

(In reply to alexander :surkov from comment #27) > (In reply to David Bolter [:davidb] from comment #26) > > (In reply to alexander :surkov from comment #23) > > > (In reply to Eitan Isaacson [:eeejay] from comment #22) > > > > > > > How about: An element is invisible if it entirely obscured by another > > > > element that is not styled with "pointer-events: none;" AND has an opacity > > > > greater than 0.5. > > > > > > this sounds reasonable. > > > > But see comment 3. > > I think tabs do not fall into this category. Iirc that's how we treat them > now and, yeah, no reason to change that. I thought tabs was just an example, the point seemed more general (to me).