- 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