W3C home > Mailing lists > Public > public-html-a11y@w3.org > April 2010

Re: Discussion: Text Alternative Survey

From: Laura Carlson <laura.lee.carlson@gmail.com>
Date: Sat, 24 Apr 2010 13:21:03 -0500
Message-ID: <z2s1c8dbcaa1004241121k2becac71u2f5681ef6abb0ba8@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: Steven Faulkner <faulkner.steve@gmail.com>, Maciej Stachowiak <mjs@apple.com>, Dave Singer <singer@apple.com>, Matt Morgan-May <mattmay@adobe.com>, HTML Accessibility Task Force <public-html-a11y@w3.org>
Hi Ian,

> As I understand it the only proposed non-ARIA solution is <figcaption>,
> which is supported even less by ATs than title="".

I would be open to eliminating <figcaption> from the list of options,
if we do not have solid rationale for it. Steve mentioned,
<figcaption> content is available by default to all users and it is
not hidden. These are good points but are they enough?

A couple of comments from the face to face meeting minutes seem
relevant. 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>. And complete equivalence
between figure and aria-labelledby would require the figcaption could
go anywhere and have a pointer to the caption.

Ian can you make that happen?

You once explained your nine step procedure [1] for adding new
features to the spec. You concluded by saying that the default state
for a feature request is for it to be rejected and the default state
for a section of the spec was for it to be eventually dropped unless
the feature is widely implemented and so important that browser
vendors "are actually ready to commit money and risk interop issues
over it".

Is figure widely implemented? Are browser vendors actually ready to
commit money and risk interop issues over it?

>> Authors are advised to only use the title attribute for "additional
>> information" and not as a full equivalent alternative.
> The spec doesn't suggest using it as a full equivalent alternative.

I think that this may be a key point of confusion in all of this that
we need to clear up.

WCAG allows alt text alternatives values that identify and describe
purpose [2]. HTML5 doesn't.

On the  CAPTCHA bug you said,  "HTML5's solution avoids conflating
alternatives and purpose descriptions, and as such is an improvement
over what could be done in HTML4."

How do we reconcile this?

Steve has illustrated the WCAG way in the "Techniques for providing
useful text alternatives" document [3] with the examples from the
Webcam [4] [5] and CAPTCHA [6] [7]  bug face offs.

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?

>> Removing title would make the HTML specification in line with WCAG, and
>> previous authoring practices. http://www.w3.org/TR/WCAG20-TECHS/H33.html
> WCAG's recommendations are based on HTML4; the whole point here is to move
> forward. WCAG will need updating for HTML5.

It might help if we think of it as a two way street. WCAG will need
updating for HTML5 and HTML5 will need updating for WCAG. We are here
to try sort out how best to do that. Working together maybe we can
figure it out.

Best Regards,
[1] http://lists.w3.org/Archives/Public/public-html/2008Jun/0140.html
[2] http://www.w3.org/TR/WCAG20/#text-equiv
[3] http://dev.w3.org/html5/alt-techniques/
[4] http://www.w3.org/Bugs/Public/show_bug.cgi?id=9215
[5] http://www.w3.org/Bugs/Public/show_bug.cgi?id=9174
[6] http://www.w3.org/Bugs/Public/show_bug.cgi?id=9216
[7] http://www.w3.org/Bugs/Public/show_bug.cgi?id=9169
[8] http://www.w3.org/WAI/PF/HTML/wiki/CAPTCHA_Survey

Laura L. Carlson
Received on Saturday, 24 April 2010 18:21:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:55:35 UTC