A change to the
caption element, to solve the
- How can we use
captionto 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?
- Introduction of a
tableinfoelement as child of
- 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
- 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
summaryattribute – even if this means that the
captionelement becomes empty/removed.
- 1 Change proposal: A media independent way to provide table info in the caption element
- 1.1 Summary
- 1.2 Rationale
- 1.2.1 Non-visual summary vs media independent identification
- 1.2.2 The open gap: media independent table summaries/table info
- 1.2.3 HTML5’s current solution
- 1.2.4 Solutions on the table
- 1.2.5 Excursus: Is it better to be an attribute?
- 1.3 Details
- 1.3.1 summary has a limited and media dependent purpose
- 1.3.2 But summary also has a media independent role, namely to secure the purpose of caption
- 1.3.3 Status of caption in HTML5 – currently
- 1.3.4 Examples of how tableinfo could be used
- 184.108.40.206 Example 1
- 220.127.116.11 Example 2: The second example from H73
- 1.3.5 Should a caption with only tableinfo elements as content be valid?
- 1.4 Impact
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.
- WCAG2 H39 defines
captionas a table identification element.
- WCAG2 H73 defines
summaryas a brief table overview container especially for non-visual users
H73 is an important feature of H39
- H73 requires table summaries to go into a
summary="*"not because authors eventually would refuse to place such content inside the
captionelemetn (it doesn't discuss it from that angle), but because placing it inside
captionwould break the
caption’s table identification role, as defined in H39.
- OTOH, H73 asks to not repeat info in
summarythat has already been added in
caption– the underlying fact being: info inside
captionis available to non-visual users and clearly linked to the table.
- Thus, there is no requirement in H73 to place table summaries inside
summaryshould it happen to be relevant for all media. However, placing it in
captionwill – or could – make the
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
- HTML5 introduces block elements in
caption– and any kind of table explanation, including specific non-visual media related table summaries – directly in
- This opening “permits” authors to break H39.
- The removal of
summaryfrom 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:
- Either insist on the purity of
caption’s purpose, as understood in HTML4 (which disallows block elements) and in WCAG H39.
- Or give up on having any formal requirements for
caption’s content (HTML5 currently only disallow the
- Or allow block elements and non-identification content inside
captionunder rules which allows authors, user agents and AT to separate the table identification string from the additional content:
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.
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
Option 2: pressure on the
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:
- To directly link the table summary to the
table- what WCAG2 describes as programmatically determination. (That
summaryis a feature of
tableand not of
- To allow authors to not pollute the caption concept with non-identifying content - the keeping of WCAG2 H39.
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
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.
summary has a limited and media dependent purpose
WCAG2 H73 defines a limited and media dependent purpose for the
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.
WCAG H39 defines the purpose of the
caption element to be a
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.
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> <ol> <li>Table 1 <li>This is an <li>HTML5 caption. </ol> </caption>
Examples of how
tableinfo could be used
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
<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>
<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>
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
- H39 is not not made invalid – though it must of course be updated about
- 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.
tableinfowould be a semantic container –unlike a
p, one could be certain that each table info element contained one set of information related to the table.
- Compared with HTML5’s current status: none. Block elements are already permitted inside
Conformance Classes Changes
- Validators must accept the
- Validators must that consider that
captioncan only contain inline elments and/or