W3C home > Mailing lists > Public > public-respimg@w3.org > August 2012

RE: Adaptive Image Element Proposal

From: Adrian Roselli <Roselli@algonquinstudios.com>
Date: Thu, 30 Aug 2012 15:30:41 +0000
To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
CC: HTML WG <public-html@w3.org>, "public-respimg@w3.org" <public-respimg@w3.org>
Message-ID: <0CB063710346B446A5B5DC305BF8EA3E2635A9@Ex2010MBX.development.algonquinstudios.com>
> From: Leif Halvard Silli [mailto:xn--mlform-iua@målform.no]
> > Adrian Roselli, Thu, 30 Aug 2012 13:18:24 +0000:
> > >> From: Leif Halvard Silli, Thursday, August 30, 2012 8:53 AM
> 
> >> <picture alt="Alernative text" id="pict" >
> >>   <img src=file  aria-labelledby="pict"/> </picture>
> 
> > IE 6-9  usage is not exactly zero, and IE10 may be out before this is
> > supported. In that case, the <img> element is the only thing that will
> > be recognized and so the redundancy is necessary.
> >
> > The ARIA attribute is meaningless in that case since the browser won't
> > pull it from an element it doesn't know.
> 
> The premise of your conclusion seems wrong.

I get that a lot.

> An ARIA supporting AT will pull the content from any element, known or
> unknown. The only issue is, thus, that IE6 to IE8 does not support
> new/uknown elements. However, even this should not be an issue since the
> alternative text is kept inside an attribute. So, e.g. IE6 to IE8 would - due to
> their peculiarity - treat the above picture element like two elements:
> 
> <picture alt="Alernative text" id="pict" />  <img src=file  aria-
> labelledby="pict"/> </picture/>
> 
> Thus, as you can see, this should work. And I believe it does work, to the
> degree that ARIA works in the specific version of Windows. (It does work in
> XP, it seems, or at least AT which support ARIA do work on XP.) When it
> comes to IE9, however, then it does support unknown/new elements.

When I speak of ARIA support I have to admit that my understanding of its support in AT devices isn't terribly good. I am not in a position to test it (not right now) so I made the assumption that if my browser cannot understand the element, it cannot hand it off to any layer on top of the browser.

My other thought when I wrote this was that not all users in need of accessibility assistance use add-ons that support ARIA. On top of that, some users just have blocked images (corporate policies for images loaded from third-party domains, for example). Those users won't necessarily have any way to access ARIA information.

Is it fair to assume there are users who can benefit from @alt who are using browsers that do not support <picture> and do not have any ARIA-capable AT either?

If not, then I am running at windmills. If so then I still believe the redundancy is necessary.


> >> (2) Also, if the picture element is the content of an figure element
> >> with a figcaption, then the img should not need to contain the alt
> >> attribute. (This may not need to be said - perhaps HTML5 already
> >> cover this.)
> >
> > Again, this presumes the browser supports HTML5's <figure> and
> > <figcaption> element, which older browsers do not (and will not).
> 
> If you really believe this is bad, then you should file a bug against HTML5's
> permission to drop the alt attribute completely - omit it - when the img
> element is the sole content of a figure element which has a non-empty
> figcaption element. (Check what HTML5 says about use of alt for the img
> element.)

I had been staying up on the dropping of @alt on <img> for <meta name="generator">, but had not followed along on <figcaption> apparently. I am not in favor of dropping @alt from <img> in any current scenario.

> The question I ask - "perhaps HTML5 already cover this" - relates to whether
> it is necessary to say anything, in the spec. But it probably is.

I suspect it is, if only to ease the reader's need to keep going back and cross-referencing.


> >> (3) If the picture is presentational (has empty alt), then the img,
> >> if any, would need to have empty alt as well.
> >
> > If I am reading this correctly, you want the spec to state that an
> > @alt value of blank should be repeated on the <img>. If so, the
> > wording already says that. The spec says to match the value, and blank
> > is still a value.
> 
> It says that one should repeat the @alt content in order to "fall back
> gracefully". As you know, presentational elements usually do not have
> fallback. Or, at least, it is common to think that they doen't. So I still think that
> the spec should point this out.

A fair point, however I disagree with your assertion that I know that presentational elements usually do not have fallback. I believe you are right but I deny that I know this as fact. What I do know from developer forums, blogs, tutorials, etc. that I read is that developers already implement empty @alts as "fallback" for presentation-only images. This is really a semantic discussion and I think the wording is clear enough. Match values. Simple.

> >> In bug 18384 [2], we discuss other ways to provide fallback. Perhaps
> >> those methods should be reserved to situations when picture is given,
> >> by the author, another role than "img" or "presentation" - e.g. if it
> >> has 'document' role. Thus, it may be necessary to specify further
> >> rules about the fallback so that the fallback is not used in ways
> >> which are inconsistent with its role as alternative text.
> >
> > This is where I wonder if @longdesc was ignored prematurely.
> 
> So, on which element would you have placed the @longdesc? For the use
> case I had in mind, see the example below. Thus I think @longdesc is
> irrelevant. (Adding @longdesc to picture could in theory be relevant,
> though.)
> 
> <picture role="document">
>   <source src="foo >
>   <p> Markup goes here </p>
> </picture>

On the <img>. For the handful of developers who understand it and use it today, it's not a change. The <img> is still the fallback for lack of <picture> support  and I feel should behave as if no <picture> existed at all in the code.
Received on Thursday, 30 August 2012 15:31:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:06:07 UTC