Warning:
This wiki has been archived and is now read-only.
ChangeProposals/tableInfoProposal
A change to the caption
element, to solve the summary
deadlock.
Summary
Dilemma
- How can we use
caption
to add related info about atable
’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 ofcaption
. - Purpose of
tableinfo
: to contain all caption content that cannot be said to take part in acaption
’s table identification role. There can be more than onetableinfo
percaption
. - 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 thesummary
attribute – even if this means that thecaption
element becomes empty/removed.
Contents
- 1 Change proposal: A media independent way to provide table info in the caption element
- 1.1 Summary
- 1.2 Rationale
- 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
- 1.3.5 Should a caption with only tableinfo elements as content be valid?
- 1.4 Impact
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.
- WCAG2 H39 defines
caption
as a table identification element. - WCAG2 H73 defines
summary
as 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 thecaption
elemetn (it doesn't discuss it from that angle), but because placing it insidecaption
would break thecaption
’s table identification role, as defined in H39. - OTOH, H73 asks to not repeat info in
summary
that has already been added incaption
– the underlying fact being: info insidecaption
is available to non-visual users and clearly linked to the table. - 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 incaption
will – or could – make thecaption
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
- HTML5 introduces block elements in
caption
– and any kind of table explanation, including specific non-visual media related table summaries – directly incaption
. - This opening “permits” authors to break H39.
- 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:
- 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 thetable
element). - 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.
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:
- To directly link the table summary to the
table
- what WCAG2 describes as programmatically determination. (Thatsummary
is a feature oftable
and not ofcaption
emphasizes this.) - 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.
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.
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>
<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 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 adiv
orp
, 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/ortableinfo
element(s).