Closed
Bug 363628
Opened 19 years ago
Closed 19 years ago
Support new ARIA relations (owns and hasparent)
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: aaronlev, Assigned: aaronlev)
References
(Blocks 1 open bug)
Details
(Keywords: access)
Attachments
(1 file)
|
3.19 KB,
patch
|
surkov
:
review+
davidb
:
review+
|
Details | Diff | Splinter Review |
Spinoff of bug 363617.
We need to support the owns=[idrefs] relation, as well as hasparent=[idref].
Owns can have more than 1 item, hasparent can contain only 1 ID.
We need to figure out which AT-SPI relatiosn we should use for each. Here are the possibilities:
RELATION_MEMBER_OF
RELATION_NODE_CHILD_OF
RELATION_SUBWINDOW_OF
RELATION_EMBEDS
RELATION_EMBEDDED_BY
RELATION_POPUP_FOR
RELATION_PARENT_WINDOW_OF
Definitions of owns and haspopup here:
http://www.w3.org/WAI/PF/Group/adaptable/
Definitions of AT-SPI relations here:
http://www.gnome.org/~billh/at-spi-idl/html/namespaceAccessibility.html#a215
This is an excellent time to generally ensure that the vision for AT-SPI relations is compatible with ARIA relations. Not only for owns and haspopup, but also for flowsto and flowsfrom, which I still find vague.
| Assignee | ||
Comment 1•19 years ago
|
||
We also need to make sure that the ARIA menu handling code can follow hasparent, and that the tree level and position code can use owns.
| Assignee | ||
Comment 2•19 years ago
|
||
Note from the other bug:
These properties are similar but the inverse of each other.
In fact "hasparent" should be renamed "parentedby" or "ownedby". Naming it
similar to "haspopup" is confusing since haspopup is a boolean.
In fact, I'm not sure we need hasparent/parentedby/ownedby when we have owns.
Summary: Support new ARIA relations → Support new ARIA relations (owns and hasparent)
| Assignee | ||
Comment 4•19 years ago
|
||
Attachment #258706 -
Flags: review?(surkov.alexander)
| Assignee | ||
Comment 5•19 years ago
|
||
Comment on attachment 258706 [details] [diff] [review]
Implement owns using NODE_CHILD_OF
ARIA and ATK/IA2 use opposite relations for the same thing.
In ARIA owns points to the objects that are out of flow and aren't quite children. This is useful for trees and diagrams.
In ATK it goes the other direction. The external children point to what owns them using NODE_CHILD_OF.
Attachment #258706 -
Flags: review?(david.bolter)
Comment 6•19 years ago
|
||
I'm thinking is it ID attribute with white spaces is valid attribute?
| Assignee | ||
Comment 7•19 years ago
|
||
I don't know, but the ARIA spec requires that you can point to multiple IDs.
These relations need it:
aaa:owns
aaa:controls
aaa:controlledby
aaa:describedby
aaa:flowto
Updated•19 years ago
|
Attachment #258706 -
Flags: review?(surkov.alexander) → review+
Comment 8•19 years ago
|
||
Comment on attachment 258706 [details] [diff] [review]
Implement owns using NODE_CHILD_OF
I'm not sure how expensive the attribute id search is. The patch looks ok to me. It appears there is an assumption that the related nodes are in the same tree?
Attachment #258706 -
Flags: review?(david.bolter) → review+
| Assignee | ||
Comment 9•19 years ago
|
||
Right, the related nodes are in the same tree.
Probably compared with the cross process communication we do, the attribute search is not too expensive. It's currently optimized for nodes that are nearby in the DOM, but of course when nothing points to the current element, which is often the case, it's expensive. If ATs needed to check RELATION_NODE_CHILD_OF for everything it probably would cost a lot.
To make it more performant we would need some kind of caching mechanism, but we have higher priorities and it's not proven we need it.
| Assignee | ||
Updated•19 years ago
|
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•