New issue
Advanced search Search tips

Issue 701747 link

Starred by 4 users

Issue metadata

Status: Fixed
Owner:
Closed: May 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug
Team-Accessibility



Sign in to add a comment

Blank img alt text is lost when using a picture <source>

Reported by craig.fr...@gmail.com, Mar 15 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3042.0 Safari/537.36

Steps to reproduce the problem:
1. Create a <picture> element with a <source> (e.g. to provide a webp version), and an <img> with alt="".
2. Check in screen reader (e.g. VoiceOver).

What is the expected behavior?
The image should be ignored (a blank alt indicates the image is decorative).

What went wrong?
It reads the filename, as though the alt attribute is missing.

Did this work before? N/A 

Chrome version: 59.0.3042.0  Channel: canary
OS Version: OS X 10.12.3
Flash Version:
 
index.html
439 bytes View Download
screenshot.png
18.7 KB View Download

Comment 1 by ajha@chromium.org, Mar 16 2017

Components: UI>Accessibility
Labels: Needs-Triage-M59
Components: -UI>Accessibility Blink
Components: UI>Accessibility
Cc: dmazz...@chromium.org
Components: -Blink
DOM looks fine in web inspector. I presume this is an inconsistency how the AXObjects are populated?

dmazzoni@ any idea?
Cc: kkaluri@chromium.org
Labels: Needs-Feedback
Unable to reproduce this issue in Mac 10.12.3 with chrome #59.0.3046.0

These are the steps performed

1. Launched chrome and navigated to provided url in comment #0
2. Enabled VoiceOver by pressing cmd + F5.
3. Read the web content by pressing "ctrl+option+shift+DownArrow"

Didn't hear any file name reading out.

Attaching the screen-cast for reference

craig.francis@ could you please look into it and let us know your observations.

Issue 701747.mp4
1.2 MB View Download
Thanks for checking kkaluri@

It depends on how you get VoiceOver to read the content, where it looks like having a minimal example kind of works, until you press [Command] [Option] [Right arrow] to move to the next element.

The attached file might help, it's pretty much the same, but includes some additional text before/after the image.

Pressing [Control] [Option] [Shift] [Down Arrow] will enter the web content area, and read the "Text before" paragraph.

Pressing [Command] [Option] [Right arrow] will then select the image, and read out the filename (rather than ignoring the image, and skipping over to "Text after").
index.html
480 bytes View Download
screenshot.jpg
112 KB View Download
Project Member

Comment 7 by sheriffbot@chromium.org, Mar 21 2017

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "kkaluri@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Cc: aleventhal@chromium.org
Labels: -OS-Mac
Status: Untriaged (was: Unconfirmed)
Removing the Mac label as it's unlikely this is Mac-specific.

Aaron, want to look at this one?

Labels: NewComponent-Accessibility-Blink NewComponent-Accessibility
Tested this issue on Mac 10.12.3 using latest Canary 60.0.3077.0 and observing some other behavior.

Below are the steps followed as per comment #6
1.Downloaded above mentioned Index.html file
2.Enabled voice over
3.Pressed [Control] [Option] [Shift] [Down Arrow] 
4. Pressed [Command] [Option] [Right arrow]

@Criag: Please find the attached screen cast and let us know your observations for further investigation.

Thanks,


701747-21-04.mp4
4.8 MB View Download
@sandeepkumars It looks like you got stuck on the minimise button for a while, and later focused on the page at a higher level (not interesting with the content).

The attached screen cast shows the content being read, where the image says the filename, rather than being ignored (images with an alt="" are decorative).
701747-2017-04-21.mp4
641 KB View Download
Components: Blink>Accessibility
Components: -UI>Accessibility
Labels: -newcomponent-accessibility-blink -newcomponent-accessibility
Owner: aleventhal@chromium.org
Status: Started (was: Untriaged)
Observations:
- I'm not seeing a difference whether <picture> is used or <img> alone.
- Safari is not even exposing the image at all, alt="" on an img, seems to be the equivalent of using role="presentation"
Safari is doing the correct behaviour.

https://www.w3.org/TR/WCAG20-TECHS/H67.html

As to the first point, I'm not at my computer at the moment, but it was acting differently when I tested with Chrome Canary 59.
Status: Fixed (was: Started)
Project Member

Comment 18 by bugdroid1@chromium.org, May 3 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7ae4d36b7f3b88d7998cc86c2fc6a7245ccdba96

commit 7ae4d36b7f3b88d7998cc86c2fc6a7245ccdba96
Author: aleventhal <aleventhal@chromium.org>
Date: Wed May 03 18:46:45 2017

Handle <img alt> and <img alt=""> as purposefully empty alt.

BUG= 701747 , 708192 , 710537 

Review-Url: https://codereview.chromium.org/2833843005
Cr-Commit-Position: refs/heads/master@{#469050}

[modify] https://crrev.com/7ae4d36b7f3b88d7998cc86c2fc6a7245ccdba96/chrome/common/extensions/api/automation.idl
[modify] https://crrev.com/7ae4d36b7f3b88d7998cc86c2fc6a7245ccdba96/content/browser/accessibility/accessibility_tree_formatter_auralinux.cc
[modify] https://crrev.com/7ae4d36b7f3b88d7998cc86c2fc6a7245ccdba96/content/browser/accessibility/accessibility_tree_formatter_win.cc
[modify] https://crrev.com/7ae4d36b7f3b88d7998cc86c2fc6a7245ccdba96/content/browser/accessibility/browser_accessibility.cc
[modify] https://crrev.com/7ae4d36b7f3b88d7998cc86c2fc6a7245ccdba96/content/browser/accessibility/browser_accessibility.h
[modify] https://crrev.com/7ae4d36b7f3b88d7998cc86c2fc6a7245ccdba96/content/browser/accessibility/browser_accessibility_android.cc
[modify] https://crrev.com/7ae4d36b7f3b88d7998cc86c2fc6a7245ccdba96/content/browser/accessibility/browser_accessibility_auralinux.cc
[modify] https://crrev.com/7ae4d36b7f3b88d7998cc86c2fc6a7245ccdba96/content/browser/accessibility/browser_accessibility_cocoa.mm
[modify] https://crrev.com/7ae4d36b7f3b88d7998cc86c2fc6a7245ccdba96/content/browser/accessibility/browser_accessibility_win.cc
[modify] https://crrev.com/7ae4d36b7f3b88d7998cc86c2fc6a7245ccdba96/content/browser/accessibility/dump_accessibility_tree_browsertest.cc
[modify] https://crrev.com/7ae4d36b7f3b88d7998cc86c2fc6a7245ccdba96/content/renderer/accessibility/blink_ax_enum_conversion.cc
[modify] https://crrev.com/7ae4d36b7f3b88d7998cc86c2fc6a7245ccdba96/content/renderer/accessibility/blink_ax_tree_source.cc
[modify] https://crrev.com/7ae4d36b7f3b88d7998cc86c2fc6a7245ccdba96/content/shell/test_runner/web_ax_object_proxy.cc
[add] https://crrev.com/7ae4d36b7f3b88d7998cc86c2fc6a7245ccdba96/content/test/data/accessibility/html/img-empty-alt-expected-android.txt
[modify] https://crrev.com/7ae4d36b7f3b88d7998cc86c2fc6a7245ccdba96/content/test/data/accessibility/html/img-empty-alt-expected-blink.txt
[modify] https://crrev.com/7ae4d36b7f3b88d7998cc86c2fc6a7245ccdba96/content/test/data/accessibility/html/img-empty-alt-expected-mac.txt
[add] https://crrev.com/7ae4d36b7f3b88d7998cc86c2fc6a7245ccdba96/content/test/data/accessibility/html/img-empty-alt-expected-win.txt
[modify] https://crrev.com/7ae4d36b7f3b88d7998cc86c2fc6a7245ccdba96/content/test/data/accessibility/html/img-empty-alt.html
[modify] https://crrev.com/7ae4d36b7f3b88d7998cc86c2fc6a7245ccdba96/content/test/data/accessibility/html/img-expected-android.txt
[add] https://crrev.com/7ae4d36b7f3b88d7998cc86c2fc6a7245ccdba96/content/test/data/accessibility/html/img-expected-blink.txt
[modify] https://crrev.com/7ae4d36b7f3b88d7998cc86c2fc6a7245ccdba96/content/test/data/accessibility/html/img-expected-mac.txt
[modify] https://crrev.com/7ae4d36b7f3b88d7998cc86c2fc6a7245ccdba96/content/test/data/accessibility/html/img-expected-win.txt
[add] https://crrev.com/7ae4d36b7f3b88d7998cc86c2fc6a7245ccdba96/content/test/data/accessibility/html/img-link-empty-alt-expected-android.txt
[add] https://crrev.com/7ae4d36b7f3b88d7998cc86c2fc6a7245ccdba96/content/test/data/accessibility/html/img-link-empty-alt-expected-blink.txt
[add] https://crrev.com/7ae4d36b7f3b88d7998cc86c2fc6a7245ccdba96/content/test/data/accessibility/html/img-link-empty-alt-expected-mac.txt
[add] https://crrev.com/7ae4d36b7f3b88d7998cc86c2fc6a7245ccdba96/content/test/data/accessibility/html/img-link-empty-alt-expected-win.txt
[add] https://crrev.com/7ae4d36b7f3b88d7998cc86c2fc6a7245ccdba96/content/test/data/accessibility/html/img-link-empty-alt.html
[add] https://crrev.com/7ae4d36b7f3b88d7998cc86c2fc6a7245ccdba96/content/test/data/accessibility/html/picture-expected-android.txt
[add] https://crrev.com/7ae4d36b7f3b88d7998cc86c2fc6a7245ccdba96/content/test/data/accessibility/html/picture-expected-mac.txt
[add] https://crrev.com/7ae4d36b7f3b88d7998cc86c2fc6a7245ccdba96/content/test/data/accessibility/html/picture-expected-win.txt
[add] https://crrev.com/7ae4d36b7f3b88d7998cc86c2fc6a7245ccdba96/content/test/data/accessibility/html/picture.html
[modify] https://crrev.com/7ae4d36b7f3b88d7998cc86c2fc6a7245ccdba96/third_party/WebKit/Source/modules/accessibility/AXNodeObject.cpp
[modify] https://crrev.com/7ae4d36b7f3b88d7998cc86c2fc6a7245ccdba96/third_party/WebKit/Source/modules/accessibility/AXObject.h
[modify] https://crrev.com/7ae4d36b7f3b88d7998cc86c2fc6a7245ccdba96/third_party/WebKit/Source/modules/accessibility/InspectorTypeBuilderHelper.cpp
[modify] https://crrev.com/7ae4d36b7f3b88d7998cc86c2fc6a7245ccdba96/third_party/WebKit/Source/web/AssertMatchingEnums.cpp
[modify] https://crrev.com/7ae4d36b7f3b88d7998cc86c2fc6a7245ccdba96/third_party/WebKit/public/web/WebAXEnums.h
[modify] https://crrev.com/7ae4d36b7f3b88d7998cc86c2fc6a7245ccdba96/ui/accessibility/ax_enums.idl
[modify] https://crrev.com/7ae4d36b7f3b88d7998cc86c2fc6a7245ccdba96/ui/accessibility/platform/ax_platform_node_win.cc

How can I tell when this appears in Chrome Canary?

60.0.3100.0 (16th May 2017) seems to be a bit different, but isn't fixed.

Sign in to add a comment