New controls attribute for img element

[yoelhawa]

Description of bug or feature request

With the proposal of a new controls attribute for the HTML img element, the section of the HTML-AAM mapping for the img element should add a note that's similar to the one the video element has regarding controls.

Will this require a change to CORE-AAM?

No, just HTML-AAM

Will this require a change to the ARIA authoring guide?

No

[scottaohara]

with the video element, for example, the element is exposed as a group so having a toolbar of controls as a descendent of the element makes sense. Rendered images historically have never allowed child/descendent elements, so I'm currently thinking the toolbar of controls would need to be implemented as a sibling to the image in a11y tree...

For instance,

<div role=image aria-label=foo>
  text goes here
  <button>bar</button>
</div>

Windows screen readers can't access the text within the named "image". VoiceOver on macOS doesn't fair much better. Windows keyboard focus can move to the button, but the screen readers won't announce anything being that it's a child of an image - and being a child of an image should not be possible. I don't think it's reasonable for this to be implemented in a way that would require AT to have to change how they've always behaved - since that would mean this new feature would be inaccessible until AT got around to updating and users also then updated their AT.

The controls should probably be rendered as a sibling to the image in the a11y tree. It might be helpful if implementors also created a "group" in the a11y tree to contain the image and the toolbar - mirroring how video works.

Adding this to the ARIA agenda to see what others in the group think on this.

[MelSumner]

This seems a little odd
But I think maybe this is why folks currently reach for figure and figcapture element(s) for these kinds of use cases, yes?

[css-meeting-bot]

The ARIA Working Group just discussed New controls attribute for img element.

The full IRC log of that discussion

<Zakim> agendum 5 -- -> New controls attribute for img element https://github.com//issues/601 -- taken up [from agendabot]
<Adam_Page> jamesn: scott?
<Adam_Page> scott: I wanted to bring this up to get additional thoughts on it
<Adam_Page> ... there is an HTML proposal to add a `controls` attribute to images, much like video and audio
<Adam_Page> ... not sure what the controls would be other than play/pause, and maybe a button to show alt text
<Adam_Page> ... my reason for bringing this up is that with audio and video, those elements act as a group container for other content within
<Adam_Page> ... for images, those have never been groups — except SVGs
<Adam_Page> ... screen readers don’t really let you navigate _inside_ an image
<Adam_Page> ... we could have a similar note in HTML-AAM as with audio/video for how controls should be exposed and mapped
<Adam_Page> ... but I’m thinking it’d need to be a sibling
<Adam_Page> ... or browsers would need to sprout a container for the image plus its controls
<Adam_Page> ... if there are any other thoughts, please review and comment
<Adam_Page> ... I basically just think a toolbar “inside” an image just won’t work
<jamesn> Q?
<Adam_Page> ... implementors, especially, please consider how you would actually do this?
<Adam_Page> jamesn: if we were to say that the control thing has to be a sibling, would you expect pushback from HTML folks?
<Adam_Page> ... or could it be put in the spec?
<Adam_Page> scott: I don’t think it’d be a problem; they should already know
<jcraig> q+
<jamesn> Ack jc
<Adam_Page> jcraig: platforms do have the ability to put child nodes inside of images
<Adam_Page> ... there’s an existing svg-aam issue that I filed about that specific thing in the context of accessible svg
<Adam_Page> ... right now, you have to expose it as a group instead of an image
<Adam_Page> ... because of limitations in ARIA
<Adam_Page> scott: that’s what I was alluding to — the browser could “sprout” a group around the image
<melsumner> Question: how do you imagine backward compat working?
<Adam_Page> ... so that AT could find it when navigating by images
<Adam_Page> jcraig: that describes today, but could we see a way to allow images to begin exposing themselves _as_ a group?
<Adam_Page> ... currently within ARIA, there’s no distinction between types of groups
<jamesn> Q?
<giacomo-petri> q+
<Adam_Page> scott: I think my concern here would be that anything to be done here that would require — especially in Windows, where people won’t be updating their AT along with browser updates — I would be nervous about
<Adam_Page> ... if it ships in HTML, it should “just work” without requiring AT changes
<Adam_Page> jcraig: with the <div role="image"> example you’ve written in the issue, are you suggesting that implementations should be able to account for that? And change the role to `group`, or recognize the author’s intent somehow?
<Adam_Page> scott: I put that in there just to illustrate using ARIA
<Adam_Page> ... but this will be an HTML feature, so there’s nothing an author should have to do
<Adam_Page> ... the question is “what would we want the implementation to be?”
<Matt_King> q+
<Adam_Page> ... so that screen readers, etc., don’t also need to be updated
<jamesn> Ack gi
<Adam_Page> giacomo-petri: when you navigate an image, you don’t expect content inside
<Adam_Page> ... if you have a “group image”, how can you determine that it is just a group of related images inside, or if it’s because there are controls inside
<jcraig> q+ to say I think we could align on the same behavior for the native example as well as your ARIA example <div role=image aria-label=foo> text goes here <button>bar</button></div>
<jamesn> Ack mat
<Adam_Page> Matt_King: how do we learn more about the use cases for this controls attribute?
<Adam_Page> scott: this is a proposal in HTML
<Adam_Page> ... for a controls attribute
<Adam_Page> Matt_King: what problem is the proposal solving?
<jcraig> q+ to mention WebKit's similar precedence with the button for playing animated GIFs when "reduce motion" is enabled.
<Adam_Page> q+
<Adam_Page> scott: I don’t have an answer for that
<Adam_Page> ... the suggestion was essentially to just copy what the video and audio elements already do
<Adam_Page> ... but this isn’t the same as those elements, since they are already serve as a group
<Adam_Page> Matt_King: okay, I’ll review and leave some feedback
<Adam_Page> ... also, big +1 to your mindset that we shouldn’t break anything
<jamesn> Ack jcraig
<Zakim> jcraig, you wanted to say I think we could align on the same behavior for the native example as well as your ARIA example <div role=image aria-label=foo> text goes here
<Zakim> ... <button>bar</button></div> and to mention WebKit's similar precedence with the button for playing animated GIFs when "reduce motion" is enabled.
<Adam_Page> jcraig: little fuzzy on the details, but there’s a button that allows animated GIFs to stop playing
<Adam_Page> ... but wanted to respond to scott
<Adam_Page> q-
<Adam_Page> ... I think there’s a path forward that could satisfy the “don’t break things” principle
<Adam_Page> jamesn: please review and add comments
<jamesn> GitHub: https://github.com//issues/601
<jamesn> github https://github.com//issues/601
<jamesn> github: https://github.com//issues/601
<Adam_Page> zakim, next item

[zcorpan]

What should the a11y mapping be when there are controls and the image has empty alt?

[scottaohara]

what would the controls represent for a decorative image?

should that combination even be allowed?

regardless, in such a case i'd think that it'd still need to be exposed as an image - otherwise controls would be available that would appear to control "nothing", in regards to what'd be exposed in the a11y tree...

[zcorpan]

I think the controls provided would be the same for the empty alt case as non-empty alt (e.g. fullscreen viewing, or play/pause for animated images).

Exposing "image" in that case instead of nothing makes sense to me.

[yoelhawa]

WebKit has an implementation that does basically what @scottaohara suggests (putting the controls and image together as siblings within a parent "group" in the a11y tree).

Had not previously considered the empty alt case, but exposing "image" seems reasonable to me.