Re: Adaptive Image Element Proposal

On Sun, 02 Sep 2012 03:57:00 +0100, Leif Halvard Silli  
<xn--mlform-iua@målform.no> wrote:

>> <picture>
>> <img alt="text alternative">
>> </picture>
>
> So, just to be 100%: Based on how JAWS + Firefox 13+ handle the canvas
> element[1], then AT users would experience the picture element the
> following way::
>
> 1. the picture element would itself not be announced (unless
>    authors added a role (e.g. role=img) to the picture element) and
> 2. in case there were no <img> element in the fallback, then AT users
>    would not be told that there was any image here.
>
> So, they would not experience it.

I think it's fine that UAs that don't support <picture> simply read the  
content. After all it's an alternative, not a meta-description of the  
markup. As long as the alternative content is useful, it shouldn't be  
important that originally it has been implemented using an image in a  
visual medium.

e.g.

<picture src=yellow-triangle.png>Warning!</picture> Alt is tricky.

is fine if it's read as:

"Warning! Alt is tricky"

rather than something noisy like:

"*Picture* Warning! *Text* Alt is tricky"


> (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.)


UAs that do support <picture> natively can be smart enough to avoid  
announcing fallback <img> redundantly (e.g. either don't announce  
<picture> when it has <img> in it, or announce <picture> and then just  
read following <img>s as if they were plain text of its alt attribute).

-- 
regards, Kornel

Received on Tuesday, 4 September 2012 19:28:43 UTC