RESOLVED FIXED 170475
AX: On generic container elements, WebKit should distinguish between tooltip (e.g. @title) and label (e.g. @aria-label) attributes
https://bugs.webkit.org/show_bug.cgi?id=170475
Summary AX: On generic container elements, WebKit should distinguish between tooltip ...
James Craig
Reported 2017-04-04 15:05:46 PDT
AX: On generic container elements, WebKit should distinguish between tooltip (e.g. @title) and accessible label (e.g. @aria-label) attributes On containers (WebCore GroupRole, etc. not leaf nodes or explicit roles like abbr, fieldset>summary, etc.) the tooltip attributes (e.g. @title) should be exposed as AXHelp not AXTitle. WebKit exposes generic containers <div title="foo"> as indistinguishable in the APIs from containers that use a more explicit label attribute, including ARIA global attributes (<div aria-label="foo">) so AT can't distinguish these in the user context. Currently the Accessibility Name Computation (formerly known as ARIA Name Computation) defines explicit rules for using tooltip attributes the role is defined (<main>, <div role="group">, etc.) but does not distinguish when the role is undefined on an semantically meaningless element like <div> with no explicit ARIA role. Therefore I think it will be safe to make this change on GroupRole (<div>), but not make it on other semantic containers like ApplicationGroupRole (<div role="group">)
Attachments
patch (8.36 KB, patch)
2017-07-18 12:15 PDT, chris fleizach
no flags
patch (8.35 KB, patch)
2017-07-18 17:35 PDT, chris fleizach
no flags
patch (7.40 KB, patch)
2017-07-26 00:00 PDT, chris fleizach
jdiggs: review+
patch for updated comments (7.41 KB, patch)
2017-09-11 08:45 PDT, chris fleizach
buildbot: commit-queue-
Archive of layout-test-results from ews100 for mac-elcapitan (1.37 MB, application/zip)
2017-09-11 09:52 PDT, Build Bot
no flags
Archive of layout-test-results from ews106 for mac-elcapitan-wk2 (1.50 MB, application/zip)
2017-09-11 09:57 PDT, Build Bot
no flags
patch for updated comments (7.47 KB, patch)
2017-09-11 09:59 PDT, chris fleizach
buildbot: commit-queue-
Archive of layout-test-results from ews103 for mac-elcapitan (1.59 MB, application/zip)
2017-09-11 10:40 PDT, Build Bot
no flags
Archive of layout-test-results from ews105 for mac-elcapitan-wk2 (1.71 MB, application/zip)
2017-09-11 10:46 PDT, Build Bot
no flags
patch for updated comments (7.51 KB, patch)
2017-09-11 10:49 PDT, chris fleizach
buildbot: commit-queue-
Archive of layout-test-results from ews105 for mac-elcapitan-wk2 (1.64 MB, application/zip)
2017-09-11 11:40 PDT, Build Bot
no flags
Archive of layout-test-results from ews100 for mac-elcapitan (1.50 MB, application/zip)
2017-09-11 11:54 PDT, Build Bot
no flags
Archive of layout-test-results from ews114 for mac-elcapitan (2.12 MB, application/zip)
2017-09-11 12:18 PDT, Build Bot
no flags
patch for updated comments (7.50 KB, patch)
2017-09-11 13:47 PDT, chris fleizach
no flags
patch for landing (7.50 KB, patch)
2017-09-11 16:48 PDT, chris fleizach
no flags
Radar WebKit Bug Importer
Comment 1 2017-04-04 15:21:57 PDT
chris fleizach
Comment 2 2017-07-18 12:15:05 PDT
Build Bot
Comment 3 2017-07-18 12:16:17 PDT
Attachment 315812 [details] did not pass style-queue: ERROR: Source/WebCore/accessibility/AccessibilityNodeObject.cpp:1566: Weird number of spaces at line-start. Are you using a 4-space indent? [whitespace/indent] [3] ERROR: Source/WebCore/accessibility/AccessibilityNodeObject.cpp:1582: When wrapping a line, only indent 4 spaces. [whitespace/indent] [3] Total errors found: 2 in 6 files If any of these errors are false positives, please file a bug against check-webkit-style.
chris fleizach
Comment 4 2017-07-18 17:35:18 PDT
Joanmarie Diggs
Comment 5 2017-07-18 22:54:10 PDT
Comment on attachment 315863 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=315863&action=review > Source/WebCore/accessibility/AccessibilityNodeObject.cpp:1576 > + case ParagraphRole: I'm not 100% sure we want to say ParagraphRole is "semantically unimportant." Though strictly for the purpose of where to expose the title attribute on a ParagraphRole, I agree that it's no different from DivRole. So I wonder if a tweak to the function name is called for. Regardless of the function name, this doesn't appear to include spans (inline or block). And what should happen with style format groups? In the latter case, even if no code change is needed here, I still think it would be worth adding some test cases for them. Were it me, I'd probably also get James to weigh in on the style format group question because in a different context (roledescription sans ARIA role) he indicated that the 'code' element was semantically meaningful. But I'm not sure he would say the same about the 'pre' element. And I'd have to look at the spec and/or check with James myself to see if, for the purpose of the title attribute exposure, 'pre' and 'code' are like 'div' or not.
chris fleizach
Comment 6 2017-07-19 00:11:00 PDT
James, can you comment which roles you think should participate in title attribute nullification?
James Craig
Comment 7 2017-07-25 12:07:26 PDT
Comment on attachment 315863 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=315863&action=review >> Source/WebCore/accessibility/AccessibilityNodeObject.cpp:1576 >> + case ParagraphRole: > > I'm not 100% sure we want to say ParagraphRole is "semantically unimportant." Though strictly for the purpose of where to expose the title attribute on a ParagraphRole, I agree that it's no different from DivRole. So I wonder if a tweak to the function name is called for. > > Regardless of the function name, this doesn't appear to include spans (inline or block). And what should happen with style format groups? In the latter case, even if no code change is needed here, I still think it would be worth adding some test cases for them. > > Were it me, I'd probably also get James to weigh in on the style format group question because in a different context (roledescription sans ARIA role) he indicated that the 'code' element was semantically meaningful. But I'm not sure he would say the same about the 'pre' element. And I'd have to look at the spec and/or check with James myself to see if, for the purpose of the title attribute exposure, 'pre' and 'code' are like 'div' or not. I agree with Joanie that the change here could be: 1. Change the name to something more explicit like ignoreTitleOnRole(). 2. Remove ParagraphRole. 3. Add InlineRole and UnknownRole. We can address the other potentially ignorable roles individually in other patches.
James Craig
Comment 8 2017-07-25 12:12:36 PDT
Comment on attachment 315863 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=315863&action=review >>> Source/WebCore/accessibility/AccessibilityNodeObject.cpp:1576 >>> + case ParagraphRole: >> >> I'm not 100% sure we want to say ParagraphRole is "semantically unimportant." Though strictly for the purpose of where to expose the title attribute on a ParagraphRole, I agree that it's no different from DivRole. So I wonder if a tweak to the function name is called for. >> >> Regardless of the function name, this doesn't appear to include spans (inline or block). And what should happen with style format groups? In the latter case, even if no code change is needed here, I still think it would be worth adding some test cases for them. >> >> Were it me, I'd probably also get James to weigh in on the style format group question because in a different context (roledescription sans ARIA role) he indicated that the 'code' element was semantically meaningful. But I'm not sure he would say the same about the 'pre' element. And I'd have to look at the spec and/or check with James myself to see if, for the purpose of the title attribute exposure, 'pre' and 'code' are like 'div' or not. > > I agree with Joanie that the change here could be: > > 1. Change the name to something more explicit like ignoreTitleOnRole(). > 2. Remove ParagraphRole. > 3. Add InlineRole and UnknownRole. > > We can address the other potentially ignorable roles individually in other patches. Actually, including the other two might regress <abbr> and <acronym>. What about shipping this patch with only GroupRole support and including the others later... E.g. InlineRole could be added after separating <abbr> and <acronym> into a new AbbreviationRole.
James Craig
Comment 9 2017-07-25 12:18:54 PDT
Joanie wrote: > in a different context (roledescription sans ARIA role) [James] indicated that the 'code' element was semantically meaningful. That comment was partially theoretical. For example, we don't currently, but we could pass the "code" context along to the speech engine to help with pronunciation, which would allow more fine-grained speech control than you can do with author-provided CSS Speech. Ditto for the different form element types: tel, etc.
chris fleizach
Comment 10 2017-07-26 00:00:52 PDT
chris fleizach
Comment 11 2017-07-26 09:21:24 PDT
(In reply to Joanmarie Diggs (irc: joanie) from comment #5) > Comment on attachment 315863 [details] > patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=315863&action=review > > > Source/WebCore/accessibility/AccessibilityNodeObject.cpp:1576 > > + case ParagraphRole: > > I'm not 100% sure we want to say ParagraphRole is "semantically > unimportant." Though strictly for the purpose of where to expose the title > attribute on a ParagraphRole, I agree that it's no different from DivRole. > So I wonder if a tweak to the function name is called for. > > Regardless of the function name, this doesn't appear to include spans > (inline or block). And what should happen with style format groups? In the > latter case, even if no code change is needed here, I still think it would > be worth adding some test cases for them. > > Were it me, I'd probably also get James to weigh in on the style format > group question because in a different context (roledescription sans ARIA > role) he indicated that the 'code' element was semantically meaningful. But > I'm not sure he would say the same about the 'pre' element. And I'd have to > look at the spec and/or check with James myself to see if, for the purpose > of the title attribute exposure, 'pre' and 'code' are like 'div' or not. Updated patch
Joanmarie Diggs
Comment 12 2017-07-27 02:41:56 PDT
Comment on attachment 316433 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=316433&action=review r+ BUT it would be great if you could tweak the test to use the shared-platform-friendlier helper methods mentioned inline. Thanks in advance! > LayoutTests/accessibility/title-tag-on-unimportant-elements-is-help-text.html:23 > + shouldBe("accessibilityController.accessibleElementById('div1').helpText", "'AXHelp: test1'"); Your platform's "AXHelp" is my platform's "description" is the W3C AccName spec's "description". A while back, I added some methods to resources/accessibility-helper.js to address this very issue. For the above test case, platformValueForW3CDescription() should do it: https://trac.webkit.org/browser/trunk/LayoutTests/resources/accessibility-helper.js#L53. If you want to keep the shouldBe() and have a single, shared expectations file, then the default value for the includeSource argument is what you want, though it will cause the "AXHelp: " prefix to be dropped. If you want to preserve the "AXHelp: " prefix for your platform, setting includeSource to true will accomplish that, though shouldBe() would need to be replaced with debug() so platform-specific expectations can be created by gardeners. > LayoutTests/accessibility/title-tag-on-unimportant-elements-is-help-text.html:24 > + shouldBe("accessibilityController.accessibleElementById('div1').description", "'AXDescription: '"); Ditto, but platformValueForW3CName(). https://trac.webkit.org/browser/trunk/LayoutTests/resources/accessibility-helper.js#L38
chris fleizach
Comment 13 2017-09-11 08:45:03 PDT
Created attachment 320429 [details] patch for updated comments
Build Bot
Comment 14 2017-09-11 09:52:18 PDT
Comment on attachment 320429 [details] patch for updated comments Attachment 320429 [details] did not pass mac-ews (mac): Output: http://webkit-queues.webkit.org/results/4512769 New failing tests: accessibility/title-tag-on-unimportant-elements-is-help-text.html
Build Bot
Comment 15 2017-09-11 09:52:19 PDT
Created attachment 320434 [details] Archive of layout-test-results from ews100 for mac-elcapitan The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: ews100 Port: mac-elcapitan Platform: Mac OS X 10.11.6
Build Bot
Comment 16 2017-09-11 09:57:15 PDT
Comment on attachment 320429 [details] patch for updated comments Attachment 320429 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.webkit.org/results/4512776 New failing tests: accessibility/title-tag-on-unimportant-elements-is-help-text.html
Build Bot
Comment 17 2017-09-11 09:57:16 PDT
Created attachment 320435 [details] Archive of layout-test-results from ews106 for mac-elcapitan-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: ews106 Port: mac-elcapitan-wk2 Platform: Mac OS X 10.11.6
chris fleizach
Comment 18 2017-09-11 09:59:58 PDT
Created attachment 320437 [details] patch for updated comments
Build Bot
Comment 19 2017-09-11 10:40:32 PDT
Comment on attachment 320437 [details] patch for updated comments Attachment 320437 [details] did not pass mac-ews (mac): Output: http://webkit-queues.webkit.org/results/4513136 New failing tests: accessibility/title-tag-on-unimportant-elements-is-help-text.html
Build Bot
Comment 20 2017-09-11 10:40:34 PDT
Created attachment 320440 [details] Archive of layout-test-results from ews103 for mac-elcapitan The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: ews103 Port: mac-elcapitan Platform: Mac OS X 10.11.6
Build Bot
Comment 21 2017-09-11 10:46:37 PDT
Comment on attachment 320437 [details] patch for updated comments Attachment 320437 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.webkit.org/results/4513147 New failing tests: accessibility/title-tag-on-unimportant-elements-is-help-text.html
Build Bot
Comment 22 2017-09-11 10:46:43 PDT
Created attachment 320443 [details] Archive of layout-test-results from ews105 for mac-elcapitan-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: ews105 Port: mac-elcapitan-wk2 Platform: Mac OS X 10.11.6
chris fleizach
Comment 23 2017-09-11 10:49:37 PDT
Created attachment 320444 [details] patch for updated comments
Build Bot
Comment 24 2017-09-11 11:40:24 PDT
Comment on attachment 320444 [details] patch for updated comments Attachment 320444 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.webkit.org/results/4513682 New failing tests: accessibility/title-tag-on-unimportant-elements-is-help-text.html
Build Bot
Comment 25 2017-09-11 11:40:25 PDT
Created attachment 320448 [details] Archive of layout-test-results from ews105 for mac-elcapitan-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: ews105 Port: mac-elcapitan-wk2 Platform: Mac OS X 10.11.6
Build Bot
Comment 26 2017-09-11 11:54:23 PDT
Comment on attachment 320444 [details] patch for updated comments Attachment 320444 [details] did not pass mac-ews (mac): Output: http://webkit-queues.webkit.org/results/4513826 New failing tests: accessibility/title-tag-on-unimportant-elements-is-help-text.html
Build Bot
Comment 27 2017-09-11 11:54:24 PDT
Created attachment 320450 [details] Archive of layout-test-results from ews100 for mac-elcapitan The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: ews100 Port: mac-elcapitan Platform: Mac OS X 10.11.6
Build Bot
Comment 28 2017-09-11 12:18:42 PDT
Comment on attachment 320444 [details] patch for updated comments Attachment 320444 [details] did not pass mac-debug-ews (mac): Output: http://webkit-queues.webkit.org/results/4513921 New failing tests: accessibility/title-tag-on-unimportant-elements-is-help-text.html
Build Bot
Comment 29 2017-09-11 12:18:45 PDT
Created attachment 320453 [details] Archive of layout-test-results from ews114 for mac-elcapitan The attached test failures were seen while running run-webkit-tests on the mac-debug-ews. Bot: ews114 Port: mac-elcapitan Platform: Mac OS X 10.11.6
chris fleizach
Comment 30 2017-09-11 13:47:44 PDT
Created attachment 320467 [details] patch for updated comments
chris fleizach
Comment 31 2017-09-11 16:48:55 PDT
Created attachment 320503 [details] patch for landing
WebKit Commit Bot
Comment 32 2017-09-12 09:31:45 PDT
Comment on attachment 320503 [details] patch for landing Clearing flags on attachment: 320503 Committed r221918: <http://trac.webkit.org/changeset/221918>
WebKit Commit Bot
Comment 33 2017-09-12 09:31:47 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.