Bug 117837 – [Windows] AX: Radio buttons with "tab" role should describe themselves as tabs

• Component: Accessibility
• Status: RESOLVED FIXED

[Brent Fulgham]

The Windows accessibility layer is blindly reporting its accessibility role based on the specific rendering object used to implement the feature in the browser.  This breaks down in the specific case of a set of radio buttons contained in a 'role="tablist"' marked with an accessibility 'role="tab"'.  We should be speaking "tab" in this case, as that is the intent of the mark-up.

Currently we speak "radio button", which is inaccurate.

[Brent Fulgham]

This is related to <rdar://problem/12476099>.

[Brent Fulgham]

Before the attached patch, we would show the following result:
========================================================
Tab A  Tab B  Tab C
This tests that the aria roles for tab and tablist work as expected for buttons.

On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE".


tabList.role = page tab list
tab1.role = radio button
tab1.title = Tab A
PASS tab1.childrenCount is 0
tab2.role = radio button
tab2.title = Tab B
PASS successfullyParsed is true

TEST COMPLETE
========================================================
Tab A  Tab B  Tab C
This tests that the aria roles for tab and tablist work as expected for buttons.

On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE".


tabList.role = page tab list
tab1.role = page tab
tab1.title = Tab A
PASS tab1.childrenCount is 0
tab2.role = page tab
tab2.title = Tab B
PASS successfullyParsed is true

TEST COMPLETE

[Brent Fulgham]

Created attachment 205131 [details]
Patch

[chris fleizach]

Comment on attachment 205131 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=205131&action=review

> Source/WebCore/accessibility/AccessibilityNodeObject.h:103
> +    virtual bool canSetSelectedAttribute() const OVERRIDE;

I don't see anyone calling this method. Is it necessary?

[Build Bot]

Comment on attachment 205131 [details]
Patch

Attachment 205131 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.appspot.com/results/918438

New failing tests:
accessibility/aria-tab-role-on-buttons.html

[Build Bot]

Created attachment 205145 [details]
Archive of layout-test-results from webkit-ews-06 for mac-mountainlion

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-06  Port: mac-mountainlion  Platform: Mac OS X 10.8.3

[Brent Fulgham]

Created attachment 205147 [details]
Updated with Mac results

[Brent Fulgham]

(In reply to comment #4)
> (From update of attachment 205131 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=205131&action=review
> 
> > Source/WebCore/accessibility/AccessibilityNodeObject.h:103
> > +    virtual bool canSetSelectedAttribute() const OVERRIDE;
> 
> I don't see anyone calling this method. Is it necessary?

Yes.  It's used by WebKit\win\AccessibleBase.cpp to expose the "Selectable" state to the accessibility layer.  Without this, NVDA and the accessibility inspector don't recognize that the tab pane is selectable, and don't properly support using the space bar to activate the tab.

[Build Bot]

Comment on attachment 205147 [details]
Updated with Mac results

Attachment 205147 [details] did not pass win-ews (win):
Output: http://webkit-queues.appspot.com/results/858835

New failing tests:
fast/frames/seamless/seamless-nested-crash.html

[Build Bot]

Created attachment 205166 [details]
Archive of layout-test-results from APPLE-EWS-4 for win-future

The attached test failures were seen while running run-webkit-tests on the win-ews.
Bot: APPLE-EWS-4  Port: win-future  Platform: CYGWIN_NT-6.1-WOW64-1.7.20-0.266-5-3-i686-32bit

[Brent Fulgham]

This EWS failure does not occur on local Windows builds.

[Brent Fulgham]

Committed r151841: <http://trac.webkit.org/changeset/151841>