Fallback content - alternative text #6

Closed
yoavweiss opened this Issue Nov 1, 2012 · 41 comments

Projects

None yet

6 participants

@yoavweiss
Member

The alternative text aspect of <picture> (example in http://picture.responsiveimages.org/#example-of-usage) shows that element as a text node in browsers that do not support <picture>.
Ideally, a fallback solution would display only a fallbcak image, and no text on current browsers.
That can be worked-around by adding a display: none style on the alternative text element, but it's not ideal.

@anselmh
Member
anselmh commented Mar 9, 2013

As issue #23 is related and I've found that issue here, I'll quickly add something here, too:

The alternative text element is thought as accessible alternative text, not only as a fallback if picture-element is not supported. This means it is thought for screenreaders and similar devices that can only read/display text.

I am still thinking that is the best solution we can have for a future-proof specification. Also see my last comment in #23 for more information on the parsing and display-modes with the current fallbacks.

@yoavweiss
Member

Hiding the fallback content using CSS seems to be a common practice in such cases, so this might be a non-issue.
Any objections to adopting that practice and changing the examples accordingly?

@marcoscaceres
Member

I would support that. But would like a review and ok from accessibility folks

@anselmh
Member
anselmh commented Apr 26, 2013

You can hide through text-indent property in CSS. This is a common practice for alternate texts.

@nwtn
Member
nwtn commented Apr 26, 2013

Pretty sure text-indent doesn't work with Apple VoiceOver. HTML Boilerplate uses:

 /*
  * Hide only visually, but have it available for screenreaders: h5bp.com/v
 */

.visuallyhidden {
    border: 0;
    clip: rect(0 0 0 0);
    height: 1px;
    margin: -1px;
    overflow: hidden;
    padding: 0;
    position: absolute;
    width: 1px;
}
@uniqname
Member

With the img tag, the value of the alt attribute is expected to be used as fallback text when the image is not available or images are unsupported. Alt text is in fact displayed in most browsers where the image fails to load. Is an alt attribute on the picture element with the same expected behavior -- as opposed to additional text nodes -- insufficient for this use case?
http://responsiveimagescg.github.io/picture-element/#attr-picture-alt

@marcoscaceres
Member

so, part of the reason there is an alt attribute on img is that img does not accept children. Picture is different in that it supports having children that can be made accessible. The alt attribute is also very limited in that one cannot "mark it up".

@uniqname
Member

That's a very good point. It raises another question with me with respect to CSS pseudo elements --specifically ::before and ::after -- within picture. They are not supported on img since img has no internal content. They also don't appear to be supported on video which may have internal nodes (not sure the nodes count as content though). I assume the picture element would take cues like this from video, but perhaps not. I've come across a number of times where a ::before or ::after element would be very useful on an img, the same would apply to picture (or video for that matter).

On Sep 13, 2013, at 12:37 PM, Marcos Caceres notifications@github.com wrote:

so, part of the reason there is an alt attribute on img is that img does not accept children. Picture is different in that it supports having children that can be made accessible. The alt attribute is also very limited in that one cannot "mark it up".


Reply to this email directly or view it on GitHub.

@anselmh
Member
anselmh commented Sep 13, 2013

Although it would be better to stick to the behavior of img and video I think if there is a strong use-case we could specify that those pseudo-elements can be applied (although not sure). Can you elaborate on the use-cases please?

@uniqname
Member

Additionally, since <picture> does allow for the alt attribute, what is the interplay between alt and internal fallback content such as is described here? Do they serve different or overlapping purposes?

@uniqname
Member

@anselmh Sure, Creating a "Polaroid effect" or any number of drop shadow effects in an img, picture or video directly. These things can fairly easily be done with additional markup, which may already exists (i.e. the picture is in a figure), but that encourages display based markup.

That said, I don't know if it's worth diverging from the consistency that already exists

@Wilto
Member
Wilto commented Sep 13, 2013

I’m not certain we’d be able to have picture’s inner DOM inert if this were supported, which would mean the fallback image is always requested—it could potentially add serious bandwidth cost.

@marcoscaceres
Member

(just a note that I'm thinking of removing alt from picture to encourage people to do accessibility properly with this element.)

Where ::before and ::after are applied is something that needs to be defined by CSS, not by the element. The fact that ::before and ::after are not being applied to some elements sounds like a browser bug.

@nwtn
Member
nwtn commented Sep 13, 2013

Ya the fallback thing is tricky, without loading the img. I think complex fallback content is one of picture's great benefits, but it needs to be handled carefully. In addition to not wanting to load img if a source is chosen, we don't want a browser that can show the img to display, say, a child table element as well.

@nwtn
Member
nwtn commented Sep 13, 2013

sorry, hit the button too soon.

the way i've been thinking about it is no alt on picture, lazyload/postpone on img, and accessible fallback content after that, but hidden visually with CSS.

@marcoscaceres
Member

lazyload and postpone on img are not really helpful, as it's legacy browsers we are really concerned about... putting lazyload on stuff will still need to be polyfilled somehow.

@nwtn
Member
nwtn commented Sep 13, 2013

we want legacy browsers to load the img though, even w/ lazyload/postpone. that's desired behaviour. what we don't want is an ert (?) DOM that loads img in browsers that support picture

@uniqname
Member

picture > *:not(img) { text-indent: -999em} or some such for fallback/accessible content.

And the lazyload/postpone is there to allow the UA time to understand the img is in the context of a picture element yes?

@nwtn
Member
nwtn commented Sep 13, 2013

That specific way of hiding the text is inaccessible for Apple's VoiceOver I think, but yes, something like that. And yes, that's why lazyload/postpone are there. So:

  • legacy browser ignores picture, source, lazyload/postpone, loads img
  • modern browser postpones loading img, chooses a source, ignores img
  • assistive tech has access to visually hidden fallback content
@uniqname
Member

I image browser vendors would be able to tweak their asset prefetching algorithms to identify img as children of picture and exclude them from that optimization. But short of that, I don't see lazyload and postpone causing harm by having them there, and benifiting if the browser isn't looking for img within picture in their optimizations.

@marcoscaceres
Member

And the lazyload/postpone is there to allow the UA time to understand the img is in the context of a picture element yes?

Not quite, it would have no knowledge of the container. All that it checks for is for "is it visible to the user" (postpone)? or "do I need to load this now?" (lazy).

@marcoscaceres
Member

legacy browser ignores picture, source, lazyload/postpone, loads img

Correct

modern browser postpones loading img, chooses a src, ignores img

It postpones if it is "display: none"

assistive tech has access to visually hidden fallback content

This happens with display: none, yes?

@marcoscaceres
Member

Argh... fixing the above...

@uniqname
Member

Yes, but if the content of picture is to be inert, the UA will need to know the contents container at some point in order to not render it. If the browsers optimizations attempt to begin fetching assets even before the DOM is completely rendered, then explicitly deferring the fetching of the asset will exclude it from pre-DOM ready fetching until such time as UA renders the content of picture inert. But I am venturing WAY outside my comfort zone on browser prefetching optimization techniques so I could be talking a whole lot of nonsense here.

@nwtn
Member
nwtn commented Sep 13, 2013

My understanding is that postpone would give the browser time to realize img was a child of picture and hide it. Then, when the postpone check is done, img would not be visible and thus wouldn't be downloaded. Is that wrong?

display: none is hidden from assistive tech usually, AFAIK. The content needs to be hidden in a different way (e.g. #6 (comment))

@marcoscaceres
Member

@uniqname wrote:

But I am venturing WAY outside my comfort zone on browser prefetching optimization techniques so I could be talking a whole lot of nonsense here.

Welcome to the RICG :) We just need to try stuff out and see what works.

@marcoscaceres
Member

@nwtn wrote:

My understanding is that postpone would give the browser time to realize img was a child of picture and hide it.

No. The spec says:

The postpone attribute indicates that the User Agent MUST not start downloading the resource associated with the element until either the bounding box of the element is inside the User Agent's interpretation of the Document's viewport, or the element has been styled such that its display property is no longer set to none.

So, viewport or none.

@marcoscaceres
Member

(Aside: i wonder why they have two attributes... why not have a single priority="" attribute that can take lazyload, postpone, or both as an argument?)

@nwtn
Member
nwtn commented Sep 13, 2013

that's...limiting. could picture > img be set to display: none using the browser's default stylesheet, so that it works with postpone?

@marcoscaceres
Member

that's...limiting. could picture > img be set to display: none using the browser's default stylesheet, so that it works with postpone?

Sure, we could do that.

@marcoscaceres
Member

... but it would have to be picture img.

@nwtn
Member
nwtn commented Sep 13, 2013

right. ok, so:

  • no alt on picture; alt on img for legacy browsers
  • postpone on any img children of picture
  • modern browsers have picture img set to display: none by default
  • authors hide other non-img children of picture in such a way that they are still visible to assistive tech

Then:

  • Modern browsers postpone prefetch for img because of postpone, then don't load img because of the default style. They choose and display a source.
  • Legacy browsers ignore picture, source, and postpone. img is prefetched and displayed
  • Assistive tech has access to both img[alt] and non-img children of picture

Does that sound about right?

@uniqname
Member

authors hide other non-img children of picture in such a way that they are still visible to assistive tech

This is only relevant though for legacy browsers as picture supporting browsers would render this inert anyway correct?

@nwtn
Member
nwtn commented Sep 13, 2013

@uniqname Hmm. We don't want it actually inert, because we want assistive tech to see it. But, we don't want it visible either. I'm actually not sure what the best route to take for that is.

@uniqname
Member

Perhaps UA default styling that is off viewport but accessible to assistive tech. Basically, UA's do by default what we are suggesting authors do themselves. I don't know if UA's have already dealt with similar problems or if there is an accepted standard or not.

@nwtn
Member
nwtn commented Sep 13, 2013

@uniqname we should take a look at what video does with non-source children. If I remember correctly, @yoavweiss's test Chromium build w/ picture support shows the non-source, non-img children of picture by default, and it needs to be hidden with CSS.

But yes, UA default styling could probably be considered for this too.

@marcoscaceres
Member

Inner just means that the elements don't respond to interaction, but still participate in the DOM. As such, inner subtrees would be available to assistive technologies*

*terms and conditions apply - this needs to be tested, may cause damage to the liver and kidneys.

@nwtn
Member
nwtn commented Sep 13, 2013

@marcoscaceres Ya, I think testing is key. Status in DOM seems to have no impact on AT I've looked at (which is admittedly not much). Ignoring things with negative text-indent, for example, seems borderline insane to me.

@yoavweiss
Member

I image browser vendors would be able to tweak their asset prefetching algorithms to identify img as children of picture and exclude them from that optimization. But short of that, I don't see lazyload and postpone causing harm by having them there, and benifiting if the browser isn't looking for img within picture in their optimizations.

@uniqname - This issue is not about prefetching. It's about fetching, and without some indications inside HTMLImageElement itself (such as a postpone attribute), it is highly complicated to prevent loading here.
The reason is that the resource fetching start at the moment that the src attribute is set on the image element, before the element is added to the DOM. So the element does not know that its parent is a picture element.
Rendering the DOM inside picture inert (which means that the elements are still there, but are not triggering any resource download, and not running any scripts/styles) was discussed, but I'm not sure this the best way to go, since there are very few precedents. (basically, only template AFAIK)

@nwtn - the problem with hiding alternative text was for legacy browsers. Once picture is supported that content (as well as the image element) are invisible. They are still in the (ert) DOM, but are not part of the render tree AFAIU (didn't check specifically why they're invisible)

@nwtn
Member
nwtn commented Sep 16, 2013

@yoavweiss Great. As long as invisible != inaccessible to assistive technologies.

@yoavweiss
Member

This is more or less irrelevant in the latest, img-driven specification, that keeps using the good(?) old alt attribute. Even though a richer alternative text could be added, I think it's important to keep things as simple as possible for now. Closing.

@yoavweiss yoavweiss closed this Jan 2, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment