- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Sat, 19 Dec 2009 03:04:30 +0100
- To: Ian Hickson <ian@hixie.ch>
- Cc: Cynthia Shelly <cyns@microsoft.com>, HTML Accessibility Task Force <public-html-a11y@w3.org>
Ian Hickson, Sat, 19 Dec 2009 01:29:19 +0000 (UTC): > On Fri, 18 Dec 2009, Cynthia Shelly wrote: >> * In threads after the call, the suggestion was made to Would adding a >> <summary> inside <caption>, while still allowing the @summary for >> back-compat. In many ways, this is the same as details, and could be >> subject to the same UI toggle. However, I think it would be easier to >> explain to people that summary changed from an attribute to an element, >> and would be less disruptive to regulations or existing training. > > What would <summary> do? 1) It would make the table summary programmatically detectable for AT. According to WCAG 2.0 it is important that the table summary is programmatically detectable. 2) A <caption> that contains non-caption content is unheard of in HTML 4 and in XHTML. <summary> would justify placing non-caption content inside <caption> (since <summary> carries a "not the caption" stamp). > If it is hidden by default, like summary="", then The thread (I and Martin) concluded that it should be _visible_ by default. > it would have the same problems. If it is shown by default, it seems > unnecessary (<p> would already handle this job fine). A <p> would not handle the job that <summary> is meant to handle: <p> is not a programmatically detectable summary container for AT software - such as WCAG 2.0 says. A <p> doesn't carry a "not the caption" stamp. > If it is a widget that can be hidden or shown by the user inline, > then it seems identical to <details>, and thus redundant. It is not a widget. It is just a container that separates the table summary from the caption content. -- leif halvard silli
Received on Saturday, 19 December 2009 02:08:15 UTC