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: Nobody <webkit-unassigned>
Status: REOPENED ---    
Severity: Normal CC: cfleizach, clown, faulkner.steve, hopewell, jcraig, 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

Description Paul Hopewell 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.
Comment 1 Paul Hopewell 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.
Comment 2 Radar WebKit Bug Importer 2017-06-27 11:59:29 PDT
<rdar://problem/33010427>
Comment 3 chris fleizach 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">
Comment 4 Paul Hopewell 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.
Comment 5 James Craig 2017-06-29 18:40:57 PDT
Created attachment 314203 [details]
test case
Comment 6 James Craig 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.
Comment 7 James Craig 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?
Comment 8 James Craig 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?
Comment 9 James Craig 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.
Comment 10 James Craig 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.
Comment 11 James Craig 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.