ChangeProposals/tableInfoProposal

From HTML WG Wiki
< ChangeProposals
Revision as of 03:04, 4 March 2010 by Jallan (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


Change proposal: A media independent way to provide table info in the caption element

A change to the caption element, to solve the summary deadlock.

Summary

Dilemma

  • How can we use caption to add related info about a table’s status, its caveats, how it should be read/used etc?
  • How can we also not break WCAG2 H39 and WCAG2 H73?

Proposal

  • Introduction of a tableinfo element as child of caption.
  • Purpose of tableinfo: to contain all caption content that cannot be said to take part in a caption’s table identification role. There can be more than one tableinfo per caption.
  • With regard to summary: if the non-identification content is formulated as a table summary (that is: it is meant for non-visual media consumption – in accordance with WCAG2 H73) then it may go into the summary attribute – even if this means that the caption element becomes empty/removed.


Rationale

The logic of this change proposal is rooted in WCAG2 and HTML4.

Non-visual summary vs media independent identification

This change proposal considers that H73 is impossible to discuss without relating it to H39.

  1. WCAG2 H39 defines caption as a table identification element.
  2. WCAG2 H73 defines summary as a brief table overview container especially for non-visual users

H73 is an important feature of H39

  1. H73 requires table summaries to go into a summary="*" not because authors eventually would refuse to place such content inside the caption elemetn (it doesn't discuss it from that angle), but because placing it inside caption would break the caption’s table identification role, as defined in H39.
  2. OTOH, H73 asks to not repeat info in summary that has already been added in caption – the underlying fact being: info inside caption is available to non-visual users and clearly linked to the table.
  3. Thus, there is no requirement in H73 to place table summaries inside summary should it happen to be relevant for all media. However, placing it in caption will – or could – make the caption break H39.

The open gap: media independent table summaries/table info

Hence we see that HTML4, on which H39 and H73 are built, do not provide any solution for linking directly related table info that is of media-independent nature, to the table in a way which makes it possible to programmatically determine that the info is directly related to the table. The only alternative is to place the description directly before the table – and things like that, as WCAG2 concretely discusses:

There may also be cases where it may be a judgment call about what information should appear in text and what would need to be directly associated, and it may be most appropriate to duplicate some information (for instance, in an HTML table, providing the summary both in the paragraph before the table and in the summary attribute of the table itself). However, wherever possible it is necessary for the information to be programmatically determined rather than providing a text description before encountering the table.

OK – there is one option: Just place into the caption element. However, then you break the purpose of the caption – especially as H39 defines it. And also: block level elements are not permitted inside caption in HTML4, so there really is no way to separate non-identification information from the table identification string.

HTML5’s current solution

  1. HTML5 introduces block elements in caption – and any kind of table explanation, including specific non-visual media related table summaries – directly in caption.
  2. This opening “permits” authors to break H39.
  3. The removal of summary from HTML5 can also be said to break H73. However, since a main purpose of H73 is to avoid that authors break H39, it is arguably more fundamental that H39 is broken.

Solutions on the table

There are 3 possible solutions:

  1. Either insist on the purity of caption’s purpose, as understood in HTML4 (which disallows block elements) and in WCAG H39.
  2. Or give up on having any formal requirements for caption’s content (HTML5 currently only disallow the table element).
  3. Or allow block elements and non-identification content inside caption under rules which allows authors, user agents and AT to separate the table identification string from the additional content: tableinfo.

Regarding option 2 – to give up – which is what I consider as HTML5’s current position: This also means that the use of summary becomes totally ad lib – I think that it is difficult to defend summary if we say that authors can freely place descriptive material inside caption. They can then just as well drop the table summary inside the caption and somehow hide it for visual user agents.

Option 1: the implications of a strict caption

As to option 1, then I am totally open to keeping the caption strict. We would then, for the purpose of users of non-visual media and AT, continute to use the summary attribute, while for other kinds of table info, we would be subject to use aria-labelledby for linking it to a table.

Option 2: pressure on the summary attribute

So why does option 2 put pressure on the summary attribute? Because the principal reasons for the summary attribute as a solution for providing table summaries for non-visual media, are two:

  1. To directly link the table summary to the table - what WCAG2 describes as programmatically determination. (That summary is a feature of table and not of caption emphasizes this.)
  2. To allow authors to not pollute the caption concept with non-identifying content - the keeping of WCAG2 H39.

When summary is defended, then the second point above is often disguised in the following form – consciously or not: to require that authors place a kind of info inside caption that they are unwilling to place there, is bad, and therefore we need the summary attribute. However, striclty speaking authors are not permitted to do so even if they would. And regardless, their reluctance to not add any such info directly in caption, is in accordance with H39!)

If one says that we may freely place any table info inside caption, then we have in practise removed both of the 2 reasons that there is for using the summary attribute for this purpose. We have removed the programmatic determination reason - because the same degree of determination can be achieved by placing the table summary inside the caption. (That the table summary this way becomes mixed together with the table caption is a problem, however, that is another problem.)

And for many practical purpose we have also removed the second reason: we are now permitted to place non-identifying content inside caption – and if it is a problem that the table summary then becomes visible in screen media, well then it is so simple to hide it via CSS.

It is a very weak defence for summary to say that we need it only because authors are unwilling to place the kind of content that summary requires inside the caption. It is also not true: Authors are currently not permitted to freely place such content into the caption – not according to HTML4, and certainly not according to H39!

So the only justification that has any strength, is that we defend H39 (and not only H73).

Option 3: the tableinfo proposal

However, there can be legitimate reasons for placing/linking non-identification stuff into caption – even for the screen media audicense. Thus this CP has chosen to pursue that option – I have not spotted very much opposition against this (from others than myself). Hence the proposal about tableinfo, as a way to place non-identification material into caption, and thereby offering programmatic determination of its relatedness to the table.

Excursus: Is it better to be an attribute?

Some say that an important side effect of summary is the fact that it is an attribute – and not an element. I shall not deny there could be positive side effects, but I personally find no preference for an attribute solution in WCAG2. The only advantage that the fact that it is an attribute has, is – as far as I can see – that it can be used even when caption is not used. I don't think side effects is a good defence for summary. The positive thing that WCAG2 describes is that summary is directly linked to the table – it is this that is important in the WCAG2 material that I have read, and not whether it is an attribute or element.

Details

summary has a limited and media dependent purpose

WCAG2 H73 defines a limited and media dependent purpose for the summary attribute:

to provide a brief overview of how data has been organized into a table or a brief explanation of how to navigate the table. The summary attribute of the table element makes this information available to people who use screen readers; the information is not displayed visually.

H73 holds that for someone who doesn't see the table he/she has to navigate, then even a simple but long table can benefit from such a brief note:

The summary may also be helpful for simple data tables that contain many columns or rows of data.

But summary also has a media independent role, namely to secure the purpose of caption

WCAG H39 defines the purpose of the caption element to be a table identificator:

The caption element identifies the table whereas the summary attribute gives an overview of the purpose or explains how to navigate the table.

In this we see a media independent purpose of summary: It allows authors to not clutter up the caption with content that doesn’t take part in a caption’s table identification role.

Status of caption in HTML5 – currently

Content status: HTML5 currently permits not only non-visual oriented table summaries inside the caption element (in the spirit that “this is good for all”), but allows any kind of table explanation/table reading guide. This blurs the role of the caption element, and makes it difficult to separate table identification string from the guiding material that caption might contain.

Syntax status: HTML5 also permits block level content inside caption – which blurs the identification role of caption, and which also complicates the parsing and perception of the caption. For example, this is currently a legal HTML5 caption:

<caption>
  <ol>
   <li>Table 1 
   <li>This is an
   <li>HTML5 caption.
  </ol>
</caption>

Examples of how tableinfo could be used

Example 1

A rework of the currently HTML5 legal example above.

<caption>
Table 1
<tableinfo>
  <ol>
   <li>This is an
   <li>HTML5 caption.
  </ol>
</tableinfo>
</caption>

Example 2: The second example from H73

Both a), b), c) and d) are valid, according to this change proposal.

a) The original example in H73
<table summary="Intersections are listed in row 1. 
Find the intersection closest to your starting point 
or destination, then read down that column to find 
out what time the bus leaves that intersection.  
Service begins at 4:00 AM and ends at midnight.">
  <caption>Route 7 Downtown (Weekdays)
</caption>
</table>
b) Added a tableinfo element with made-up information
<table summary="Intersections are listed in row 1. 
Find the intersection closest to your starting point 
or destination, then read down that column to find 
out what time the bus leaves that intersection.  
Service begins at 4:00 AM and ends at midnight.">
  <caption>Route 7 Downtown (Weekdays)
<TABLEINFO>Only valid from Week 36</TABLEINFO>
</caption>
</table>
c) Moved the content of summary into a tableinfo element
<table>
  <caption>Route 7 Downtown (Weekdays)
<TABLEINFO>Only valid from Week 36</TABLEINFO>
<TABLEINFO>Intersections are listed in row 1. 
Find the intersection closest to your starting point 
or destination, then read down that column to find 
out what time the bus leaves that intersection.  
Service begins at 4:00 AM and ends at midnight.</TABLEINFO>
</caption>
</table>
d) Removed the table caption string, but kept the tableinfo elements.
<table>
  <caption>
<TABLEINFO>Only valid from Week 36</TABLEINFO>
<TABLEINFO>Intersections are listed in row 1. 
Find the intersection closest to your starting point 
or destination, then read down that column to find 
out what time the bus leaves that intersection.  
Service begins at 4:00 AM and ends at midnight.</TABLEINFO>
</caption>
</table>

Should a caption with only tableinfo elements as content be valid?

Question: The table caption has to be inserted either directly into the caption and/or inside one or serveral inline elements. But should it be valid to have a caption with only one or several tableinfo elements inside? Answer: Yes, this would be equivalent to HTML4’s permission to have a table without any caption, but which still has a summary attribute.

Impact

Positive Effects

  • H39 is not not made invalid – though it must of course be updated about tableinfo
  • Authors gain a way to link content which does not serve a table identification purpose, but which still is directly related to the table, in a way that is possible to programmatically determine – regardless of media type.
  • AT and other user agents gains a way to discern between table identification string and other table related content.
  • tableinfo would be a semantic container –unlike a div or p, one could be certain that each table info element contained one set of information related to the table.

Negative Effects

  • Compared with HTML5’s current status: none. Block elements are already permitted inside caption there.

Conformance Classes Changes

  • Validators must accept the summary attribute.
  • Validators must that consider that caption can only contain inline elments and/or tableinfo element(s).