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.
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.
<rdar://problem/33010427>
(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">
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.
Created attachment 314203 [details] test case
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.
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?
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?
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.
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.
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.
HTML-AAM https://github.com/w3c/html-aam/issues/99 ACCNAME https://github.com/w3c/aria/issues/602
https://github.com/w3c/accname/issues/27
Created attachment 441465 [details] patch
Created attachment 441494 [details] Patch
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"
Created attachment 441518 [details] patch
(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.
(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
Created attachment 442380 [details] patch
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].