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

<caption> and <figcaption>

From: Sean Hayes <Sean.Hayes@microsoft.com>
Date: Sat, 24 Apr 2010 09:00:35 +0000
To: Steven Faulkner <faulkner.steve@gmail.com>, Ian Hickson <ian@hixie.ch>
CC: Laura Carlson <laura.lee.carlson@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>
Message-ID: <8DEFC0D8B72E054E97DC307774FE4B911A4F9544@DB3EX14MBXC303.europe.corp.microsoft.com>
Sorry to divert this thread, but I don't see any technical difference between <figcaption> and <caption>. Why don't we simply generalise the latter so it can appear anywhere.  Thus providing title or legend behaviour for any container element. This would avoid having to have funky rules for when <figcaption> and <caption> should be used.

The @title would then be redundant, but it could be retained it in order to point a <caption> element in the case where the caption is not a child element of the element being  titled, and thus provide the @aria-labelledby semantic. 

Having a common titling element  that can contain markup would be better for both accessibility and i18n.

If the tooltip behaviour is thought to be valuable, introduce a @tooltip attribute, and specify there that it needs to be keyboard accessible.


Sean Hayes
Accessibility Business Unit
Microsoft TwC.

-----Original Message-----
From: public-html-a11y-request@w3.org [mailto:public-html-a11y-request@w3.org] On Behalf Of Steven Faulkner
Sent: Saturday, April 24, 2010 8:01 AM
To: Ian Hickson
Cc: Laura Carlson; Maciej Stachowiak; Dave Singer; Matt Morgan-May; HTML Accessibility Task Force
Subject: Re: Discussion: Text Alternative Survey

> The whole point of using it in this case is that the AT would use it 
> as a source of caption information, so that isn't accurate in HTML5 UAs and ATs.

This is not about AT, its about anybody that cannot use a pointing device. no browser supports keyboard access to  title attribute content, this has been a known issue for many years, but has yet to be fixed, the html5 spec does nothing to  bring us closer to a fix.

What you want to do is encourage authors to hide content in the title attribute by relaxing the conformance rules for alt. This does a disservice to any users that cannot access that content.

> The spec proposes to change this. We can't avoid speccing things that 
> aren't implemented yet; we'd never add anything new!

there is no disagreement (as far as I know) with changing the implementation requirements in HTML5, just to predicating the relaxing of alt conformance on a feature that although its been around for at least 10 years has never been implemented accessibly.


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

there is a major difference between title attribute  and <figcaption>.
<figcaption> content is available_by_default to all users it is not hidden. It can also be explicitly associated with an image using ARIA, which some AT support.

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

wcag techniques and html5 conformance requirements for alt should be updated WHEN we have implemented support for  accessible title attribute content, not when an idea about how things should be is written in a spec. otherwise authors are being encouraged to use a technique that makes content less accessible. Surely a situation that nobody who cares about accessibility wants.

regards
stevef



On 24 April 2010 05:26, Ian Hickson <ian@hixie.ch> wrote:
> On Fri, 23 Apr 2010, Laura Carlson wrote:
>>
>> The title attribute is not up to the job of providing a text 
>> alternative. It's content is not displayed to the user unless they 
>> can use a mouse and beforehand know that the content is there.
>
> The whole point of using it in this case is that the AT would use it 
> as a source of caption information, so that isn't accurate in HTML5 UAs and ATs.
>
>
>> The content of the image title attribute is also often not detected 
>> by AT by default unless the user makes an explicit choice in their 
>> preferences to announce the attribute contents.
>
> The spec proposes to change this. We can't avoid speccing things that 
> aren't implemented yet; we'd never add anything new!
>
>
>> The set of options listed in the suggested text section of this 
>> proposal uses semantic HTML that is up to the job.
>
> As I understand it the only proposed non-ARIA solution is 
> <figcaption>, which is supported even less by ATs than title="".
>
>
>> 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.
>
>
>> 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.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    
> fL http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>



--
with regards

Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium

www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
http://www.paciellogroup.com/resources/wat-ie-about.html
Received on Saturday, 24 April 2010 09:01:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:42:07 GMT