- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Mon, 25 Jan 2010 18:11:52 +0100
- To: public-html <public-html@w3.org>, public-html-a11y@w3.org
Shelley Powers, Sun, 24 Jan 2010 21:46:42 -0600: > On Sun, Jan 24, 2010 at 9:30 PM, Maciej Stachowiak <mjs@apple.com> wrote: >> On Jan 24, 2010, at 7:14 PM, Leif Halvard Silli wrote: >>> I personally also don't find <summary>/<dsummary> a good name as a >>> <details> caption. For example consider this example from the <table> >>> section in the draft [2] (where I replaced <dt> with summary : >>> >>> <details><summary>Help</summary> [.. explanation ..]</details> >>> >>> There is no summary here?! It is just a very short label/identifier. >>> (And as well: The draft only permits phrasing content inside the >>> <details> caption - whereas <summary> invites to a full explanation - I >>> certainly don't think of a summary as any shorter than a caption - on >>> the contrary!) >> >> Examples like this make me think <dlabel> (or similar) would be >> better than <dsummary> or <summary>. It is true that the spec calls >> this portion the "summary", but the way this type of UI element is >> typically used, the short version is a label for the longer >> contents, not a summary of them. This is pretty obvious with the >> screenshot examples in the spec: >> <http://dev.w3.org/html5/spec/Overview.html#the-details-element>. >> "General", "Name & Extension" and "Preview" are not summaries of >> anything, they are labels. >> > > I have no objection to <dlabel>. There are _two_ conditions that *could* make <summary> work: (1) It is used for both <figure> and <details> (2) One solves the problem of the proposed <summary> element for <table> simultaneously. For more explanation of (1), see "Some considerations" below. Here I want to explain (2): One could bind <summary> and <caption> together, into a accessibility solution somewhat like Laura hoped for, simply by twisting what the draft currently says (under the heading "The caption element") about what should happen when a table element is the only content in a figure element: ]] the caption element should be omitted in favor of the [figure caption] [[ But instead of advising to drop one of the two captions, the spec could advice to use <summary> and <caption> for different purposes: The figure's <summary> could be used for reading advice about the table - especially for the accessibility audience - somewhat like @summary. While <caption> could be used as a caption for the entire <figure>. (Or opposite - I don't know what would be most logical.) But of course, it is not the name <summary> that is most important here, but the presence of two captions that allow us to split their purpose. So if we want to solve this issue without mixing the table summary problem into this, then we should - at least for now - not choose <summary>. A name for a common caption element is not a problem: <about>, <cap>, <describe>, <info>, <subtext>. Some considerations: (1) If we cannot have just *one* caption element, then we should have just one *naming convention*. For example, both elements could contain the word 'caption' - <fcaption> and <dcaption>. I consider this the only option if we look for two elements. If we go for <fcaption> and <dlabel>, then authors will look in vain for any symmetry. The <fcaption> vs <summary> already breaks the principle of one-naming-convention very badly ... ! (2) If one is willing to accept *anything* - even unsystematic naming - as the name of this/these caption element(s), then that doesn't exactly bode well for the fate of <figure> and <details> themselves ... Neither of those elements can be said to be ready for prime time without a decent and fitting caption element - it is an essential part of either of them. In many ways, the caption looks as the most important part of both <figure> and <details>. -- leif halvard silli
Received on Monday, 25 January 2010 17:12:32 UTC