<details> as a child of <caption> or <figure><legend> [was: Re: Summary of Thursday's IRC conversation about @summary]

James Graham wrote:
> Ian Hickson wrote:
>> On Sat, 6 Jun 2009, Laura Carlson wrote:
>>> Jonas wrote:
>>>
>>>>> If a feature that we've developed is being improperly used
>>>>> after years of adoption, we have to change something.
>>>> Long Term Solution Possibilities
>>>> http://esw.w3.org/topic/HTML/SummaryForTABLE#head-847d2ebafa6828471a3d2777ad3676944007c35d 
>>>>
>>> What do you think of the  Long Term Solution Possibilities listed in
>>> the Wiki, in particular a new <summary> element or equivalent?
>>
>> I will look at the above closely when I get to this issue in my slog 
>> through feedback e-mails, but in the meantime I would really 
>> appreciate coherent e-mails for each proposal. When I glanced at the 
>> wiki just now I actually couldn't work out what many of the proposals 
>> were -- just proposing a new element name, for example, doesn't really 
>> mean anything -- what does the element do? What are the proposed 
>> conformance criteria for authors? For browser vendors? For 
>> accessibility tools? How does it solve the problems that have been 
>> raised? What new problems can it introduce? 
> 

Proposal:

Allow the <details> element as a child of <caption> and as a child of 
<figure><legend>. Encourage authors to use this construct in the case 
that their table is sufficiently complex to require a more verbose 
caption for some users. In other cases, authors would just use an 
ordinary <caption> or <figure> element.

Advantages:

The details element is intended to be visible to all users; avoiding 
hidden data helps ensure that the data is helpful and correct. It also 
allows people without AT but who need the information for some other 
reason e.g. difficulty understanding the structure of the table, have 
access to the information.

The backward compatibility story, especially when used in conjunction 
with <caption> ought to be good; the text of the caption will be 
associated with the table in existing UAs and AT will presumably read 
out the full, extended, form of the caption. This is not a perfect user 
experience but is likely better than a solution that involves data-loss 
in the transitional phase since it can be recommended immediately. (With 
<figure> extant UAs will not recognise the association between the 
figure caption and the table so will not read the caption. Hence this, 
perhaps superior, solution cannot be used immediately).

Support for the solution comes for "free" when implementing <details>. 
This halves the work for implementors compared with a solution that does 
not reuse markup already in the HTML 5 draft and makes it more likely 
that the solution will be fully implemented in UAs in the near future. 
It also means that authors are reusing things that they are likely to be 
familiar with from other parts of HTML so less specific accessibility 
related education is needed.

The solution is relatively easy to author as the markup is local (that 
is there is no requirement to match idrefs across different parts of the 
document). There is also a continuity of the solution between the case 
where a relatively terse caption is sufficient and one where a longer 
explanation is required. This makes it easy for authors when extending a 
table to a more complex form to add the additional information.

Disadvantages:

The use of the <legend> element has well known problems to do with 
parsing in extant browsers. This is a common problem for the <details> 
element and the <figure> element. It could be solved by choosing an 
element name that does not have such an undesirable legacy to use in 
these cases.

Forcing the data to be visible and adding a disclosure triangle may 
cause designers to avoid the solution if they feel it interfers too much 
with the look of their website. It is hard to see how any solution that 
makes the data visible can avoid this difficulty (assuming that XBL2 
does not become widely deployed in the near future).

The most obvious way of implementing support for <details> in legacy UAs 
is to use CSS display:none to hide the summary and javascript to display 
it in response to user action may not be AT friendly. This can likely be 
fixed with the use of ARIA (testcase needed).

The solution can be relatively verbose, requiring deep nesting of 
elements (e.g. <table><caption><details><legend>).

Testcases:
[1], [2]

[1] http://james.html5.org/table_descriptions/table_4.html
[2] http://james.html5.org/table_descriptions/table_5.html

Received on Monday, 8 June 2009 11:30:18 UTC