Allow adaption of <figcaption> based on chosen <source>

[Boldewyn]

Based on this tweet: https://twitter.com/iandevlin/status/538313179450060801

The use case: A photo of 5 people, art direction cuts off the left-most human for some variants. Then a <figcaption>John Doe, 2nd from left</figcaption> is not possible reliably.

Possible fix: Re-use the for attribute:

<figure>
  <picture>
    <source id="wide">
    <source id="narrow">
  </picture>
  <figcaption for="narrow">John Doe, left-most</figcaption>
  <figcaption><!-- default caption: -->John Doe, 2nd from left</figcaption>
</figure>

[yoavweiss]

Looping in @stevefaulkner

[iandevlin]

Manuel/Boldewyn beat me to the bug report, but provides a very valid use case.

Here's another (and the one I am working with): A town photo, it is a wide ranging shot with a castle on a hill above the town. The initial caption reads something like "The town of Saumur, with a medieval castle and church tower its most prominent features".
A smaller image is then used for smaller screens which only features the castle or perhaps the church, and the previous caption needs to be changed to reference what is contained within the new image.

This is also a problem for alt attributes.

[Boldewyn]

The problem with @alt may be solvable by allowing @alt on the <source> elements. I'd be surprised, though, if that hadn't come up before. (...digging through the list archive...)

[anselmh]

I raised this concern I think years ago (was still in the beginning right after picture was proposed initially) and back then we kind of agreed that art direction shouldn't alter the alternative text of an image itself. I though still can imagine (as the examples of use cases show) that this could be useful sometimes.

I'm not familiar to the @alt CSS property but I could imagine this can help here if allowed by spec. Ultimately, back then I proposed to allow the alt-attribute on each source element which is, I think, not ideal as source needs to be altered and is not really thought to handle that.

[iandevlin]

Yeah, I mentioned that also on Twitter (https://twitter.com/iandevlin/status/538314872149540864), should have repeated it here, or perhaps create a new bug!

[zcorpan]

The idea is that all images should express the same information. Therefore alt should be the same for all images, since alt should also express the same thing.

Here's another (and the one I am working with): A town photo, it is a wide ranging shot with a castle on a hill above the town. The initial caption reads something like "The town of Saumur, with a medieval castle and church tower its most prominent features".
A smaller image is then used for smaller screens which only features the castle or perhaps the church, and the previous caption needs to be changed to reference what is contained within the new image.

This is invalid since you don't express the same thing. If you want to show the town, don't crop away the town.

If you want to show different information for different environments, that is not what picture is intended to do.

The use case: A photo of 5 people, art direction cuts off the left-most human for some variants. Then a <figcaption>John Doe, 2nd from left</figcaption> is not possible reliably.

This might be reasonable. If you find yourself needing this, I recommend doing it with javascript. You can listen for load events on img and check currentSrc. If this is a common problem then it could make sense to introduce something declarative, but right now we need to wait for browsers to catch up with the existing feature set.

[iandevlin]

It's easy for you/us to say that what I gave as an example above is invalid, but what if it's not? Why should we force people to art direct so that the image shows the same thing?

"Do it with JavaScript" is not a valid answer in my opinion, there should be a native way of doing this, otherwise why bother with a native method for responsive images?

[zcorpan]

We can't force people much of anything. What I meant is that the use case in this bug was not in the original set of use cases (http://usecases.responsiveimages.org), so it is quite intentional to not address it. If it turns out that many use it for something it was not intended and it's missing something important, we can re-evaluate, but it's not clear to me that we're there yet.

HTML is not about giving a declarative solution to 100% of use cases. More like 80% of use cases. The remaining should be implemented with javascript. This is the case for any given feature set in HTML, e.g. forms.

As to why we bother at all, this is discussed in the spec's introduction (mainly because a JS solution to responsive images means the author has to choose between double download or no image when the script doesn't run).

[stevefaulkner]

On 1 December 2014 at 10:04, Ian Devlin [email protected] wrote:

It's easy for you/us to say that what I gave as an example above is
invalid, but what if it's not? Why should we force people to art direct so
that the image shows the same thing?

specs describe conformance requirements (I think) intended to constrain
author use to practical application of the feature, given its limitations.
has the practical limitation that while devs can show 2completely different images via art direction, they shouldn't because thereis no built in mechanism to providing different alt texts.The advice in html 5.1 reflects thishttp://www.w3.org/html/wg/drafts/html/master/embedded-content.html#an-image-in-a-picture-element

Reality hat on:
the difficulty problem with as with graphics in general is to getdevs to provide ANY alt or an alt that is useful. provides thedefault mechanism for this via the img element.

As it appears that for the majority of cases of art direction, the
provision of 1 reasonable alt text will be sufficient and an a11y win! The
addition of a method to provide multiple alts (i think) would be an over
complication of an already complicated requirement.

"Do it with JavaScript" is not a valid answer in my opinion, there should
be a native way of doing this, otherwise why bother with a native method
for responsive images?

simon has answered this subsequently.

In respect to caption text: If it is the case that different art directed
images require different captions, is it not possible to use CSS to
hide/show the appropriate caption depending on image displayed?

Regards

SteveF

[Boldewyn]

Well, it would surely be possible:

<figcaption class="wide">Foo</figcaption>
<figcaption class="narrow">Bar</figcaption>

@media (min-width: like <source id="wide">) {
  .narrow { display: none; }
}
@media (max-width: like <source id="wide"> - 1) {
  .wide { display: none; }
}

But you'd bind your markup semantics to the stylesheet...

For a JS solution: Is there no other way than inspecting img.currentSrc to tell which <source> is selected at the moment?

[yoavweiss]

currentSrc is currently the only way to look into what was picked (and is changed after the image started downloading and its dimensions are known).

Is it not sufficient to cover the above use-case?

[yoavweiss]

I agree with @zcorpan that if different alt are absolutely necessary than you can provide that with JS (e.g. hang a data-alt on each <source> and have JS inspect currentSrc, find the source used, and switch the alt text).

I would also argue that there's no reason not to provide the user with the most descriptive alt on all viewport dimensions. The reason for art-direction is that the physical dimensions of the device the user is viewing the content with are limited, and we need to focus on the image's subject. That is not true for the text alternative. If you're using a screen reader to browse the content, your "physical dimensions" are identical regardless of the viewport dimensions.

[anselmh]

That is not true for the text alternative. If you're using a screen reader to browse the content, your "physical dimensions" are identical regardless of the viewport dimensions.

True, but just for the record, a screenreader is only one of many accessibility use-cases. Thinking of contrast issues and similar I would still see it as helpful to provide different alt texts. But I can also agree with Steve that we probably shouldn't make the spec more complicated right now—and if it's just for the moment to get people used to the current spec.

[mdmcginn]

I think Yoav has the right idea. Changing the viewport dimensions doesn't change the purpose of your web page. In my case, I want to display customized auto license plates. On wide screens, I show the license plate mounted on the back of the car, and on narrow screens I show just the license plate. What I want people to notice - what I want to say to them - doesn't change and neither should my alt="Custom license plate on Jeep Challenger".

When you crop an image of "The town of Saumur," that doesn't change the fact that "a medieval castle and church tower are the town's most prominent features". I don't see a typical accessibility use case for alt="John Doe, 2nd from left" (it wouldn't help screenreader users) so that may be solely a figcaption question.

[anselmh]

Dear @mdmcginn: Your first example doesn't relate to the use cases, it clearly isn't one that is meant here. It's all around the person containing stuff or if you want to describe something additionally as it's shown to the user. It's also not only about the alt text here but about captions which don't mean the image is not shown but means the image is shown. And as said, the accessibility use case doesn't only relate to no image is shown but to users that need assistance recognizing things viewing the image. To be clear: I think it's an edge-case and we shouldn't bother at the moment but state that it's doable via JS but it is a use-case and should be allowed, maybe also supported later on by spec and maybe even natively.

[yoavweiss]

To conclude:

• alt shouldn't be altered when the resource change, but even if there's a legitimate use-case for that, it can be resolved using a JS prolyfil.
• There seems to be a legitimate use-case for <figcaption> changes per source, but they're most probably not the typical-case. They can be resolved using a JS prolyfill or CSS hacks, and if we'd see they're wide-spread, we can consider adding a native solution for that use-case.

Closing, but feel free to open if you feel this needs to be further discussed.

[iandevlin]

Ok, for now.

I will build said polyfills and see how they go.

[zcorpan]

@iandevlin did you (or someone else) write a polyfill?

There's a new issue about this here: whatwg/html#6627