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.
This is related to <rdar://problem/12476099>.
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
Created attachment 205131 [details] Patch
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?
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
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
Created attachment 205147 [details] Updated with Mac results
(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.
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
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
This EWS failure does not occur on local Windows builds.
Committed r151841: <http://trac.webkit.org/changeset/151841>