RESOLVED FIXED 117837
[Windows] AX: Radio buttons with "tab" role should describe themselves as tabs
https://bugs.webkit.org/show_bug.cgi?id=117837
Summary [Windows] AX: Radio buttons with "tab" role should describe themselves as tabs
Brent Fulgham
Reported 2013-06-20 10:39:07 PDT
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.
Attachments
Patch (6.87 KB, patch)
2013-06-20 17:20 PDT, Brent Fulgham
no flags
Archive of layout-test-results from webkit-ews-06 for mac-mountainlion (502.01 KB, application/zip)
2013-06-20 21:24 PDT, Build Bot
no flags
Updated with Mac results (7.72 KB, patch)
2013-06-20 22:14 PDT, Brent Fulgham
cfleizach: review+
buildbot: commit-queue-
Archive of layout-test-results from APPLE-EWS-4 for win-future (798.24 KB, application/zip)
2013-06-21 03:15 PDT, Build Bot
no flags
Brent Fulgham
Comment 1 2013-06-20 10:40:27 PDT
This is related to <rdar://problem/12476099>.
Brent Fulgham
Comment 2 2013-06-20 17:08:34 PDT
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
Comment 3 2013-06-20 17:20:00 PDT
chris fleizach
Comment 4 2013-06-20 17:50:43 PDT
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 5 2013-06-20 21:24:24 PDT
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
Comment 6 2013-06-20 21:24:25 PDT
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
Comment 7 2013-06-20 22:14:18 PDT
Created attachment 205147 [details] Updated with Mac results
Brent Fulgham
Comment 8 2013-06-20 22:49:04 PDT
(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 9 2013-06-21 03:15:53 PDT
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
Comment 10 2013-06-21 03:15:55 PDT
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
Comment 11 2013-06-21 09:30:27 PDT
This EWS failure does not occur on local Windows builds.
Brent Fulgham
Comment 12 2013-06-21 09:37:05 PDT
Note You need to log in before you can comment on or make changes to this bug.