- From: Maciej Stachowiak <mjs@apple.com>
- Date: Tue, 02 Mar 2010 15:10:13 -0800
- To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Cc: "public-html-a11y@w3.org" <public-html-a11y@w3.org>
On Mar 2, 2010, at 2:10 PM, Leif Halvard Silli wrote: > Maciej Stachowiak, Tue, 02 Mar 2010 13:55:03 -0800: >> >> On Mar 2, 2010, at 1:52 PM, Leif Halvard Silli wrote: >> >>> Maciej Stachowiak, Tue, 02 Mar 2010 13:37:45 -0800: >>>> I cannot reproduce the bug. Safari+VoiceOver reads the generated >>>> content in this case, as far as I can tell. >>> >>> In Safari version 4.0.4 (5531.21.10) on PPC for OS X 10.5, no it >>> doesn't. >>> >>> In Webkit latest nightly, same OS and platform, yes it does. >> >> 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?) 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. > > 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. Regards, Maciej
Received on Tuesday, 2 March 2010 23:10:46 UTC