- From: James Graham <jgraham@opera.com>
- Date: Mon, 08 Jun 2009 13:30:17 +0200
- To: Ian Hickson <ian@hixie.ch>
- CC: Laura Carlson <laura.lee.carlson@gmail.com>, John Foliot <jfoliot@stanford.edu>, David Singer <singer@apple.com>, public-html@w3.org
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