New issue
Advanced search Search tips

Issue 624258 link

Starred by 3 users

Issue metadata

Status: Fixed
Owner:
Closed: Aug 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug
Team-Accessibility



Sign in to add a comment

ARIA radio setsize incorrectly calculated, includes non-radios, too large

Reported by jesse.r....@gmail.com, Jun 29 2016

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.84 Safari/537.36

Steps to reproduce the problem:
Correct behavior: https://jsbin.com/qeqebebivo/1/edit?html,output
Bad behavior: https://jsbin.com/dijoqawuyi/1/edit?html,output 

In the bad behavior example, the total number of radio items reported to the AX API, and thus output by VoiceOver, is the total number of child nodes under the radio group, resulting in inflated counts for radio items e.g. 2 of 10 when there are only three items with the role radio in the radio group.

What is the expected behavior?
In the correct behavior example, we get the following AX Tree  (the radio items are reported as 1 of 3, 2 of 3 and 3 of 3 respectively):

++++++++++AXRadioGroup AXRoleDescription='radio group' AXInvalid='false' AXEnabled='1' AXFocused='0' AXVisited='0' position=(0, 0) size=(983, 18)
++++++++++++AXRadioButton AXRoleDescription='radio' AXValue='0' AXInvalid='false' AXARIASetSize='3' AXARIAPosInSet='1' AXEnabled='1' AXFocused='0' AXTitleUIElement='AXGroup' AXVisited='0' position=(0, 0) size=(8, 18)
++++++++++++AXRadioButton AXRoleDescription='radio' AXValue='0' AXInvalid='false' AXARIASetSize='3' AXARIAPosInSet='2' AXEnabled='1' AXFocused='0' AXTitleUIElement='AXGroup' AXVisited='0' position=(0, 0) size=(8, 18)
++++++++++++AXRadioButton AXRoleDescription='radio' AXValue='0' AXInvalid='false' AXARIASetSize='3' AXARIAPosInSet='3' AXEnabled='1' AXFocused='0' AXTitleUIElement='AXGroup' AXVisited='0' position=(0, 0) size=(8, 18)

In the bad behavior example, we get the following AX Tree (the radio items are reported as 1 of 6, 3 of 6 and 5 of 6 respectively):

++++++++++AXRadioGroup AXRoleDescription='radio group' AXInvalid='false' AXEnabled='1' AXFocused='0' AXVisited='0' position=(0, 0) size=(828, 18)
++++++++++++AXRadioButton AXRoleDescription='radio' AXValue='0' AXInvalid='false' AXARIASetSize='6' AXARIAPosInSet='1' AXEnabled='1' AXFocused='0' AXTitleUIElement='AXGroup' AXVisited='0' position=(0, 0) size=(8, 18)
++++++++++++AXGroup AXRoleDescription='group' AXInvalid='false' AXEnabled='1' AXFocused='0' AXVisited='0' position=(0, 0) size=(90, 18)
++++++++++++++AXStaticText AXRoleDescription='text' AXValue='radio option 1' AXInvalid='false' AXEnabled='1' AXFocused='0' AXVisited='0' position=(0, 0) size=(90, 18)
++++++++++++AXRadioButton AXRoleDescription='radio' AXValue='0' AXInvalid='false' AXARIASetSize='6' AXARIAPosInSet='3' AXEnabled='1' AXFocused='0' AXTitleUIElement='AXGroup' AXVisited='0' position=(0, 0) size=(9, 18)
++++++++++++AXGroup AXRoleDescription='group' AXInvalid='false' AXEnabled='1' AXFocused='0' AXVisited='0' position=(0, 0) size=(91, 18)
++++++++++++++AXStaticText AXRoleDescription='text' AXValue='radio option 2' AXInvalid='false' AXEnabled='1' AXFocused='0' AXVisited='0' position=(0, 0) size=(91, 18)
++++++++++++AXRadioButton AXRoleDescription='radio' AXValue='0' AXInvalid='false' AXARIASetSize='6' AXARIAPosInSet='5' AXEnabled='1' AXFocused='0' AXTitleUIElement='AXGroup' AXVisited='0' position=(0, 0) size=(9, 18)
++++++++++++AXGroup AXRoleDescription='group' AXInvalid='false' AXEnabled='1' AXFocused='0' AXVisited='0' position=(0, 0) size=(91, 18)
++++++++++++++AXStaticText AXRoleDescription='text' AXValue='radio option 3' AXInvalid='false' AXEnabled='1' AXFocused='0' AXVisited='0' position=(0, 0) size=(91, 18)

What went wrong?
In the bad behavior example, note that within the AXRadioGroup node, we have six siblings comprised of AXRadioButton and AXGroup nodes. The AXGroup nodes reference the <label> elements and are bing counted as radio items in the group, resulting in a misleading count of six items in the radio group instead of 3. Adding any nodes to the radio group will result in an increase in the total number of radio items reported to the AX API.

Did this work before? N/A 

Chrome version: 51.0.2704.84  Channel: stable
OS Version: OS X 10.11.4
Flash Version: Shockwave Flash 22.0 r0

This is an extremely nasty bug for blind users, using VoiceOver to access forms with radio buttons.
 
Interestingly, native radio buttons don't seem to get any "grouping" behaviour at all, i.e. no "M of N" is announced.

I'm not sure this is an accessibility tree bug so much as a VoiceOver "bug" - it sees six "elements" in the group and doesn't bother to check which of them are radio buttons.

If this is an accessibility tree bug, what would a fix look like? What should be exposed instead?

Either way, would it work as a workaround to add aria-hidden to the label elements? I tried this out at https://output.jsbin.com/vajegut and it works fine for me. Not ideal since then the label isn't available to explore to, but the radio buttons are correctly labelled and numbered at least.
Huh, that is weird that the grouping only happens with the ARIA-roled radiogroup.

I tested this on in Chrome on a PC as well with JAWS -- same behavior. Here's the IA2 version of the AX Tree.

++++++++++ROLE_SYSTEM_GROUPING
++++++++++++ROLE_SYSTEM_RADIOBUTTON name='radio option 1' FOCUSABLE IA2_STATE_CHECKABLE
++++++++++++IA2_ROLE_LABEL
++++++++++++++ROLE_SYSTEM_STATICTEXT name='radio option 1'
++++++++++++ROLE_SYSTEM_RADIOBUTTON name='radio option 2' FOCUSABLE IA2_STATE_CHECKABLE
++++++++++++IA2_ROLE_LABEL
++++++++++++++ROLE_SYSTEM_STATICTEXT name='radio option 2'
++++++++++++ROLE_SYSTEM_RADIOBUTTON name='radio option 3' FOCUSABLE IA2_STATE_CHECKABLE
++++++++++++IA2_ROLE_LABEL display:inline tag:label id:js_
++++++++++++++ROLE_SYSTEM_STATICTEXT name='radio option 3'
Maybe this is a pre-Blink Webkit issue? Because I get the same behavior on Safari on OSX.
Alice and I chatted: the AX Tree in both cases looks well-structured. Perhaps both JAWS and VoiceOver and performing a too-simple count of child nodes of the group and using that as the enumeration total, rather than checking the node types and filtering for radio<option> items. I'll see if I can get some input from a JAWS dev on this. 
Definitely a Chrome bbug. The same code works fine in Firefox with all screen readers and fails in Chrome with all the same screen readers.

Best way to work around this bug is to specify aria-posinset and aria-setsize on each radio. 

Chrome should be calculating values for aria-setsize and aria-posinset and setting them as specified in the ARIA Core AAM in section 5.5.2:
http://w3c.github.io/aria/core-aam/core-aam.html

Of course it should count only elements with implied or explicit role radio inside of  a radiogroup. In native, the group can be defined by giving all radios in the same group the same value for the name attrib.
aria-posinset and aria-setsize do not help in this case. Here are two bins that illustrates the incorrect behavior:

Radios and labels are children of radiogroup: https://jsbin.com/yuvuwelovu/1/edit?html,output
Radios and labels are descendants of radiogroup: https://jsbin.com/namawipice/1/edit?html,output
Adding a name attribute to the radios does not fix the enumeration.
Interesting that this works in FF. Is someone able to get a dump of the relevant parts of their accessibility tree to compare?
The Firefox AX Tree on PC is much the same:

(none) - grouping
  radio option 1 - radio button
  (none) - editable text
    radio option 1 - text
  radio option 2 - radio button
  (none) - editable text
    radio option 2 - text
  radio option 3 - radio button
  (none) - editable text
    radio option 3 - text
Components: UI>Accessibility
Labels: -OS-Mac OS-All
Labels: NewComponent-Accessibility-Blink NewComponent-Accessibility
Components: Blink>Accessibility
Components: -UI>Accessibility
Labels: -newcomponent-accessibility-blink -newcomponent-accessibility
Labels: triage-aaron
Summary: Elements with role radio in ARIA radiogroup are not enumerated correctly in accessibility output (was: Elements with role radio in a radiogroup are not enumerated correctly in accessibility output)
Owner: aleventhal@chromium.org
Status: Available (was: Unconfirmed)
Summary: ARIA radio setsize incorrectly calculated, includes non-radios, too large (was: Elements with role radio in ARIA radiogroup are not enumerated correctly in accessibility output)
Labels: -triage-aaron
Status: Started (was: Available)
Labels: triage-dtseng
Labels: -triage-dtseng
Project Member

Comment 21 by bugdroid1@chromium.org, Aug 15 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9d972cc1907dc5bfe27174c270157939f886e6d0

commit 9d972cc1907dc5bfe27174c270157939f886e6d0
Author: Aaron Leventhal <aleventhal@chromium.org>
Date: Tue Aug 15 02:33:40 2017

Count ARIA radios properly

Do not count non-radio elements when computing radio setsize, posinset.

Bug:  624258 
Change-Id: I8f3faf6a370493e2a02ebd86ad6a94a6f579588d
Reviewed-on: https://chromium-review.googlesource.com/610840
Commit-Queue: Aaron Leventhal <aleventhal@chromium.org>
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#494308}
[modify] https://crrev.com/9d972cc1907dc5bfe27174c270157939f886e6d0/content/test/data/accessibility/aria/aria-listbox-expected-android.txt
[modify] https://crrev.com/9d972cc1907dc5bfe27174c270157939f886e6d0/content/test/data/accessibility/aria/aria-listbox-expected-blink.txt
[modify] https://crrev.com/9d972cc1907dc5bfe27174c270157939f886e6d0/content/test/data/accessibility/aria/aria-listbox-expected-mac.txt
[modify] https://crrev.com/9d972cc1907dc5bfe27174c270157939f886e6d0/content/test/data/accessibility/aria/aria-listbox-expected-win.txt
[modify] https://crrev.com/9d972cc1907dc5bfe27174c270157939f886e6d0/content/test/data/accessibility/aria/aria-listbox.html
[modify] https://crrev.com/9d972cc1907dc5bfe27174c270157939f886e6d0/content/test/data/accessibility/html/optgroup-expected-blink.txt
[modify] https://crrev.com/9d972cc1907dc5bfe27174c270157939f886e6d0/content/test/data/accessibility/html/optgroup.html
[modify] https://crrev.com/9d972cc1907dc5bfe27174c270157939f886e6d0/third_party/WebKit/LayoutTests/accessibility/aria-setsize-posinset-expected.txt
[modify] https://crrev.com/9d972cc1907dc5bfe27174c270157939f886e6d0/third_party/WebKit/LayoutTests/accessibility/aria-setsize-posinset.html
[modify] https://crrev.com/9d972cc1907dc5bfe27174c270157939f886e6d0/third_party/WebKit/LayoutTests/accessibility/aria-tree.html
[modify] https://crrev.com/9d972cc1907dc5bfe27174c270157939f886e6d0/third_party/WebKit/Source/modules/accessibility/AXNodeObject.cpp
[modify] https://crrev.com/9d972cc1907dc5bfe27174c270157939f886e6d0/third_party/WebKit/Source/modules/accessibility/AXNodeObject.h

Status: Fixed (was: Started)
Updated auto setsize and posinset algroithms in a number of ways, to match Firefox impl:
- Only count other siblings with same role
- Stop at separators
- Be smart about level, e.g. in a tree
- Don't count hidden/presentational elements

Thank you!

Sign in to add a comment