Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

WCAG/ACCNAME discrepancy with `<img alt="" title="foo"> #27

Open
jnurthen opened this issue May 21, 2018 · 6 comments
Open

WCAG/ACCNAME discrepancy with `<img alt="" title="foo"> #27

jnurthen opened this issue May 21, 2018 · 6 comments
Assignees
@MelSumner
Labels
AAM ARIA 1.1
Milestone
2022H2

Comments

@jnurthen
Copy link
Member

From @cookiecrook on July 7, 2017 9:25

The following text in ACCNAME:

"Otherwise, use the value as specified by a host language attribute."

Seems to literally means the value even if it's empty, which does not leave the exception covered by WCAG Success Criteria H67: https://www.w3.org/TR/WCAG20-TECHS/H67.html

For each image that should be ignored: Check that title attribute is either absent or empty. Check that alt attribute is present and empty. ...

Furthermore, both Blink and Gecko allow this behavior. WebKit currently matches the HTML-AAM and ACCNAME specs, but will likely change to match the other browser's behavior. https://webkit.org/b/173870

Test case 7 here:
https://bugs.webkit.org/attachment.cgi?id=314203

Copied from original issue: w3c/aria#602
@jnurthen
Copy link
Member Author

From @cookiecrook on July 7, 2017 9:25

Similar issue in HTML-AAM w3c/html-aam#99

@jnurthen jnurthen mentioned this issue May 21, 2018
Closed
@jnurthen jnurthen added this to the 1.2 milestone May 29, 2018
@joanmarie joanmarie assigned MelSumner and unassigned richschwer Mar 18, 2021
@joanmarie
Copy link
Contributor

Melanie: This came up in Chromium (which currently doesn't use the title). And it's not 100% clear what the right answer is (use the title or not).

I don't know if the fix belongs here, in HTML-AAM, or what.... But some clarification is needed somewhere. Ideas?

@carmacleod
Copy link
Contributor

carmacleod commented Mar 18, 2021 •
edited
Loading

In case it's helpful, there's an img section in HTML-AAM that makes it pretty clear that alt wins:

  1. If the img element has an aria-label or an aria-labelledby attribute the accessible name is to be calculated using the algorithm defined in Accessible Name and Description: Computation and API Mappings 1.1.
  2. Otherwise use alt attribute.
  3. Otherwise use title attribute.
  4. If none of the above yield a usable text string there is no accessible name.

@scottaohara
Copy link
Member

just spent some time with @stevefaulkner on this, re: the intent of HTML AAM.

from our perspective, if there's an alt="" that would indicate that the image is meant to be "hidden", and therefore the steps would stop at 2. we could clarify that further by revising step 3 specifically indicate it only be applicable if there is no alt attribute.

  • webkit treats this scenario as an ignored image (but does label it with the title)
  • as already stated, chromium ignores title and the image here.
  • firefox does respect the title and exposes the image with this as its name.

@joanmarie
Copy link
Contributor

In case it's helpful, there's an img section in HTML-AAM that makes it pretty clear that alt wins:

I'm afraid in my mind it's not pretty clear. I read that section before commenting here.

  1. Otherwise use alt attribute.

Would be way more clear IMHO if that statement ended with "even if it's empty."

  1. If none of the above yield a usable text string there is no accessible name.

Does an empty alt attribute "yield a usable text string"? Without the "even if it's empty" qualifier, that text seems to hint that the goal is a usable text string. 😀 And we can meet that goal from:

  1. Otherwise use title attribute.

And WCAG says:

Procedure
For each image that should be ignored:

  1. Check that title attribute is either absent or empty.
  2. Check that alt attribute is present and empty.

So for images that should be ignored, there should be an absent or empty title. That, to me, seems to imply that an image which fails to meet both criteria is NOT an "img element for images that AT should ignore." But if an AT should not ignore it, it should have something presentable.

But whatever....

The HTML-AAM's img section is called "Element Accessible Name Computation". So if it's modified to make it clear that alt wins, even if it's empty, that answers the question "What is the name of the image?" Now let's say this same image is being consulted as part of a name-from-contents calculation on an ancestor element.

According to AccName's step 2D:

Otherwise, if the current node's native markup provides an attribute (e.g. title) or element (e.g. HTML label) that defines a text alternative, return that alternative in the form of a flat string as defined by the host language.

Does the title constitute "an attribute that defines a text alternative"? OR is the assumption that the since the image has no name, the title should also be ignored when calculating name from contents of an ancestor?

scottaohara added a commit to w3c/html-aam that referenced this issue Mar 21, 2021
@scottaohara
clarify img naming steps
7db8d84 
related to w3c/accname#27
@scottaohara scottaohara mentioned this issue Mar 22, 2021
Merged
webkit-commit-queue pushed a commit to WebKit/WebKit that referenced this issue Oct 25, 2021
@fleizach
WebKit should use img@title as label even if img@alt is exlicitly empty
e964f28 
https://bugs.webkit.org/show_bug.cgi?id=173870
<rdar://problem/33010427>

Reviewed by Andres Gonzalez.

Source/WebCore:

alt="" usually means to ignore an image. However, when it also carries other
descriptive attributes, that is probably the wrong decision.
Other browsers are not ignoring these images, WebKit should follow suit.

This issue has been raised with
w3c/accname#27

Test: accessibility/img-no-alt-not-ignored-with-title.html

* accessibility/AccessibilityRenderObject.cpp:
(WebCore::AccessibilityRenderObject::computeAccessibilityIsIgnored const):

LayoutTests:

* accessibility/img-no-alt-not-ignored-with-title-expected.txt: Added.
* accessibility/img-no-alt-not-ignored-with-title.html: Added.
* platform/ios-simulator/TestExpectations:
* platform/win/TestExpectations:


Canonical link: https://commits.webkit.org/243521@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@284844 268f45cc-cd09-0410-ab3c-d52691b4dbfc
philn pushed a commit to philn/old-webkit that referenced this issue Oct 27, 2021
WebKit should use img@title as label even if img@alt is exlicitly empty
91638ef 
https://bugs.webkit.org/show_bug.cgi?id=173870
<rdar://problem/33010427>

Reviewed by Andres Gonzalez.

Source/WebCore:

alt="" usually means to ignore an image. However, when it also carries other
descriptive attributes, that is probably the wrong decision.
Other browsers are not ignoring these images, WebKit should follow suit.

This issue has been raised with
w3c/accname#27

Test: accessibility/img-no-alt-not-ignored-with-title.html

* accessibility/AccessibilityRenderObject.cpp:
(WebCore::AccessibilityRenderObject::computeAccessibilityIsIgnored const):

LayoutTests:

* accessibility/img-no-alt-not-ignored-with-title-expected.txt: Added.
* accessibility/img-no-alt-not-ignored-with-title.html: Added.
* platform/ios-simulator/TestExpectations:
* platform/win/TestExpectations:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@284844 268f45cc-cd09-0410-ab3c-d52691b4dbfc
scottaohara added a commit to w3c/html-aam that referenced this issue May 12, 2022
@scottaohara
clarify img naming steps (#322)
d509007 
* clarify img naming steps

related to w3c/accname#27

* remove reference to note that’s no longer there

add in new note as a reminder that `alt=“”` means the `img` is meant to be exposed as role=presentation
@JAWS-test JAWS-test mentioned this issue Jun 21, 2022
Closed
@giacomo-petri giacomo-petri mentioned this issue Jun 22, 2022
Closed
@scottaohara
Copy link
Member

this was resolved in HTML AAM.

further conversation in w3c/html-aam#404 and w3c/aria#1746

shall we close this issue in favor of the others where conversation should continue?

pkra pushed a commit to w3c/aria that referenced this issue May 20, 2024
@scottaohara
clarify img naming steps (#322)
18d7dcb 
* clarify img naming steps

related to w3c/accname#27

* remove reference to note that’s no longer there

add in new note as a reminder that `alt=“”` means the `img` is meant to be exposed as role=presentation
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@MelSumner MelSumner

Labels
AAM ARIA 1.1
Projects
None yet
Milestone
2022H2
Development

No branches or pull requests
6 participants
@jnurthen @joanmarie @carmacleod @scottaohara @MelSumner @richschwer