Re: Adaptive Image Element Proposal

Mathew Marquis, Tue, 4 Sep 2012 13:47:22 -0400:

I continue to side with Steve, Chaarles and other in their preference 
for markup-fallback as alternative text of the <picture> element. 
However, I want to make a point that should be valid regardless of 
picture's role and content model. See below.

> I am still curious about the viability of allowing an `alt` specified 
> on the fallback `img` to “bubble up” to the parent `picture` element 
> — if that should be possible, I think it would be ideal if we could 
> mention that specifying an `alt` on the fallback `img` applicable to 
> the parent `picture` is also a valid approach.
  [...]
> On a separate note: I do think `role="img"` should be an essential 
> part of any `picture` polyfill. Steve, are you okay with my copying 
> your post above and filing an issue on Picturefill ( 
> https://github.com/scottjehl/picturefill/tree/div-markup-currentprop 
> ), so I can address this as soon as possible?

You mention role=img as polyfill. Then keep in mind that this is how 
role=img works, See WAI ARIA on Children Presentational/presentational 
children.[1][2] 

   <foo role=img>
      You may write what ever you like here but AT do not see it 
      anyway. (And that's why the HTML5 spec demoes it effect with
      an ASCII art example.)
   </foo>

Thus: <picture role=img> means that AT, from day one (as long as they 
support ARIA) will pick the alternative text from the <picture> element 
rather than from the <img> element - regardless of whether the user 
agent supports <picture>. In fact, the child <img> element will just be 
ignored. Meaning that the role of the <img> element, accessibility 
wise, only becomes to display as visible fallback to sighted users when 
the image for some reason does not load.

However, it could be argued that it would be better to advice *against* 
role=img as part of the polyfill. Why? Well, because once we apply the 
img role to <picture>, then we are also faced with AT bugs related to 
use of role on unknown elements. For instance, in IE8 and below, then 
each unknown element becomes *two* uknown elements. Which means that if 
you do the following - without also using the HTML5 shiv, then AT 
perceives two image elements - the foo element and the img element:

   <foo role=img alt="Text.">
    <img alt="Text." />
   </foo>

To instead just wait for AT and UAs to pick up the semantics of the new 
element thus seems to me like a better approach.

However, if we would like the img element to "bubble up", then (as you 
should see from the above and from the ARIA reference), there is a 
*design* reason to never ever pick "img" as the role of <picture>: 
Since the img role hides the children, then the choice of img role 
would close the door from the bubbling up option. It is not even a 
given that <picture> should be given any of the (current) ARIA roles - 
*may be* it it would be better to give the task to UAs themselves, like 
ARIA already does for many elements, such as for instance HTML <table>.

Also, once we start to fiddle with role=img, then the question becomes: 
Why not use aria-lablledby as well? After all, we are in ARIA land 
anyhow ... I don't say this because I want you tool look at the 
aria-labelledby option once more but because I think Steve's proposal 
needs more consideration.

>> (Strictly speaking, and despite the canvas behavior, the AT *could*
>> probably announce the picture — e.g. it could say ‘Picture!’. But
>> if so, if there could perhaps be confusion e.g. if it found <img>
>> element inside the picture.)
> 
> Fortunately (in a sense), this is a fundamentally broken scenario 
> even outside the realm of a11y: without specifying a fallback `img`, 
> no user in an unsupported browser would know an image existed. I 
> think this is a fairly unlikely situation, at least for a long time 
> yet — it wouldn’t be an “out of sight, out of mind” sort of error on 
> the part of a careless author.

I think, without doubt, that it is necessary to specify what is 
supposed to happen (once <picture> is supported) in case there is a 
<picture> with @alt but no <img>. Imagine, for instance, that the 
images of the <picture> don't load or that the UA do not render images: 
Would the @alt of the <picture> then be displayed? (I am not thinking 
of unsighted AT users - I think about all others.) Personally, I tend 
to think that it should be one of the characteristics of the @alt 
attribute that it get rendered, visually, if the image is disabled. 
And, if that is not the case - namely, the attribute does not  and is 
not supposed to render when the image does not load, then we are other 
attributes available - first and foremost the @aria-label attribute.

[1] http://www.w3.org/TR/wai-aria/complete#img

[2] http://www.w3.org/TR/wai-aria/complete#childrenArePresentational

-- 
leif halvard silli

Received on Tuesday, 4 September 2012 20:24:35 UTC