[Webkit-unassigned] [Bug 73822] [Gtk] Dojo color-chooser menu items should expose ROLE_MENU_ITEM (or do something to identify themselves more clearly to ATs)

Wed Aug 22 10:29:55 PDT 2012

https://bugs.webkit.org/show_bug.cgi?id=73822

Alejandro Piñeiro <apinheiro at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |apinheiro at igalia.com,
                   |                            |msanchez at igalia.com

--- Comment #1 from Alejandro Piñeiro <apinheiro at igalia.com>  2012-08-22 10:29:53 PST ---
I have been taking a look to this bug, dojo example html, current webkit code, and w3 refenrence, so I think that it is a good moment to share some initial thoughts.

First, I don't see a easy way to change the role of the cells in order to have menu items. The role of the elements are grid cell, and I don't see anything that could inform us that are being used as menu items.

Looking at the w3 reference, I found a way to relate one with the other, using ARIA. The problem is that the specific example is not using properly ARIA. How this should work in an ARIA friendly html:

That Color chooser button is using aria-haspopup, as the color chooser table appear as a popup. From here [1]:

"aria-haspopup (property)
...
Value true:    Indicates the object has a popup, either as a descendant or pointed to by aria-owns."

The Dojo example is a case where the popup is not a descendant, so the html should be using aria-owns with that table. But Dojo example is wrong. It is using aria-haspopup, the table is not a descendant, but aria-owns is not there. I have found some examples of how to use that combination [3].

So, if Dojo were using aria-owns this bug would be solved? Taking a look to the code, no. WebCore accessibility objects supports aria-owns. AccessibilityObject has a method called ariaOwnsElements. This method returns the objects listed by aria-owns. mac port include some support to expose this method, but nothing else. I guess that the idea is that any AT tool on Mac could ask for those elements.

Gtk port doesn't do anything with that method. But we could use that list. The obvious (to me) solution would be set the relationship ATK_RELATION_POPUP_FOR [5] between the elements returned by ariaOwnsElements and the "parent" node.

Anyway, as I said, Dojo is not using aria-owns, so implementing that wouldn't solve the problem. So I'm not sure if we should just close this bug (as that html is not aria compliant with respect to this problem) and wait for an html page that is using properly all that stuff (so we would require to implement the other stuff).

CCed people, opinions?

Note: while looking at w3 documentation I also found aria-controls. For me it is not clear the difference between one and the other. There are some examples of when use one or the other, but for me it is not clear why do you need both aria-controls and aria-owns.

[1] http://www.w3.org/TR/wai-aria/states_and_properties#aria-haspopup
[2] http://www.w3.org/TR/wai-aria/states_and_properties#aria-owns
[3] http://www.punkchip.com/2010/11/aria-basic-findings/
[4] http://www.w3.org/TR/wai-aria/states_and_properties#aria-controls
[5] http://developer.gnome.org/atk/stable/AtkRelation.html#AtkRelationType

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.