- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Wed, 3 Mar 2010 00:24:04 +0100
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, "public-html-a11y@w3.org" <public-html-a11y@w3.org>
Maciej Stachowiak, Tue, 02 Mar 2010 15:10:13 -0800:
>>>
>>> I didn't test, but it seems plausible this is a bug we fixed since
>>> 4.0.4. We've made a lot of improvements to our accessibility code
>>> lately.
>>
>> If so, then what about - ahem - @summary? ;-)
>
> You mean read table summaries by default? (Or invokable by a user
> key?)
Yes, basically implement support for @summary.
> We're dealing with things based on our sense of the priority
> and how much content it affects. Right now I think we have much more
> basic issues in tables that would be higher value to address.
OK.
>> And also, if you would like to support the workaround to use generated
>> content like Charles supported, then you need to look at what happens
>> if you add a border to that table. E.g. try this:
>>
>> table:before { content: attr(summary);position:absolute;left:300px }
>> table {border:1px solid}
>>
>> And also what happens when there already is a real <caption> in the
>> table. Both those issues interferes with this - effectively - generated
>> "summary caption".
>
> If there were both a visible caption and generated content from a
> summary attribute, we would read both. Can't see any reason it would
> be otherwise.
Yes, that works - it is read! And if I could somehow make this happen
only when VoiceOver was active, then fine.
However, there are visual side effects. Which you will see if you try
the above.
--
leif halvard silli
Received on Tuesday, 2 March 2010 23:24:42 UTC