clarify img naming steps #322

scottaohara · 2021-03-22T19:08:15Z

related to w3c/accname#27

firefox bug
https://bugzilla.mozilla.org/show_bug.cgi?id=1700174

Preview | Diff

💥 Error: 504 Gateway Time-out 💥

PR Preview failed to build. (Last tried on May 10, 2022, 5:08 PM UTC).

More

PR Preview relies on a number of web services to run. There seems to be an issue with the following one:

🚨 Spec Generator - Spec Generator is the web service used to build specs that rely on ReSpec.

🔗 Related URL

<html><body><h1>504 Gateway Time-out</h1>
The server didn't respond in time.
</body></html>

If you don't have enough information above to solve the error by yourself (or to understand to which web service the error is related to, if any), please file an issue.

related to w3c/accname#27

carmacleod

+1

I think this helps clarify immensely. Thanks, @scottaohara !

jcsteh · 2021-03-24T23:47:27Z

I'm not convinced discarding title where alt="" is present is a good thing. The title is still available on hover for sighted users. Contrary to the purpose of alt="", that suggests the image isn't purely decorative; it has some meaning beyond decoration.

Strictly speaking, it can be argued that you shouldn't combine alt="" with title for the above reason and that this should be considered authoring error. However, when mistakes like this are made (and they invariably are), I'd argue it's better in the real world to avoid hurting the user if we can (only of course if we can do so without breaking valid use cases).

An analogy is what browsers (tested Firefox and Chrome) do if you specify role="presentation" but also specify ARIA attributes:
data:text/html,<h1 role="presentation" aria-label="label">text
In that case, role="presentation" is ignored because the author specified another ARIA attribute, so the author's intentions are contradictory and we thus choose to be cautious in favour of not stripping potentially important information.

The question is: is there a valid use case for alt="" title="something"? If not, why take potentially useful info away from the user?

joanmarie · 2021-03-27T14:23:11Z

I agree 100% with @carmacleod and with @jcsteh. The new wording makes things so clear that even I can understand it. 😀 Thanks @scottaohara! That said, whether or not those now-clear steps describe what we really want to happen is something I question.

scottaohara · 2021-03-27T18:15:33Z

agreed, all. Which is why i wanted to leave this open for a bit before pulling it in - so thank you for responding.

The following is my current stance on this. I'm mentioning it not because I am completely rooted in it, only to provide reasoning to why I think this change makes sense. Please, rebut me if you see things differently.

point 1 - author error

More often than not, in the audits/reviews of audits that I do, a title on an image is either redundant or used in error.

For example, the following code snippets are representations of what I've seen in just the last week:

<a href=...>
  <img src=... alt="" aria-label="user name" title="user name">
  user name
</a>

clearly the above is still going to be an issue regardless of title, because aria-label wins out.

but then there's also many instances like the following:

<img src=... alt="" title="user name"> user name

where again title was used in error, likely injected by whatever CMS was used, while the image was meant to be treated as decorative.

Granted, I know I am constantly exposed to incorrect usage due to the nature of my job. But because of that, i also see this happening a lot. It doesn't make the content "inaccessible" - just unnecessarily redundant/verbose. Though, this verbosity is ignored in Webkit and Chromium as they do not expose images with title=something if they are also provided alt="".

point 2 - `title` is not presently an attribute that can undo `role=presentation`

per ARIA's presentational roles conflict resolution regarding the applicable bullets here, only if an <img> were focusable or had a global aria-* attribute (e.g. aria-label) should (normative must) the implicit role=presentation that the alt="" provides be overruled, and the img role re-exposed.

If we decide that <img src=... alt="" title=foo> should have an accName of "foo", then I think ARIA needs to change to indicate that title can undo role=none.

jnurthen

The mapping for "img (alt attribute value is an empty string, i.e. alt="" or alt with no value in the markup)" states "See also the Note under img element Accessible Name Computation."

There is no note under img element Accessible Name Computation any more

add in new note as a reminder that `alt=“”` means the `img` is meant to be exposed as role=presentation

jcsteh · 2021-04-29T04:08:20Z

<img src=... alt="" title="user name"> user name
where again title was used in error, likely injected by whatever CMS was used, while the image was meant to be treated as decorative.

I agree this is author error... but on the other hand, this is also going to impact sighted users, albeit less impact than for screen reader users (they'll see a redundant tool tip when they hover).

per ARIA's presentational roles conflict resolution regarding the applicable bullets here, only if an <img> were focusable or had a global aria-* attribute (e.g. aria-label) should (normative must) the implicit role=presentation that the alt="" provides be overruled, and the img role re-exposed.

That's true. role="none" feels a lot more "explicit" to me than alt="" here - alt="" seems more likely to be done in error than role="none" - but I don't have any evidence for that thinking. While you're primarily concerned about title being used in error, I'm worried about alt="" being used in error (and the user losing info as a result).

One other concern I've been reluctant to raise until now (because it really complicates things) is that Firefox actually doesn't ever prune images with alt="" from the a11y tree. Rather, it differentiates between no alt (accName exposed as null) and alt="" (accName exposed as the empty string). This was done many years ago (I believe before the mapping spec existed) to give ATs the opportunity to compensate for inappropriate use of alt="". For example, if alt="" was used inside a link but the link had no other text, the AT could choose to try to derive a name from the image URL. If the image is pruned from the tree, this becomes impossible. Looking at NVDA's code, it doesn't use this any more (except to avoid rendering the image for alt=""). I'm not sure about JAWS, but I guess it probably doesn't use it given that Chrome complies with the spec on this point. Still, this is one of those cases where a spec decision was made (i.e. alt="" mapping to role="none") that wasn't necessarily reflected in reality for all implementations at time of writing. It's probably best for us to just change Firefox to comply with the spec here, but I worry a bit about breaking some consumer that currently depends on that behaviour.

JAWS-test · 2021-04-29T08:58:51Z

I'm not sure about JAWS, but I guess it probably doesn't use it given that Chrome complies with the spec on this point.

JAWS outputs a link with graphic with alt="" as follows:

Chrome: href of the link
Firefox: src of the graphic

NVDA outputs href of the link with Firefox and Chrome

scottaohara · 2021-10-07T17:17:52Z

@jnurthen i would like to request this be taken up in an ARIA wg call before I merge this.

cyns · 2021-10-14T18:06:32Z

@aleventhal and I discussed offline, and we'd be ok with either the Chrome or the Firefox approach, as long as there's consensus.

aleventhal · 2021-10-14T18:12:45Z

@aleventhal and I discussed offline, and we'd be ok with either the Chrome or the Firefox approach, as long as there's consensus.

I'd be ok with any approach that has consensus, for <img alt="" title="foo">

Expose image with name=foo (current Firefox approach)
Do not expose image (current Chrome approach)
Expose image with no name, but description=foo (nobody, probably)

cookiecrook · 2021-10-15T00:22:25Z

I'd also be ok with any approach that has consensus, but I have a mild preference for the Firefox approach for the reasons Jamie specified in the context of considering users over authors over implementors.

Quoting @jcsteh:

I'm not convinced discarding title where alt="" is present is a good thing. The title is still available on hover for sighted users. Contrary to the purpose of alt="", that suggests the image isn't purely decorative; it has some meaning beyond decoration.

Strictly speaking, it can be argued that you shouldn't combine alt="" with title for the above reason and that this should be considered authoring error. However, when mistakes like this are made (and they invariably are), I'd argue it's better in the real world to avoid hurting the user if we can (only of course if we can do so without breaking valid use cases).

aleventhal · 2021-10-15T13:36:22Z

@mcking65 what say you?

stevefaulkner · 2021-10-20T10:52:11Z

Given that alt="" equates to role="presentation" when present on an <img> does this mean that the following should also be exposed?

<img role=presentation alt="text">
<img role=presentation title="text">
<img role=presentation aria-label="text">

aleventhal · 2021-10-20T14:16:58Z

Steve, good question. I just compared what browsers do now using:
data:text/html,<img src='https://upload.wikimedia.org/wikipedia/commons/2/2b/Broadcast_icon.png' role=presentation alt=text><img src='https://upload.wikimedia.org/wikipedia/commons/2/2b/Broadcast_icon.png' role=presentation title=text><img src='https://upload.wikimedia.org/wikipedia/commons/2/2b/Broadcast_icon.png' role=presentation aria-label=text>

I compared Chrome, Firefox and Safari (Edge will be the same as Chrome):
<img role=presentation alt="text">: exposed by nobody
<img role=presentation title="text">: expose by Firefox only
<img role=presentation aria-label="text">: exposed by Firefox and Safari

scottaohara · 2021-10-20T16:59:50Z

Per those results, I'm really only surprised at Chromium not exposing the aria-label example, since that example fits into the third bullet of Presentational Roles Conflict Resolution.

Of note, the ARIA spec states the following in the middle of the role=presentation definition:

In HTML, the <img> element is treated as a single entity regardless of the type of image file. Consequently, using role="presentation" or role="none" on an HTML img is equivalent to using aria-hidden="true".

So, ARIA is stating that img role=none is equivalent to img aria-hidden=true... so that's a bit of spec language that might need adjusting if we go with exposing title here...

I'm still on the fence (though more leaning more towards Webkit/Chromium behavior) with which direction is actually going to be more helpful to users in reality, particularly due to the numerous instances of misuse I've encountered (and more since this thread started).

But if we do go the Firefox route here, I think it's important to surface the change in other places. Why are Chromium/Webkit no longer using alt="" as a way to treat an image as decorative (a developer might wonder as their previously decorative images are now exposed). Also, why are img role=presentation title=foo now being exposed?

Or do we agree that is a Firefox bug? For instance, taking Steve's example a step further, what should happen here <img src=... alt="" role=none title=foo>. Essentially double role=none. Firefox also exposes that as a graphic. I think that's wrong.

From my earlier comment, what say people to point 2?
Specifically If we decide that <img src=... alt="" title=foo> should have an accName of "foo", then I still kinda think ARIA needs to change to indicate that title can undo role=none.

Because that's essentially what we'd be doing here. For better or worse. And, imo, otherwise it's not really clear why this behavior would be happening when the general expectation/author guidance has been alt="" treats an image as decorative (and under the hood makes it role=none).

The counter point to that, would be allowing title to undo role=none would then have ramifications for things like <div role=none title=foo>, or <article role=none title=foo> as well. If a title is present then only mouse users will be able to get the information in those examples. Similar with <img alt title=foo> (or re: Firefox, <img role=none title=foo>. Should we not be consistent with the behavior? (note; that actually Firefox is still exposing <article role=none title=foo> here as well. NVDA/JAWS ignore the article, but Narrator actually exposes it... rabbit holes).

And that makes me nervous... accessibility is hard enough for developers to understand and get right. Having inconsistencies in how things behave doesn't help.

MelSumner · 2021-10-21T17:54:11Z

As an author, I use title as a layered cue but I don't expect it to be available to assistive tech if I've also explicitly added role="presentation" or role="none".

I think this should be considered a Firefox bug.

ETA: I think we can spin our wheels a lot on this and I would encourage us to not get stuck in the edge cases but think about the sensible implementation.

scottaohara · 2021-10-21T18:00:08Z

@jcsteh we spoke about this again in the ARIA wg today. We wanted to make sure you were pinged on this again for any further thoughts you'd like to add.

cookiecrook · 2021-10-21T18:03:49Z

Somewhat related to w3c/aria#1628

jcsteh · 2021-10-22T01:33:38Z

I don't really have anything more to add beyond what I've already said. I understand and agree we need to fix the inconsistency here. I understand Firefox's approach might be confusing for authors. However, I still believe we need to consider users first (in a world of brokenness) at the end of the day, as I argued in #322 (comment).

mcking65 · 2021-10-22T06:59:34Z

I agree with all of the reasons provided by @jcsteh for using title for the image name when alt="".

However, I wonder if it could be feasible to revise the proposal slightly to avoid blocking valid use cases. I can imagine a design that legitimately calls for title on a image that should be treated as presentational because the information in the title is provided to assistive technologies via another element in the UI.

Would it be feasible for ...

Title to override implicit role presentation set with null alt so <img src=... alt="" title="user name"> would give accname="user name"
Explicit role presentation to override implicit role presentation so <img role="none" src=... alt="" title="user name"> would make the image presentational.

This would enable reduction of harm when alt="" might possibly be misused while still allowing for the possibility of hover text on a presentational image. It also continues to allow for reduction in harm when role presentation is mistakenly declared on an image where aria-label is specified.

LJWatson · 2021-12-02T08:47:28Z

@jcsteh wrote:

I'm not convinced discarding title where alt="" is present is a good thing. The title is still available on hover for sighted users.

AFAIK it's only available to sighted mouse users, and even then causes problems for magnifier users and others. It's not available to sighted keyboard users or to anyone using a touch screen device.

We've spent decades drumming it into authors that alt="" means an image is hidden from AT. We haven't succeeded in getting the message through to everyone yet, so the last thing we need is to complicate the message by throwing title into the equation.

Yes, if we agree that alt="" means an image has no accessible name, there will be times when screen reader users miss information that would otherwise be useful to them.

But if we allow title to override alt="", there will be times when screen reader users will be presented with meaningless information not intended for human consumption (think SEO stuffing), or will get duplicated and/or conflicting information.

Like @scottaohara, I've seen title misused more often than not over the years, but in the absence of actual data (as opposed to anecdotal data) to indicate which of these scenarios is the more prevalent in the wild, I caution against assuming that either one is better for users than the other.

So my preference would be to accept this PR.

jcsteh · 2021-12-02T09:04:36Z

It's certainly fair to be cautious of assuming one situation is more prevalent than another. On the other hand, removing an element entirely means there is almost no possibility of a user working around that situation; e.g. in the case of a clickable image. In contrast, if the info is duplicated or slightly incorrect, the user has a chance of working around it, even if it's annoying, reduces efficiency or requires assistance the first time. To put this another way, you can learn that an incorrect label is incorrect, but if there's nothing there at all, you've got nothing to work with, incorrect or not.

jcsteh · 2021-12-02T09:06:20Z

As an adendum, keep in mind that we're talking about what gets exposed via APIs here. If something isn't exposed, an AT can't even consider the possibility of a hacky caveat emptor workaround mode.

tunetheweb · 2021-12-02T13:00:06Z

...but in the absence of actual data (as opposed to anecdotal data) to indicate which of these scenarios is the more prevalent in the wild...

Here's some data in case it adds to the conversation.

I ran a query on the raw responses (i.e. not the rendered page) of the 7.85 million mobile sites, and 5.77 million desktop home pages crawled by the HTTP Archive in November:

client	images	non_blank_alt	empty_alt	non_blank_title	non_blank_title_explict_no_alt	non_blank_title_no_alt_at_all	non_blank_title_explict_no_alt_aria_hidden
mobile	395,247,313	46.81%	23.16%	9.61%	1.02%	0.72%	0.0005%
desktop	317,977,523	46.38%	23.64%	9.40%	1.09%	0.67%	0.0004%

So it's about 1% of images that are in scope of what we're talking about here. Which is higher than I thought it would be to be honest!

What's more difficult to ascertain (and hence most of the discussion here!) is what the intent of those mixed signals were?

The last column shows aria-hidden was NOT set on the vast majority of those in question (perhaps not surprisingly given the developers here seem to be sending mixed signal so wouldn't really be expecting them to know much about aria-hidden), so that doesn't help.

Not sure if that helps or hinders the conversation.

SQL (warning this costs $136 to run, as that response bodies table is LARGE!)

SELECT
  _TABLE_SUFFIX AS client,
  --client,
  COUNT(0) as images,
  COUNTIF(
     REGEXP_CONTAINS(image_elements, '(?i) alt *= *\'[^\']+\'') OR
     REGEXP_CONTAINS(image_elements, '(?i) alt *= *"[^"]+"')
  ) AS non_blank_alt,
  COUNTIF(
     REGEXP_CONTAINS(image_elements, '(?i) alt *= *\'\'') OR
     REGEXP_CONTAINS(image_elements, '(?i) alt *= *""') OR
     REGEXP_CONTAINS(image_elements, '(?i) alt *[^=]')
  ) AS empty_alt,
  COUNTIF(
     REGEXP_CONTAINS(image_elements, '(?i) title *= *\'[^\']+\'') OR
     REGEXP_CONTAINS(image_elements, '(?i) title *= *"[^"]+"')
  ) AS non_blank_title,
  COUNTIF(
  (
     REGEXP_CONTAINS(image_elements, '(?i) title *= *\'[^\']+\'') OR
     REGEXP_CONTAINS(image_elements, '(?i) title *= *"[^"]+"')
     ) AND (
     REGEXP_CONTAINS(image_elements, '(?i) alt *= *\'\'') OR
     REGEXP_CONTAINS(image_elements, '(?i) alt *= *""') OR
     REGEXP_CONTAINS(image_elements, '(?i) alt *[^=]')
     )
  ) AS non_blank_title_explict_no_alt,
  COUNTIF(
  (
     REGEXP_CONTAINS(image_elements, '(?i) title *= *\'[^\']+\'') OR
     REGEXP_CONTAINS(image_elements, '(?i) title *= *"[^"]+"')
     ) AND NOT(
     REGEXP_CONTAINS(image_elements, '(?i) alt')
     )
  ) AS non_blank_title_no_alt_at_all,
  COUNTIF(
  (
     REGEXP_CONTAINS(image_elements, '(?i) title *= *\'[^\']+\'') OR
     REGEXP_CONTAINS(image_elements, '(?i) title *= *"[^"]+"')
     ) AND (
     REGEXP_CONTAINS(image_elements, '(?i) alt *= *\'\'') OR
     REGEXP_CONTAINS(image_elements, '(?i) alt *= *""') OR
     REGEXP_CONTAINS(image_elements, '(?i) alt *[^=]')
     ) AND (
     REGEXP_CONTAINS(image_elements, '(?i)aria-hidden*= *"true"') OR
     REGEXP_CONTAINS(image_elements, '(?i)aria-hidden*= *\'true\'')
     )
  ) AS non_blank_title_explict_no_alt_aria_hidden
FROM
  --`httparchive.sample_data.summary_response_bodies`,
  `httparchive.response_bodies.2021_11_01_*`,
  UNNEST (REGEXP_EXTRACT_ALL(body, '(?i)]*>')) AS image_elements
GROUP BY
  client

jnurthen

LGTM now

stevefaulkner · 2022-04-03T16:29:34Z

@scottaohara is this now ready to merge?

scottaohara · 2022-05-12T14:20:30Z

I am merging this PR, but please note that I do not consider this discussion resolved. Rather, this is being merged because I have other content I need to work on in this section of the document, and what's being merged matches 2 of the 3 implementations. If Firefox does not update to match the updated content of this PR, then nothing has actually changed. Rather, I would submit that maybe Firefox doesn't update at this time, as outside of this detail, they otherwise follow the spec. Instead, I have opened #404 with a summary of the discussion of this issue, and have provided a few proposals of what could be done next. I would very much appreciate feedback on that issue, and even alternative proposals if none of those seem feasible.

clarify img naming steps

7db8d84

related to w3c/accname#27

carmacleod approved these changes Mar 22, 2021

View reviewed changes

Merge branch 'gh-pages' into img-naming-clarification

133f6e8

This comment has been minimized.

Sign in to view

jnurthen requested changes Apr 8, 2021

View reviewed changes

scottaohara and others added 4 commits April 8, 2021 17:28

remove reference to note that’s no longer there

ac82b14

add in new note as a reminder that `alt=“”` means the `img` is meant to be exposed as role=presentation

Merge branch 'gh-pages' into img-naming-clarification

bea5d98

Merge branch 'gh-pages' into img-naming-clarification

70a0447

Merge branch 'gh-pages' into img-naming-clarification

6d32d6f

Merge branch 'gh-pages' into img-naming-clarification

6efc3af

stevefaulkner approved these changes Jul 20, 2021

View reviewed changes

scottaohara added 2 commits July 22, 2021 19:41

Merge branch 'gh-pages' into img-naming-clarification

e000d13

Merge branch 'gh-pages' into img-naming-clarification

e4ac277

scottaohara added the Agenda label Oct 7, 2021

scottaohara requested a review from cookiecrook October 14, 2021 18:00

Merge branch 'gh-pages' into img-naming-clarification

874522f

jnurthen approved these changes Jan 5, 2022

View reviewed changes

scottaohara removed the Agenda label Feb 6, 2022

scottaohara added 2 commits February 6, 2022 18:26

Merge branch 'gh-pages' into img-naming-clarification

6bdcade

Merge branch 'gh-pages' into img-naming-clarification

fdda789

scottaohara added 2 commits May 3, 2022 08:05

Merge branch 'gh-pages' into img-naming-clarification

968fb68

Merge branch 'gh-pages' into img-naming-clarification

b7ec1d1

scottaohara mentioned this pull request May 12, 2022

Further considerations for naming / exposing images #404

Open

scottaohara merged commit d509007 into gh-pages May 12, 2022

scottaohara deleted the img-naming-clarification branch May 12, 2022 14:20

JAWS-test mentioned this pull request Jun 21, 2022

Input type="image" - Accessible name computation #414

Closed

giacomo-petri mentioned this pull request Jun 22, 2022

"Image button has non-empty accessible name" [59796f] - clarification about input type image with empty alt but non-empty title act-rules/act-rules.github.io#1861

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

clarify img naming steps #322

clarify img naming steps #322

scottaohara commented Mar 22, 2021 •

edited by pr-preview bot

Loading

carmacleod left a comment

jcsteh commented Mar 24, 2021

joanmarie commented Mar 27, 2021

scottaohara commented Mar 27, 2021

This comment has been minimized.

jnurthen left a comment •

edited

Loading

jcsteh commented Apr 29, 2021

JAWS-test commented Apr 29, 2021

scottaohara commented Oct 7, 2021

cyns commented Oct 14, 2021

aleventhal commented Oct 14, 2021

cookiecrook commented Oct 15, 2021

aleventhal commented Oct 15, 2021

stevefaulkner commented Oct 20, 2021 •

edited

Loading

aleventhal commented Oct 20, 2021

scottaohara commented Oct 20, 2021

MelSumner commented Oct 21, 2021 •

edited

Loading

scottaohara commented Oct 21, 2021

cookiecrook commented Oct 21, 2021

jcsteh commented Oct 22, 2021

mcking65 commented Oct 22, 2021

LJWatson commented Dec 2, 2021

jcsteh commented Dec 2, 2021

jcsteh commented Dec 2, 2021

tunetheweb commented Dec 2, 2021 •

edited

Loading

jnurthen left a comment

stevefaulkner commented Apr 3, 2022

scottaohara commented May 12, 2022

clarify img naming steps #322

clarify img naming steps #322

Conversation

scottaohara commented Mar 22, 2021 • edited by pr-preview bot Loading

💥 Error: 504 Gateway Time-out 💥

carmacleod left a comment

Choose a reason for hiding this comment

jcsteh commented Mar 24, 2021

joanmarie commented Mar 27, 2021

scottaohara commented Mar 27, 2021

point 1 - author error

point 2 - title is not presently an attribute that can undo role=presentation

This comment has been minimized.

jnurthen left a comment • edited Loading

Choose a reason for hiding this comment

jcsteh commented Apr 29, 2021

JAWS-test commented Apr 29, 2021

scottaohara commented Oct 7, 2021

cyns commented Oct 14, 2021

aleventhal commented Oct 14, 2021

cookiecrook commented Oct 15, 2021

aleventhal commented Oct 15, 2021

stevefaulkner commented Oct 20, 2021 • edited Loading

aleventhal commented Oct 20, 2021

scottaohara commented Oct 20, 2021

MelSumner commented Oct 21, 2021 • edited Loading

scottaohara commented Oct 21, 2021

cookiecrook commented Oct 21, 2021

jcsteh commented Oct 22, 2021

mcking65 commented Oct 22, 2021

LJWatson commented Dec 2, 2021

jcsteh commented Dec 2, 2021

jcsteh commented Dec 2, 2021

tunetheweb commented Dec 2, 2021 • edited Loading

jnurthen left a comment

Choose a reason for hiding this comment

stevefaulkner commented Apr 3, 2022

scottaohara commented May 12, 2022

scottaohara commented Mar 22, 2021 •

edited by pr-preview bot

Loading

point 2 - `title` is not presently an attribute that can undo `role=presentation`

jnurthen left a comment •

edited

Loading

stevefaulkner commented Oct 20, 2021 •

edited

Loading

MelSumner commented Oct 21, 2021 •

edited

Loading

tunetheweb commented Dec 2, 2021 •

edited

Loading