Re: summarization information delivery options: attribute or element

Shelley Powers, Tue, 02 Mar 2010 10:56:54 -0600:
> Leif Halvard Silli wrote:
>> Shelley Powers, Tue, 02 Mar 2010 07:59:42 -0600:
>>   
>>> Leif Halvard Silli wrote:
>>>     
>>>>> Though technically not a _new_ element [1], using two captions on 
>>>>> a table is not, I believe, an enhancement that will degrade 
>>>>> gracefully with older user agents.
>>>>> 
>>>>> Firefox doesn't print out the second caption, as Leif states in 
>>>>> his change proposal, but that's not a behavior we can count on.
>>>>>         
>>>> Right. We need support in more than one UA.
>>>>         
>>> Unfortunately, the second caption is not backwards compatible. It 
>>> breaks with existing and older browsers.
>> 
>> I think you are rushing to conclusions. On this page, I have both 
>> hidden and shown second captions, and it works for Webkit, IE, Opera 
>> and Firefox:
>> 
>> http://målform.no/html5/caption+role

>> 
>> You could test it in NVDA if you want, If NVDA doesn't read even the 
>> *visible* second <caption>s, then we for sure have a problem. As 
>> long as NVDA reads the visible captions, then trick to serve a 
>> hidden caption to NVDA is some variant of:  a) make second caption 
>> visible via CSS, and then use
>>  b) caption+caption{position:absolute;left:-9999cm}    (or something 
>> similar) to visually hide it. (I will soon publish a demo of this.)
>> 
> Let me ask you something: do you think that a web designer or author 
> will do this? Let's forget UAs and parsing, and what NVDA will speak 
> or not: do you think a web designer or developer will do this? 

The question back is: "the vendors" are defining a HTML5 parser. Of 
course we should expect them to treat a second caption in a way that 
makes  it simple for authors to use. Nothing is simple to use, not 
<video> and no nothing (such as <details>) if UAs do not enable support 
for it. Should we not take the future into account? If we shouldn't 
then we should remove /all/ new elements from HTML5. The CSS that I 
talk about is of course related to how to get existing user agents to 
show acceptable behaviour.

> What a lot of this comes down to is one sentence you wrote:
> 
> "We already have the summary attribute, which has as drawback that it 
> is an attribute, and attributes are, by definition, not as accessible 
> whether for those in need of AT software nor for the average Web 
> author. "
> 
> In my opinion, the summary attribute is a lot more palatable than a 
> second caption with some not very attractive CSS. I can't speak for 
> all web authors and designers and developers, but I wouldn't use it. 
> Sorry, I just wouldn't.

Well, my proposal would at least not hinder you from legally using 
@summary. As for the ugliness of CSS, there are many things about CSS 
with regard to screen readers which are extremely ugly. For instance 
the thing that you hide an element by doing 

 element{position:absolute;left:-9999kilometer}
 
But that is reality. You can't escape it no matter what we do with 
<caption> and/or @summary. Of course, what is really needed is 

 @media screenreader {}

http://www.w3.org/TR/2004/WD-css3-reader-20040224/


(And I don't know why there hasn't been some movement on that front. 
But if even that solution would be a futuristic thing.)

> Now, you mention @summary is not accessible for AT software. How so? 
> As far as I know of, summary does work with AT software. In fact, as 
> far as I know of, that's never been an issue with @summary.

I noted in the vote about <details>, that someone said the exact same 
thing - I think it was Steve who told you so on Twitter .

I have told that Apple's VoiceOver for Mac OS X does not support 
@summary. At least not up until Mac OS X 10.5. I have not tested Mac OS 
X 10.6, so I cannot tell. 

If @summary isn't supported on Mac OS X 10.6 (does anyone know?), then 
this pretty much means that not a single AT tool for Mac OS X supports 
@summary. 

-- 
leif halvard silli

Received on Tuesday, 2 March 2010 17:58:48 UTC