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.

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

Should the Host Language Label be used if it's empty? #234

Open
dandclark opened this issue Mar 21, 2024 · 3 comments
Open

Should the Host Language Label be used if it's empty? #234

dandclark opened this issue Mar 21, 2024 · 3 comments
Assignees

Comments

@dandclark
Copy link

The Host Language Label step E of the accname computation algorithm is unclear on whether the empty string should be used if that's what the native markup provides.

E. Host Language Label: Otherwise, if the current node's native markup provides an attribute (e.g. alt) or element (e.g. HTML label or SVG title) that defines a text alternative, return that alternative in the form of a flat string as defined by the host language, unless the element is marked as presentational (role="presentation" or role="none").

Going by a strict reading of the spec, I'd guess that an empty string should be used. However the img with tooltip label with empty alt subtest of accname/name/comp_tooltip.html suggests that an empty alt attribute should be ignored. Gecko and WebKit pass this test, while Blink fails.

If that test reflects the intended behavior, should the spec be updated to something like this?

E. Host Language Label: Otherwise, if the current node's native markup provides an attribute (e.g. alt) or element (e.g. HTML label or SVG title) that defines a text alternative, return that alternative in the form of a flat string as defined by the host language, unless the text alternative is an empty string or the element is marked as presentational (role="presentation" or role="none").

Also -- if the empty string is omitted, what about a whitespace-only string? (See #233).

@scottaohara
Copy link
Member

related w3c/html-aam#533

@aleventhal
Copy link
Contributor

aleventhal commented Apr 3, 2024

Not that it answers this question, but I wanted to note that <img alt=""> is special. It historically was a way to indicate decorative/redundant images before ARIA existed. The presence of an alt attribute with the empty string tells screen readers like JAWS to not attempt to repair the missing alt attribute. We can't really break that since it's baked into the web at this point. But whether aria-label[ledby] should override that is another question.

aarongable pushed a commit to chromium/chromium that referenced this issue Apr 3, 2024
The Host Language Label step [1] of the accname computation algorithm
is unclear on whether the empty string should be used if that's
what the native markup provides.

I've filed an issue to clarify this at [2].

Meanwhile, other engines will allow a source later in the name
computation steps to provide a name even if an empty `alt` attribute
was set; see results for the "img with tooltip label with empty alt"
case in accname/name/comp_tooltip.html [3]. So, switch Blink's
behavior to match the other engines.

However, we still ensure that `name_source` is still set to
`kAttributeExplicitlyEmpty` returning
from`AXNodeObject::TextAlternative` if `alt` was set to the
empty string and a name was not provided from another source. This is
necessary to preserve the behavior where setting `alt=""` causes
the image to be treated as presentational and ignored. If a valid
name is provided from another source, however, the other name
overrides that behavior.

[1] https://w3c.github.io/accname/#comp_host_language_label
[2] w3c/accname#234
[3] https://wpt.fyi/results/accname/name/comp_tooltip.html?label=master&label=experimental&aligned&view=interop&q=label%3Ainterop-2024-accessibility

Bug: 325612090
Change-Id: I38e510ce27319afad406a9c128a47288c2c087ee
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5382253
Commit-Queue: Aaron Leventhal <[email protected]>
Reviewed-by: Aaron Leventhal <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1282227}
@MelSumner
Copy link
Contributor

The test reflects the desired behavior but alt="" is special TBH.

I have long been of the opinion that, since modern IDEs will pre-fill <img src="" alt=""/> for you, it should be permissible/valid to also add role="none" or role="presentation" to an image.

I do not think the specification should change here. If anything, we could add a note that this is a special case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Needs triage
Development

No branches or pull requests

5 participants