Re: [html-techs-tf] caption vs alt

Hello, Detlev and all.

I cannot see how the @alt would add more redundancy than the figcaption 
itself. As I've mentioned, the user needs both the information about the 
image and the figcaption, so the alt would just provide the information 
for the image, while the figcaption would provide information for the 
"box". Yes, maybe both are the same, but both must be readable.

For example, using the following code:

<figure>
   <img src="einstein.jpg" alt="Albert Einstein" />
   <figcaption>Albert Einstein<figcaption>
</figure>

In a quick test, navigating using the down arrow key with Firefox 25 + 
Jaws 14, the <figure> is announced as a "frame" identified with the 
<figcaption> content: "frame start Albert Einstein". Then the graphic is 
announced with its alt attribute "graphic Albert Einstein", and after 
that the <figcaption> is read as a simple paragraph "Albert Einstein".

In principle, it is a bit confusing that the "frame" is not in the 
"frames" listing and therefor is not accessible using the "M" key, but I 
think that the verbosity level is ok. The user receives both the 
information about the image and the caption itself, and the "box" is 
properly identified. The image is also accessible using the "G" key and 
apparas in the images listing through Jaws+Ctrl+G. Maybe the figcaption 
could be announced with other role, something like "caption" or similar, 
but I don't perceive extra redundancy.

Now, if we admit that the alt can be suppressed, the only difference 
would be that the image's accName is taken from the <figcaption> 
content, but the final result should be the same for the user.

In any case, given the lack of accessibility support, I would not even 
consider to include an advisory technique, because it doesn't solve any 
barrier, but generate a new one (the user ignores that there is an image).

Regards,
Ramón.

Detlev commented:

> Even if it has been WCAG WG practice so far to class techniques with future potential but no or weak current accessibility support as 'advisory', I think advisory is a misnomer. Under this heading, a developer is likely to look for techniques that, while not ensuring that a particular SC is met, will still improve accessibility today, if marginally. Would an advisory figcaption technique then suggest figure / figcaption as a coding option that must have alt as a fallback? This may lead to redundancy / verbosity in some situations.
> 
> Joshue O Connor schrieb am 13.01.2014 21:44:
> 
>> Ramón Corominas wrote:
>>> The problem with sufficient techniques that have no accessibility
>>> support is that developers rely on them anyway,
>> Generally techniques that have little to no support would be classed as 
>> 'advisory' - with this one - as it is likely one of the new wave of 
>> sufficient techniques we need to ensure that the samples we give are as 
>> robust as possible, or indeed as likely to be very soon.
>>
>> Technologies always change, so we need to try to future proof our 
>> techniques - as well as ensuring they work.
>>
>> A balancing act I know.
>>
>> Josh
>>
>>
> 
> --
> Detlev Fischer
> testkreis c/o feld.wald.wiese
> Thedestr. 2, 22767 Hamburg
> 
> Mobil +49 (0)1577 170 73 84
> Tel +49 (0)40 439 10 68-3
> Fax +49 (0)40 439 10 68-5
> 
> http://www.testkreis.de
> Beratung, Tests und Schulungen für barrierefreie Websites
>

Received on Tuesday, 14 January 2014 09:11:01 UTC