Closed Bug 390154 Opened 13 years ago Closed 13 years ago

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

Categories

(Core :: Disability Access APIs, defect)

x86
Linux
defect
Not set

Tracking

()

RESOLVED FIXED

People

(Reporter: scott, Assigned: aaronlev)

References

(Blocks 2 open bugs)

Details

(Keywords: access)

Attachments

(4 files, 1 obsolete file)

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

Keywords: access
Summary: Accessible hierarchy inconsistent for ARIA buttons → ATK hierarchy inconsistent for ARIA buttons
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?
This testcase shows that the issue is with buttons in general, not just ARIA buttons.
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
Note, for XUL you can click.
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.
Depends on: 390280
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.
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.
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?
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?
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.
So you're certain you want us to flatten the tree for buttons right?
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.
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.
Summary: ATK hierarchy inconsistent for ARIA buttons → Should ATK hierarchy for widgets that are normally leaves be able to contain a subtree?
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.
Blocks: aria
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?
Attachment #276673 - Flags: review?(ginn.chen)
Aaron, I think that list is a good start. We can always change our minds later correct?
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.
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.
I'm not sure about spinner. Aren't the arrow buttons children?
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.
Attachment #276692 - Attachment is obsolete: true
Attachment #276692 - Flags: review?(ginn.chen)
Attachment #276673 - Flags: review?(ginn.chen) → review+
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.
Attachment #276673 - Flags: approval1.9?
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
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.
Attachment #276673 - Flags: approval1.9? → approval1.9+
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Some occurrances of IsFlat() were not converted to MustPrune.
Attachment #276853 - Flags: review?(aaronleventhal)
Attachment #276853 - Flags: review?(aaronleventhal) → review+
You need to log in before you can comment on or make changes to this bug.