Objects that have an unknown role are not exposed in the accessible hierarchy. This appears to inhibit the children of these objects from having their "id" object attribute exposed. For instance, the search box container is absent from the hierarchy and so its children do not show their "id" attribute. One possible fix is to expose generic nodes with ROLE_UNKNOWN. Does this adversely effect review mode in the Linux ATs? In LSR, we can treat unknown nodes as trivial objects and skip in most situations.
> One possible fix is to expose generic nodes with ROLE_UNKNOWN In other words, if there's an ID on an element, that should be enough to expose it, even if we don't have anything else a11y-wise to map for that element.
I just realized this is actually a good quick fix to bug 395699.
Created attachment 281041 [details] [diff] [review] 1) Use proper ID getter methods, 2) If ID present, always create accessible This will also help ensure there is always an object for elements pointed to by a relation and activedescendant focus events.
Attachment #281041 - Flags: review?(ginn.chen)
Comment on attachment 281041 [details] [diff] [review] 1) Use proper ID getter methods, 2) If ID present, always create accessible r=me though I'd prefer to use nsAccUtils::SetAccAttr(). It looks nicer a bit.
Attachment #281041 - Flags: review+
Attachment #281041 - Flags: review?(ginn.chen) → approval1.9?
Attachment #281041 - Flags: approval1.9? → approval1.9+
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
I backed out the part of this fix that affects the accessible object hierarchy. it was causing bug 397032.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I think we might to change: If has an ID, create accessible to If it has an ID && (a relation || ancestor with activedescendant property), then create an accessible A thought on performance: We don't need to check all the relations necessarily, we could try to be smart about which relations we actually have to check. Checking for some relations is expensive right now (until we have code for a relation cache some day). For example, in HTML you wouldn't need to check describedby, since that would have to be created via aaa:describedby which we already check anyway. But, we would need to check description_for. In XUL weed need to check both because you might have <description control=id>
Attachment #281041 - Flags: approval1.9+
Can we close this bug after bug 395699 has been fixed?
We can't close this because a generic node with an ID won't be exposed unless it has another node pointing to it with a relation. This bug was reopened because when we tried to expose all nodes with an ID, it caused bug 397032. In general just exposing everything with an ID caused trouble. But I'd like to keep it open for future consideration. It just shouldn't block Firefox 3.
Is there a relations cache yet?
Search the bug database for "relation cache" :P It's bug 381599 :)
Mass un-assigning bugs assigned to Aaron.
Assignee: aaronleventhal → nobody
Honestly I don't understand bug description and why we'd need to follow the suggestion from comment 1 (especially if brings a problem per comment #9). Closing as incomplete, please feel free to reopen if we have to fix anything here.
Status: REOPENED → RESOLVED
Last Resolved: 11 years ago → 8 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.