390154 - Should ATK hierarchy for widgets that are normally leaves be able to contain a subtree?

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Scott Haeger]

The accessible hierarchy is inconsistent for ARIA buttons and perhaps other widget types as well.  Looking at the examples linked from http://developer.mozilla.org/en/docs/Accessible_DHTML#Supported_roles and the dojo example at http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/form/test_Button.html shows that buttons often have children.  This is inconsistent from HTML and GTK+ widgets where I have never seen a button with children.  The children seen are often paragraphs, but I have seen BUTTONS as well.

Comment 1

[Simon Bates]

Aaron's patch [https://bugzilla.mozilla.org/attachment.cgi?id=273396] on https://bugzilla.mozilla.org/show_bug.cgi?id=382247 may address this.

Comment 2

[alexander :surkov (:asurkov)]

HTML and XUL buttons can contain anything.

IIRC Hakan had a point mac buttons doesn't have a children, but it's only for mac I guess?

Comment 3

[Aaron Leventhal]

Windows buttons don't want anything either -- that's what Simon pointed us to in comment 1: the code which prunes subtrees for certain objects on Windows.

I don't think we have similar code for Linux, except that it prunes text leaf objects only. Therefore images and other object subtrees would show up. Perhaps MustPrune() needs to be cross-platform.

Comment 4

[Aaron Leventhal]

And as Surkov mentioned, buttons can have anything. So, we either have to decide that:
1) We should make MustPrune() cross platform, and don't worry about weird cases where buttons have anything
2) There are legitimate cases when a button will have a complex subtree, and Orca needs to deal with that.

Scott, keep in mind that in HTML you can have:
<button>Anything</button>

Anyone care to put together some examples?

Comment 5

[Aaron Leventhal]

Attachment: Complex HTML (not ARIA) buttons

This testcase shows that the issue is with buttons in general, not just ARIA buttons.

Comment 6

[Aaron Leventhal]

Attachment: XHTML testcase with working inner widgets inside of buttons, and MathML inside button

Notes:
- You cannot click on the inner textbox, link or button, but you can tab to them
- The MathML is not rendered correctly in Firefox 3, but is in Firefox 2
- We have not decided how to expose MathML yet in Firefox

Comment 7

[alexander :surkov (:asurkov)]

Note, for XUL you can click.

Comment 8

[Aaron Leventhal]

Note that we're adding infrastructure in bug 390280 that would make this easier to do, but because of testcase added in comment 6 I'm not sure we want to do it.

Comment 9

[Scott Haeger]

Similar problems can be seen for these sliders http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/form/test_Slider.html and these tables http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/test_Table.html .  I am not sure if they are related to this bug, but I thought I would point them out.

Comment 10

[Aaron Leventhal]

I understand the slider problem -- I suppose for that one we might want to force it to be a leaf, otherwise the author would have to put role="presentation" on the images they use.

But, what's the problem with the table? Table cells can certainly contain anything in HTML. That's not an ARIA thing. That's just HTML.

Comment 11

[Scott Haeger]

On second look the table looks fine.  Strange, the accessible tree seems different than when I first looked at it.

How about these spinners http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/form/test_Spinner.html .  The arrows are 'section's in the accessible tree.  Should they appear there?

Comment 12

[Aaron Leventhal]

Spinners: No, they shouldn't. Please file a separate bug on that and cc the Dojo folks.

For this bug, can you look at the last test case and give your opinion about whether we should flatten the tree or expose what's really inside the buttons?

Comment 13

[Scott Haeger]

That last button is sure a strange beast.  Although I don't have any compelling reason why, this may be one case where we should expose what's really inside the button.

Comment 14

[Aaron Leventhal]

So you're certain you want us to flatten the tree for buttons right?

Comment 15

[Scott Haeger]

You have shown cases where I can see the value of not flattening the tree.  However, I don't want to see cases which are clearly wrong, such as a button as a child of a button.  I say flatten the best you can and Orca will handle complex situations.

Comment 16

[Aaron Leventhal]

I'm just not sure what the rule should be. It's definitely easiest just to reflect reality to Orca, and let Orca deal with the fact that reality is a strange beast.

If you want we can make things nicer than what they really are, but we're no longer reflecting what's actually happening.

Again, this isn't ARIA-specific, so I want to change the bug summary.

Comment 17

[Scott Haeger]

This bug shines light on the bigger issue of what objects make up a widget and how best to represent that structure in the ATK hierarchy.  In cases like the button, where all objects are direct descendants of the button, showing reality will probably suffice.  I am more concerned about cases like the combobox http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/form/test_ComboBox.html where objects that make up the widget are outside comboboxes hierarchy.

Comment 18

[Aaron Leventhal]

Attachment: Unify MustPrune() -- prune the same objects on each platform

I think for the following widgets we gain more by pruning (in terms of AT compatibility) than we lose by not supporting really insane widget containment:
MENUITEM || ENTRY || PASSWORD_TEXT || PUSHBUTTON || TOGGLE_BUTTON || GRAPHIC || SLIDER ||  PROGRESSBAR || SEPARATOR;

Scott, does that look like a good list to you?

Comment 19

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

Aaron, I think that list is a good start. We can always change our minds later correct?

Comment 20

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

Of course changing our minds does have a cost. Particularly on the AT side. Hmmm. For what it is worth, I was leaning toward just reflecting reality (strange beast it may be). Just my 2 cents.

Comment 21

[Scott Haeger]

I think the list is a good start, but maybe add spinners.  It seems that the more complicate widgets, sliders, comboboxes, and spinners, benefit the very most from an AT's perspective because it is less objects we must iterate through to get useful content.

Comment 22

[Aaron Leventhal]

I'm not sure about spinner. Aren't the arrow buttons children?

Comment 23

[Aaron Leventhal]

Attachment: Reintrouce them -- they will be collated if they all occur in the same subtree

Comment 24

[Aaron Leventhal]

Comment on attachment 276692 [details] [diff] [review]
Reintrouce them -- they will be collated if they all occur in the same subtree

Wrong bug for this patch.

Comment 25

[Aaron Leventhal]

Comment on attachment 276673 [details] [diff] [review]
Unify MustPrune() -- prune the same objects on each platform

Hi David, I register your concern, but I have run into quite a few situations where screen readers double-speak objects when they see contents in them that match the accessible name. This is easier than changing 5 screen readers, and those edge cases are extremely edge -- never seen thim in rela life.

Comment 26

[Scott Haeger]

The spinner arrows are not children of the spinner accessible object.  Here is my test page http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/form/test_Spinner.html

Comment 27

[Aaron Leventhal]

Thanks. Spinners are not part of it in that case, which is arguably correct, but I'm not 100% certain. I'd like to think about it more before adding spinner. In any case, if the author does them separately, there doesn't seem to be a need to prune the subtree for spinners anyway. So I think we're okay for now.

Comment 28

[Håkan Waara]

Attachment: Fix bustage on mac

Some occurrances of IsFlat() were not converted to MustPrune.