371156 - id obj. attr. missing

Status: RESOLVED INCOMPLETE

(Core :: Disability Access APIs, defect)

Description

[parente]

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.

Comment 1

[Aaron Leventhal]

> 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.

Comment 2

[Aaron Leventhal]

I just realized this is actually a good quick fix to bug 395699.

Comment 3

[Aaron Leventhal]

I just realized this is actually a good quick fix to bug 395699.

Comment 4

[Aaron Leventhal]

Attachment: 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.

Comment 5

[alexander :surkov (:asurkov)]

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.

Comment 6

[Aaron Leventhal]

I backed out the part of this fix that affects the accessible object hierarchy. it was causing bug 397032.

Comment 7

[Aaron Leventhal]

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>

Comment 8

[Evan Yan]

Can we close this bug after bug 395699 has been fixed?

Comment 9

[Aaron Leventhal]

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.

Comment 10

[David Bolter [:davidb] (NeedInfo me for attention)]

Is there a relations cache yet?

Comment 11

[Aaron Leventhal]

Search the bug database for "relation cache" :P

It's bug 381599 :)

Comment 12

[David Bolter [:davidb] (NeedInfo me for attention)]

Mass un-assigning bugs assigned to Aaron.

Comment 13

[alexander :surkov (:asurkov)]

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.