Bug 173870

Summary: WebKit should use img@title as label even if img@alt is exlicitly empty
Product: WebKit Reporter: Paul Hopewell <hopewell>
Component: AccessibilityAssignee: chris fleizach <cfleizach>
Status: RESOLVED FIXED    
Severity: Normal CC: aboxhall, andresg_22, apinheiro, cfleizach, clown, dmazzoni, ews-watchlist, faulkner.steve, hopewell, jcraig, jdiggs, samuel_white, tyler_w, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: All   
OS: All   
See Also: https://bugs.webkit.org/show_bug.cgi?id=173006
Attachments:
Description Flags
test case
none
patch
ews-feeder: commit-queue-
Patch
ews-feeder: commit-queue-
patch
andresg_22: review+, ews-feeder: commit-queue-
patch none

Paul Hopewell
Reported 2017-06-27 02:56:13 PDT
I am blind and so use VoiceOver for all access. Using VoiceOver and Safari on Mac OS (latest El Capitan) and latest IOS renders some icons in a frequently used web site as "index.php". Viewing the same web site using Chrome on Mac OS renders these icons with sensible text. Further investigation shows that Chrome gets the text from the TITLE tag. Windows screen readers NVDA and WindowEyes with Firefox on Windows 7 also renders the TITLE tag for these icons. Do the following to show the problem..... 1. Start Safari and VoiceOver on Mac OS. 2. Go to http://www.cfordu3a.org.uk/test_system/index.php 3. Login with membership number 10 and password juice 4. Go to groups and then groups by title and then worm charming 5. Note that VoiceOver renders icons as "index.php" Now repeat the above using Chrome rather than Safari. You will see that the icons are rendered with sensible text. Please note that this is similar to a much shorter bug I submitted in early June. That lacked the details on how to recreate the bug. I would have liked to update the previous bug but could not figure out how to do this.
Attachments
test case (6.20 KB, text/html)
2017-06-29 18:40 PDT, James Craig
no flags
patch (4.80 KB, patch)
2021-10-15 18:13 PDT, chris fleizach
ews-feeder: commit-queue-
Patch (4.79 KB, patch)
2021-10-16 09:09 PDT, chris fleizach
ews-feeder: commit-queue-
patch (5.43 KB, patch)
2021-10-16 22:41 PDT, chris fleizach
andresg_22: review+
ews-feeder: commit-queue-
patch (6.88 KB, patch)
2021-10-25 09:59 PDT, chris fleizach
no flags
Paul Hopewell
Comment 1 2017-06-27 09:03:05 PDT
This is an expansion of bug 173006. Note that the owner of the referenced web site intends to add ALTTXT tags to the guilty icons but we have no time table for doing this. The owner recognises that he should have ALTTXT tags and that he is not following web design guidelines, but then many web designers do not follow guidelines! SO please check out this problem soon, before the web site owner adds the ALTTXT tags. Note that I have tried changing the VoiceOver option to "mouse pointer follows VoiceOver pointer" in the hope that this would improve the rendering of the icons, but no joy.
Radar WebKit Bug Importer
Comment 2 2017-06-27 11:59:29 PDT
chris fleizach
Comment 3 2017-06-28 01:26:05 PDT
(In reply to Paul Hopewell from comment #1) > This is an expansion of bug 173006. > Note that the owner of the referenced web site intends to add ALTTXT tags to > the guilty icons but we have no time table for doing this. The owner > recognises that he should have ALTTXT tags and that he is not following web > design guidelines, but then many web designers do not follow guidelines! > SO please check out this problem soon, before the web site owner adds the > ALTTXT tags. > Note that I have tried changing the VoiceOver option to "mouse pointer > follows VoiceOver pointer" in the hope that this would improve the rendering > of the icons, but no joy. the problem with these images is that they also specify an empty alt tag which has traditionally meant to ignore the image. James, what do you think? if there's a title on the image and alt is empty should we expose these images again <img src="copy.jpg" title="Create a Copy of a Group" alt="" style="border:0" height="22" width="22">
Paul Hopewell
Comment 4 2017-06-29 08:06:41 PDT
Interesting that traditionally an empty ALTTXT tag meant that the screen reader should ignore the icon. However Safari is on its own for this interpretation. Google Chrome on Mac OS and Chrome and Firefox on Windows use the TITLE tag in these circumstances. I suspect that many web designers are not aware of the above tradition, and that using the TITLE tag would improve Safari accessibility on some web sites.
James Craig
Comment 5 2017-06-29 18:40:57 PDT
Created attachment 314203 [details] test case
James Craig
Comment 6 2017-06-29 18:49:32 PDT
I uploaded a test case with all the variants I could think of. Safari seems to do a better job on most (for example, VoiceOver+Chrome reads the data URIs, ick) but the case Paul is referencing is example 7. I don't have a strong opinion but it seems like using th e title would be fine here. I'll reference the two relevant specs and ask around to the various editors and implementors.
James Craig
Comment 7 2017-06-29 18:56:48 PDT
HTML-AAM seems pretty clear that the WebKit behavior is correct. https://w3c.github.io/html-aam/#img-element ~If "any labeling attribute … specifies an empty label … indicates the author's intention to indicate that the img is decorative or redundant. In this case, the user agent MUST set the name to an empty string." Though it specifies this normative requirement in an non-normative note. The normative text does not include this "empty label" exception. Steve?
James Craig
Comment 8 2017-06-29 19:03:51 PDT
My read of the Name Computation spec is that it also confirms WebKit's behavior is correct. http://w3c.github.io/aria/accname-aam/accname-aam.html#mapping_additional_nd_te "Otherwise, use the value as specified by a host language attribute." Note: This literally means the value even if it's empty, though that point could be debated. Also of note is that the name computation spec calls out the exception for an explicitly empty aria-label, but not an explicitly empty host language attribute. Joseph?
James Craig
Comment 9 2017-06-29 19:12:23 PDT
FWIW, I'm fine changing it to match the others if the implementors and spec editors agree that's the desired behavior. It seems like it would work better in most cases, unless anyone is using machine micro-data in images.
James Craig
Comment 10 2017-07-05 08:42:37 PDT
Marking as "WORKS FOR ME" AKA behaves correctly unless we hear feedback from other implementors or spec authors about changing ARIA or HTML to match the bug reporter's expectation.
James Craig
Comment 11 2017-07-07 01:49:28 PDT
Reopening based on Joanie's comment that there is a specific WCAG success criteria that includes this case in https://www.w3.org/TR/WCAG20-TECHS/H67.html I think that's enough to consider this a valid bug and match the behavior in Firefox/Chrome. I'll file issues against the HTML-AAM and NameComp specs to account for this discrepancy.
James Craig
Comment 13 2021-10-14 17:12:49 PDT
chris fleizach
Comment 14 2021-10-15 18:13:57 PDT
chris fleizach
Comment 15 2021-10-16 09:09:18 PDT
Tyler Wilcock
Comment 16 2021-10-16 09:31:58 PDT
Comment on attachment 441494 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=441494&action=review I don't have r+ privileges, but looks good to me. > LayoutTests/accessibility/img-no-alt-not-ignored-with-title.html:13 > + description("This tests that if an image as an empty alt tag, but it has title or aria-label, we will NOT ignore it."); > This tests that if an image as Typo. Should be: "This tests that if an image has"
chris fleizach
Comment 17 2021-10-16 22:41:05 PDT
Andres Gonzalez
Comment 18 2021-10-18 08:37:07 PDT
(In reply to chris fleizach from comment #17) > Created attachment 441518 [details] > patch Should we enable this test for iOS? Needs to be done explicitly in the platform/ios/TestExpectations.
chris fleizach
Comment 19 2021-10-18 08:38:51 PDT
(In reply to Andres Gonzalez from comment #18) > (In reply to chris fleizach from comment #17) > > Created attachment 441518 [details] > > patch > > Should we enable this test for iOS? Needs to be done explicitly in the > platform/ios/TestExpectations. Will look into it
chris fleizach
Comment 20 2021-10-25 09:59:13 PDT
EWS
Comment 21 2021-10-25 16:20:37 PDT
Committed r284844 (243521@main): <https://commits.webkit.org/243521@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 442380 [details].
Note You need to log in before you can comment on or make changes to this bug.