Consider adding a 'decorative image' role

[scottaohara]

Description of bug or feature request

Creating this issue to start up a conversation relating to one of the proposed solutions to https://github.com/w3c/html-aam/issues/404.

Presently the importance of images is treated as an odd boolean where authors either need to decide (or are told) that certain images are important to convey to AT, while others are decorative and can be treated as if they were hidden. This need to markup an image as 'informative or decorative' essentially means that authors are telling users of AT what is important for them to know about, and doesn't take into account that some users may want to know what these decorative images represent.

However, if there were a role (or other aria-* attribute... whichever tbh) that could be used to indicate that an image with alternative text is available to AT, but has also been explicitly marked as decorative, so AT can allow users to decide if they want to interact with these images or not.

As mentioned, this could then be a way to resolve the above mentioned HTML AAM issue, where an author has specified an image as having a null alt - the long standing indicator that an image is decorative - but also provided a title, indicating that there is some level of information available, but is either an author error in how the image should have been marked up, or is communicating potentially nice to have (or nonsense) information that users should be able to decide if they want to make it discoverable, or not.

Will this require a change to CORE-AAM?

It will if this proposal gets any traction.

Will this require a change to the ARIA authoring guide?

It will if this proposal gets any traction.

PR tracking (for feature tracking, leave as is when submitting)

• ARIA PR:
  • Editor's Draft commit:
  • Working Draft commit:
• Core AAM PR:
• AccName PR:
• APG PR:

Implementation tracking (for feature tracking, leave as is when submitting)

• WPT test:
• Implementations (link to issue or when done, link to commit):
  • WebKit: [ISSUE]()
  • Gecko: [ISSUE]()
  • Blink: [ISSUE]()

[chlane]

This is great. Does it have to be limited to images? I'm wondering if it can be used for animations/motion.

[jnurthen]

Discussed at https://www.w3.org/2022/06/02-aria-minutes.html#t05

[scottaohara]

potential alternative name "contextual-image"

[brennanyoung]

I approve of this but if we're going there, I would like to see the "connotative" case considered too, and as distinct from "decorative".

Connotative (or "mood-setting") images fall somewhere between content and decoration, and have generated far too much discussion at my workplace, and with our auditors who (being outside the problem domain) often can't tell the difference.

The "child with the balloon on the account sign-up page" case mentioned in the aria minutes has this quality. It suggests "we're a friendly sort of folk, and we don't take ourselves too seriously", which is neither content, nor decoration. It sets a mood.

Any hooks we can provide to help users decide how much of these 'lesser' text alternatives they consume will be useful.

It has occurred to me that a combination of null alt (or null aria-label) with a non-null aria-description might be used to indicate a decorative image unambiguously. This would not require much change in the spec, maybe little more than an APG example, but the AT vendors would need to be on board.

Otherwise aria-something="decorative" or aria-something="connotative" seem viable (for some value of 'something') with the text alternative provided as a description, not a label. BTW I agree with @chlane that these semantics should be available for videos and animations, even audio, hence an attribute, rather than a role.

[giacomo-petri]

Hi everyone,

I’ve discussed this topic internally with our company teams. I'll use "decorative but with meaning" images to define this kind of images. We've identified pros and cons:

PROS

• allow users using assistive technologies to understand the visual presentation of an image
• allow users using assistive technologies to remedy devs errors, giving the opportunity to read some level of information, if available (e.g. empty alt and non-empty title)
• make mouse (hover event) and assistive technology experiences consistent for decorative images with title attribute (empty alt and non-empty title); browsers expose visually the title attribute value, assistive technologies will expose it too.

CONS

• increase rules complexity and related complexity in understanding requirements
• increase evaluation complexity (more cases to evaluate but also more subjectivity in the evaluation); sometime, while evaluating a page, it's hard to determine if an image is decorative or informative and only the author is aware about why the image has been added into the page, determining its role. With the introduction of this new "image type" (decorative but with meaning), we risk to relieving authors and content teams in determining which is the purpose of the content, making everything (or almost everything) acceptable
• we have to handle also HTML elements that support the ALT attribute such as inputs type="image" and area (e.g. empty alt and non-empty title); we are not sure if it makes sense to have a "decorative but with meaning" operable user interface component, but if devs implement it, what do we expect from it? How browsers and assistive technologies should expose them?
• how browsers will expose "decorative but with meaning" images into the accessibility tree? I've read the option to announce them just once. But in this senario it won't be neither an accessible name, nor a description. How do we handle with it? In addition, if images are marked as decorative and I filter the page by images (e.g. using VoiceOver rotor), which are the expectations? Right now the accessible name is displayed; how assistive technologies should distinguish decorative but with meaning from informative images?
• this new 3rd image option will considerably increase the number of cases and combination of attributes; for example:
  • links with aria-label containing only a single image that is "decorative but with meaning": if the image convey some level of information, do we expect that image information is announced while navigating the link or not?
  • similarly to the previous one, wrongly-managed operable controls without accessible name but with "decorative but with meaning" image inside (e.g. empty alt but non-empty title), do we expect that at least this level of information is communicated?
• assuming this rule of "decorative but with meaning" image takes hold, what will happen? Does it become a requirement, a best practice or a nice to have? I'm assuming that for the WCAG conformance it won't be a requirement, as decorative and informative images (if properly managed) are currently working. So, who will engage this scenario? If instead we treat it as a sufficient technique for 1.1.1, we risk to have misunderstandings. Big companies have multiple teams (designer team, devs team, marketing team, content team, SEO team, etc.), all involved in understanding how to handle images (and of course not only images). Sometime it's already hard to understand how to manage communications, especially for non-tech teams that face with tech teams, and not always everyone is aware about requirements and how to handle specific scenarios. I'm afraid it will become an overgrown jungle, without understanding real requirements.

• so AT can allow users to decide if they want to interact with these images or not.

  It's not clear if AT should provide an option to enable/disable this feature. If that's true, another risk is that AT users always activate it to relieving author/dev mistakes, making the page verbose without a real need. In addition, similarly to point 4, it won't be neither an accessible name, nor a description into the accessibility tree computation.

I have asked this question also to our user testing group (all members of the disability community), using a decorative/marketing/emotional image without a real meaning within the page. Answers:

• DN: In my opinion the image description does not enhance or add anything for me. I think there are instances where the description would be nice, and enhance the experience. I think it is very subjective though, and many users are just going to want the meaningful information only.

• M: This idea might be interesting for proficient and advanced users, but a new thing to learn for others. Coming from a person who is totally blind any sort of feedback from a website is good. Do you have anything like this already? If possible I’d like to try it out to give you my full opinion on the matter.

  Quick consideration and comment on M's feedback: blind users are not aware about the high number of decorative images available within a website, because they are simply ignored by assistive technologies. The user's request to try something ready is interesting. In addition this solution might be good in a perfect world, but I'm not sure what will happen with current overall poor-knowledge.

Last, but no least, the complexity in navigating web pages using a screen reader, especially considering that the majority of websites are not WCAG conforming, is higher than expected, resulting in very high task completion times compared to a "mainstream" navigation. Do we really want to include more information, considering that the majority of visual impaired users usually skips decorative images? Or it will do more harm than good?

[cookiecrook]

As discussed in the ARIA call this morning, it's almost like a hint for verbosity priority... E.g. Never read this if my SR verbosity is set to low or medium, but if it's high, or if I've landed on this in a non-linear context like touch exploration, this may/could be spoken or brailled.

Separate from that, I think the terms "decorative" and "presentational" have too much baggage associated with them. If the feature is needed, it should use separate terms that have no relational history to the concept: "totally devoid of meaning."

[jnurthen]

Propose a joint session with APA / WAI-ADAPT at TPAC

[spectranaut]

Discussion in the last WAI Coordination Call: https://www.w3.org/2022/06/29-waicc-minutes.html#item03

[scottaohara]

related https://github.com/w3c/aria/issues/1427