RE: Discussion: Text Alternative Survey

It doesn’t make sense to separate <figcaption> if its specific to <figure>, since figure is a container. At the time I made the comment I thought that <figcaption> could be a generic element for marking any element with a figure heading, which would need to be referenceable when the element in question was not a container.

e.g.

<hfig id="fig1">A title here </hfig>
<img header="fig1" ... />

<hfig> would be part of the <h...> series and could replace <caption> <legend> and <figcaption> which all basically do the same thing.

-----Original Message-----
From: Laura Carlson [mailto:laura.lee.carlson@gmail.com] 
Sent: Sunday, April 25, 2010 1:18 AM
To: Ian Hickson
Cc: Steven Faulkner; Maciej Stachowiak; Sean Hayes; Dave Singer; Matt Morgan-May; HTML Accessibility Task Force
Subject: Re: Discussion: Text Alternative Survey

Hi Ian,

>> I would be open to eliminating <figcaption> from the list of options, 
>> if we do not have solid rationale for it.
>
> The rationale is "in the scenario where the author knows the image is 
> critical and has a caption for the image, but does not know what the 
> image is

Would you say that <figcaption> could be used as a short text alternative instead of using an alt attribute when the author knows the image is critical content and also knows what the image is?

>> I think it was Sean who pointed out that if we want the figure to be 
>> equivalent to aria-labelledby we would need figcaption to be 
>> available outside <figure>.
>
> I don't see why we would want that. The idea of aria-labelledby is to 
> express an annotation to be passed on to the OS accessibility layer. 
> The <figcaption> element automatically conveys that annotation, by 
> virtue of its link with the <figure> element. It doesn't really make 
> sense to separate them, since then that role is lost. We already have 
> a feature that just does the OS accessibility API annotation, that's ARIA.

To do that naively I would assume. Is that correct Sean?

>> Are browser vendors actually ready to commit money and risk interop 
>> issues over [<figure>]?
>
> Yes, browser vendors have repeatedly indicated an interest in 
> implementing <figure> and <figcaption>.

Do any implementations currently exist? Are they widely implemented?

> If there is any text in the spec responsible for this confusion, 
> please let me know so that I can fix it.

The confusion lies in the fact that WCAG text alternatives advice and
HTML5 text alternatives advice differ. The two need to get in sync.

> WCAG is written in the context of HTML4, which required an alt=""
> attribute to be present even if the author has no alternative text to 
> provide and only had a caption. In that context, it makes sense to say 
> that if all you have is a caption, you would put the caption in the 
> place of the alternative text, even if that is semantically dubious.
>
> In HTML5, we avoid conflating the alternatives and purpose descriptions.
> This allows WCAG to suggest even more accessible solutions once ATs 
> have adapted to the broader model defined in HTML5.

If disambiguating alternatives and purpose descriptions is a goal, why not use @role for purpose?

>> I drafted a CAPTCHA survey last month [8]. It included Matt's idea of 
>> providing a "captcha" role on img to give user agents and assistive 
>> technologies a chance to call internal or cloud-based CAPTCHA solving 
>> systems like Webvisum, and validation/evaluation tools to mark them 
>> as an accessibility issue. Ian would you be open to something like this?
>
> If there is a proposal for providing a CAPTCHA cloud API, I am very 
> happy to consider it. Please file a bug.

I don't know if it is at the proposal stage, Matt?

Ian, could your give your first impressions of the idea here. That might make it easier to brainstorm and write a proposal.

> In the particular case of ARIA being mixed into the HTML conformance 
> layer, a simple example of a problem that would immediately be 
> introduced is that if someone decided to redo the way the page maps to 
> accessibility, they couldn't just remove all the ARIA annotations and 
> start over, because doing so might make their document invalid. On the 
> long run, it would make developing ARIA an increasingly difficult task 
> as it would effectively couple ARIA and HTML -- instead of being able 
> to revise ARIA independently when problem are found, any change to the 
> image labelling in ARIA would require a revision of HTML, which would pull in the rest of the HTML spec.

This seems to add complexity all right. I'd like to hear from our ARIA specialists on this.

>> I think I understand the reasoning behind "images whose contents are 
>> not known" section now. That has baffled me for the longest time. It 
>> is an attempt to mitigate damages. Right?
>
> Yes. Sorry, I thought that was clear -- why would people be suggesting 
> changes to it if they didn't understand what it was for?

Because it is counter to WCAG.

> Is there something I can add to the spec to make the intent of the 
> section clearer?

Maybe add "This section of the spec is intended is to improve WCAG but the two specs are currently in disagreement."

Ian, the idea of separating alternatives and purpose descriptions may be good. But writing such accessibility rules into the HTML5 spec is the wrong way to go about it.  WAI could say to you,"file a bug on WCAG".  Maybe they will...I don't know... But we have this task force set up to try to discuss and resolve such things. Let's give it our best effort to figure it out here.

What do people think of Ian's idea of separating alternatives and purpose descriptions? Would that be helpful?

Best Regards,
Laura

--
Laura L. Carlson

Received on Monday, 26 April 2010 17:17:59 UTC