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 Sunday, 25 April 2010 00:18:40 UTC