Bug 73822 - [Gtk] Dojo color-chooser menu items should expose ROLE_MENU_ITEM (or do something to identify themselves more clearly to ATs)
Summary: [Gtk] Dojo color-chooser menu items should expose ROLE_MENU_ITEM (or do somet...
Status: UNCONFIRMED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Accessibility (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Linux
: P2 Normal
Assignee: Nobody
URL: http://archive.dojotoolkit.org/nightl...
Keywords: Gtk
Depends on:
Blocks: 30796
  Show dependency treegraph
 
Reported: 2011-12-05 04:26 PST by Joanmarie Diggs
Modified: 2017-03-11 10:57 PST (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Joanmarie Diggs 2011-12-05 04:26:43 PST
The Dojo color-chooser menu items found on this test page [1] currently claim to be of ROLE_TABLE_CELL. Since these items are functioning like menu items it would be extremely helpful if they would claim to be of ROLE_MENU_ITEM.

Failing that.... There does not seem to be anything which connects them to the pop-up menu which contains them, and/or to the button which cased them to be popped up: The accessible parent of these items is a table whose accessible parent is a panel. And the parent of that panel is the accessible document frame. Without any way of knowing what these table cells are, or why they are, an AT will have a hard time knowing if and how to present them to the user.

[1] http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/form/test_Button.html
Comment 1 Alejandro Piñeiro 2012-08-22 10:29:53 PDT
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
Comment 2 Joanmarie Diggs 2012-08-22 11:04:49 PDT
(In reply to comment #1)
 
> 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?

Please do not close this bug out. Please do file a bug against the Dojo toolkit [1] pointing to this bug and consider this bug "blocked" pending them fixing the issue on their end. Then we'll have an html page that is using the stuff properly. :)

And while I normally would be skeptical that <insert random toolkit here> could be counted on to fix these sorts of things, I think Dojo is different. Their generic/for-everyone documentation about why use Dojo/Dijit [2] begins with "One of the great features of dijit is the fact that it is all ready for a11y (accessibility)". And they have a full Accessibility statement here [3]. So they're the GoodGuys(tm) and would be an excellent toolkit to demonstrate WebKit ARIA accessibility with.

Thanks for digging into all this!!

[1] http://bugs.dojotoolkit.org/
[2] http://dojotoolkit.org/reference-guide/1.6/quickstart/interfacedesign.html
[3] https://dojotoolkit.org/reference-guide/1.8/dijit/a11y/statement.html
Comment 3 Alejandro Piñeiro 2012-08-23 04:50:36 PDT
(In reply to comment #2)

> > CCed people, opinions?
> 
> Please do not close this bug out. Please do file a bug against the Dojo toolkit [1] pointing to this bug and consider this bug "blocked" pending them fixing the issue on their end. Then we'll have an html page that is using the stuff properly. :)

Done:

http://bugs.dojotoolkit.org/ticket/15885

> 
> And while I normally would be skeptical that <insert random toolkit here> could be counted on to fix these sorts of things, I think Dojo is different. Their generic/for-everyone documentation about why use Dojo/Dijit [2] begins with "One of the great features of dijit is the fact that it is all ready for a11y (accessibility)". And they have a full Accessibility statement here [3]. So they're the GoodGuys(tm) and would be an excellent toolkit to demonstrate WebKit ARIA accessibility with.

Good, lets wait until they solve that bug, and after that I can resume the work on this bug.
Comment 4 Alejandro Piñeiro 2012-12-14 05:13:58 PST
(In reply to comment #3)

> 
> Done:
> 
> http://bugs.dojotoolkit.org/ticket/15885
> 

> 
> Good, lets wait until they solve that bug, and after that I can resume the work on this bug.

FWIW: this bug are in theory solved, so I should be able to resume the work on this bug. Noting down just to not forget.