Re: Adaptive Image Element Proposal

Laura Carlson, Wed, 5 Sep 2012 07:26:27 -0500:

> Alt should work for a SHORT string text alternative that is read out
> automatically as previously discussed.
> 
> Any LONG text alternative would require user choice of consuming and
> the ability for authors to use rich HTML structural elements, e.g.,
> for complex images, charts, graphs, infographics, etc. One of the
> advantages of longdesc is that it enables users to utilize shortcut
> keys that rely on structure to perform functions. Any proposed long
> description element should not provide less functionality. For
> accessibility, structural markup is important because software can use
> structure to perform functions for the user and provide better access
> to content.

Both ideas - <pictcaption> and <desc> - have the problem that until 
support is ready, it is hard to avoid that users receive both the short 
and the long alternative text.

Else: I see that you don't like <pictcaption> because you think it does 
not provide for a way to discern between long and short description. 
OK. But note that I did not say that one could not provide "long" 
content outside <pictcaption>, the same way that the <figure> element 
allows content inside <figcaption> as well as in the "body".

In my message to Kornel [1], I suggested that two content models are 
possible with regard to accessible content: 

Model (1) - the img like model, where short and long content
            has designated child elements. Many think that the
            short text should be provided by <img>. But this model
            is also where both <pictcaption> and <desc> fits in.
Model (2) - the canvas like model, where <picture> itself has no
            role (other than as a presentational container).
            Here we can place a <details> or whatever, to create
            the experience we want.

But are <desc> really be necessary? As long as the short text is 
provided via <img> - by default - then "everything else" would be the 
long content. And thus, JAWS should be perfectly able to ignore "the 
rest" - until the user eventually asks about it. Not? 

Anyway. May be a third model is the best - one which combine of model 
(1) and (2) - a model (3);

<picture>
 <details>
   <summary>
 <img alt="Alternative text." src="f" >
   </summary>
  <ul>
  <li>A 
  <li>small
  <li>list
  </ul>
 </details>
</picture>

Explanation: Let's imagine two parsing modes. A "short accessible 
content" mode and a "long accessible content" mode. In the short mode, 
when seeing the <picture>, AT looks for the child <img> in order to 
establish the short alternative text. We must here imagine that there 
is an invisible aria-labelledby which points to the <img> element. 
Thus, when parsing <picture> in this mode, the other content is just 
ignored. However, at user option, the AT could jump out of <img> and 
present the content of <picture>. In the above example, that would be a 
details element. But it could be another element to - like figure.

The <details> element could work now, in many/most UAs. But it is quite 
difficult to style in such a way that it gets completely hidden inside 
<picture>. One could also use aria-describedby to point to the 
<details>. I think, in that case, the aria-describedby should point 
*from* <picture> to <details>. (And not from <img> to details.)

We should also think about what will happen when neither <img> nor the 
<source> files of <picture> will render any image. <details> would work 
in that case. Whereas a <desc > would not work unless it had the 
@hidden attribute set and unless AT would then render - rather than 
'flatten' - tables, lists etc.

[1] 
http://www.w3.org/mid/20120906014959201677.b0236edd@xn--mlform-iua.no

-- 
leif halvard silli

Received on Thursday, 6 September 2012 04:46:50 UTC