Log in   Register a New Account

Accessify Forum - Independent Accessibility Discussion Since 2003; Professional, Moderated, Web-based, Archived

New to the forum?

Only an email address is required.

Register Here

Already registered? Log In

Currently Online

No registered users are online.

Table Summaries

Reply with quote We are making changes to XStandard’s interface and an issue has come up regarding the use of table summaries. This thread will discuss two topics which are related to each other:

1. Currently, when building data tables in XStandard, a table summary is required, but it has been suggested by some of our users that a summary should be optional. One user writes:

Quote:
A summary that echos a “normal” header is just as unnecessary as one that echoes a caption. So from my point of view it would be even better to just make the summary optional, period. (Or at least allow the administrator to make it optional)


What this person is saying is that in many cases, the table summary is just a repeat of data that is found in the <caption>, <th> and <h1> to <h6> that precede the table.

This user further writes:

Quote:
After all there are different opinions among accessibility advocates on a number of WAI-principles – and I think it would be great if XStandard would take this diversity in interpretation into account and not force informed developers to do things one particular way.


We are hoping that rather than have a setting in the editor that is configurable so that summaries for tables are either required or optional, we can come to a single approach that is not configurable, but that works for everyone.

2. From a recent WSG post, Terrence Wood writes:

Quote:
The summary attribute is best used to describe the structure of the table, not to summarise it’s content. A longer summary is better according to actual screen reader user testing.

Example from complex financial table:
summary=”There are 8 columns. Column 1 names the appropriation and labels the row or rowgroup. Columns 2 through 5 report the numbers for 2004/5, where column 2 is Budgeted Annual, column 3 is Budgeted Other, column 4 is Estimated Actual Annual, column 5 is Estimated Actual Other. Columns 6 through 7 report the numbers for 2005/6 where column 6 is Vote Annual, column 7 is Vote Other. Column 8 contains narrative on the scope of the appropriation. Rows are grouped by appropriation type.”


In XStandard, we perceived the role of the summary differently and worked under the assumption that table summary is used to describe the function of a table (what it’s designed to contain), since the structure of the table can be programmatically determined by screen readers. Does anyone else have an opinion on this?

There are several implications for XStandard. First, if the table summary is for describing structure, then should the table summary be required? Second, if the table summary is for describing structure, then the amount of data that goes into the summary field is a lot more than if it contains the description of table contents. This would mean that the control to edit table summaries should be larger than it currently is – say 4 to 5 rows.

Vlad Alexander
XStandard Development Team
http://xstandard.com
Reply with quote Hi Vlad, here’s my 2p:

1. I like the current setup where a summary is required. Our content editors are not ‘informed developers’ or in any way au fait with the intricacies of HTML or the WCAG. Our style guide states that tables should only be used for tabular data, therefore they will always require to provide a summary.

I’d be unhappy to see it become an optional field – for me it should be configurable at the very least.

2. I’ve always advocated using a table summary to summarise the content (i.e. purpose) of the table, but not necessarily the structure. The summary should provide users with sufficient information to understand the most important points the table conveys – they can then decide whether to consume the entire table in detail, or move on.

Although it follows the WCAG HTML techniques guidance, I find Terrence’s example describing each column pretty unfriendly. I can’t believe many users would find it useful, and it’s tautological if the table is properly marked-up with header, body and footer, and uses scope or header ids correctly. So I agree with your original perception, but I’d be interested to hear others views.

Dan Champion, Champion IS, Mooch Marketing, Revish
Reply with quote
Quote:
We are hoping that rather than have a setting in the editor that is configurable so that summaries for tables are either required or optional, we can come to a single approach that is not configurable, but that works for everyone.


Vlad: I’m very glad you’re looking into this issue, but I’m a little confused as to why you are resistant to a configurable setting. Everyone has different needs, and the proper usage of the summary attribute is very much up for debate.

In the case of the publishing company I work for, we require a <caption> on every table we use in our articles. The summary attribute is therefore redundant. Yes, we could conceivably use it for other descriptive purposes, but with present levels of browser support we do not intend to. Therefore, we need an editor that requires the <caption> but does not require the summary.

Since XStandard does not provide either of these features — and more importantly, does not allow us any way to configure this — we must continue using a modified version of FCKeditor. I’d love to advocate switching to XStandard as I believe it’s an overall better piece of software, but the lack of dialog box customizability in XStandard is unfortunately a deal-breaker for us.

Ideally, I’d like to see you have an xml file or other configuration mechanism that defines which fields are visible and which are required in every dialog box. Put more power in the hands of your developer-users, not less.
Reply with quote
Quote:
the structure of the table can be programmatically determined by screen readers.


Yes, screen readers can read out the the structure of the table, e.g. 8 columns 24 rows, however that doesn’t help all that much in explaining what those 8 columns and 24 rows acutally represent, and how they relate to each other.

Quote:
The summary should provide users with sufficient information to understand the most important points the table conveys


The summary is used to help develop a mental model of how the table is structured. Summarising the content of the table, such as a preamble of the important points, is content that should be visible to all users.

Quote:
A summary that echos a “normal” header is just as unnecessary as one that echoes a caption


Agreed. But the author of the above gets it wrong about making the summary optional. The correct course of action is to write a summary that is not simply a repitition of the caption or heading preceding the table.

The example attributed to me above comes from a usuability report we commissioned to supplement our research.

Quote:

… This is a long summary, but was well received by our testers. It may
be useful to note the comment from an accountant on a WCAG discussion
started by Terrence Wood:
“In fact, the summary may need to be even more detailed and longer…
Without a summary for guidance, one can spend several minutes trying to
decipher the content in a complex table and get very very frustrated. But
a summary that explains the structure allows one to build a mental model
of the table and understand the content as one navigates it. At times one
might have to revisit the summary but that is OK.” (Sailesh Panchang,
Deque Systems, on w3c-wai-ig, 1 October 2005)


It is more useful to note that Sailesh is an ex-accountant, a screen reader user and now runs a usability consultancy.
Reply with quote
ibwhite wrote:
I’m very glad you’re looking into this issue, but I’m a little confused as to why you are resistant to a configurable setting. Everyone has different needs, and the proper usage of the summary attribute is very much up for debate.

We’re actually open to the idea of making the “summary” attribute optional for data tables but wanted to get confirmation from the community that this is the right thing to do. I think you rightfully pointed out that this is up for debate and as such should be optional.

ibwhite wrote:
Therefore, we need an editor that requires the <caption> but does not require the summary.

Interesting… I’ll recommend that we look at making a setting for this as well.

ibwhite wrote:
Ideally, I’d like to see you have an xml file or other configuration mechanism that defines which fields are visible and which are required in every dialog box. Put more power in the hands of your developer-users, not less.

We do understand what you are saying and for things like caption and summary attribute, this can be done. If you can provide examples of other attributes that should have configurable required status, I can recommend that we evaluate them on a case-by-case basis.

We cannot however provide a configuration setting for all attributes because some attributes in our dialog boxes are virtual and their behaviour is hard-wired and affects other attributes. For example, in the Image Properties dialog box, there is a field called “Decorative Image”. This is a virtual property and setting this value to “Yes” will set the alt=”” and remove title and longdesc.

As far as hiding fields in the dialog boxes, there is already a setting that will hide advanced features:

Code:
<param name="Options" value="512" />

Vlad Alexander
XStandard Development Team
http://xstandard.com
Reply with quote Terrence, thanks for additional info.

Vlad Alexander
XStandard Development Team
http://xstandard.com
Reply with quote After giving it some more thought, and given table summaries is a priority 3 checkpoint in WACG 1.0, I think the summary attribute should be optional for those times where a only a simple table is required e.g. single level headings, single tbody, and 2-3 columns.

I’m not entirely sure where table summaries sit within WACG 2.0, but it may pay to be mindful of what the future requirements may be while looking at this issue.
Reply with quote Currently, in the Layout Table Properties dialog box, the Summary field is optional. It was proposed that in the next release, the Summary field in the properties dialog box for layout tables should be hidden and all layout tables have a blank summary:

Code:
<table summary="" … >


Can anyone think of a scenario where a summary might be useful for a layout table?

Vlad Alexander
XStandard Development Team
http://xstandard.com
Reply with quote I can’t and I don’t think it would ever be useful to give a layout table a summary. Since it is solely for layout, it contains no data relationships, patterns, trends or anything else which could be summarised.

My understanding of the summary attribute was that it had a similar role to tables as alt has to images and <noscript> has to <script>? I thought it’s purpose was to provide simple text description of how the table should have appeared for users with devices which cannot render the table as intended. It might explain how any colspan or rowspan features are being used, whether there are totals and subtotals, anything which might be difficult to understand when accessing the table through a limited device.

W3C wrote:
summary = text [CS]
This attribute provides a summary of the table’s purpose and structure for user agents rendering to non-visual media such as speech and Braille.

(Source: HTML4 Tables
Basically, it seems that the summary attribute is for user agents which cannot support the full capabilities of table layouts. For simple layouts, the summary could be very basic–perhaps even ommitted? This purpose is very different to the <caption> element as that merely provides a title to the table, rather than a description of its purpose and structure.

While on the subject of table accessibility parameters, any developer who doesn’t already have the Table Inspector Extension for Firefox would do well to get it. It makes cell scopes, header relationships, axes, column header abbreviations and the summary attribute visible, allowing much easier checking of whether they are being used correctly and make sense.

That page also includes the W3C example tables, which use summaries like this:-
  1. This table charts the number of cups of coffee consumed by each senator, the type of coffee (decaf or regular), and whether taken with sugar.
  2. This table charts the number of cups of coffee consumed by each senator, the type of coffee (decaf or regular), and whether taken with sugar.
  3. History courses offered in the community of Bath arranged by course name, tutor, summary, code, and fee.
  4. This table summarizes travel expenses incurred during August trips to San Jose and Seattle.
Of these summaries, it seems that #1, #2 and #3 fulfill the spec of it briefly describing structure and purpose. There seems to be some uncertainty even at W3C about quite how it should be used, merely that it could be used.

Since many authors will naturally describe the table in <p> elements elsewhere on the page, the summary attribute seems to have very limited use. Does any one know of any device which actually uses it for anything? Lynx doesn’t display it even in the versions which struggle to draw tables.


Last edited by Ben Millard on 31 Dec 2005 04:13 pm; edited 1 time in total
Reply with quote JAWS will read it.

I think the summary attribute may be used such that a user with a screen reader (or simular) can get a quick overview of the table, so that he or she can make a decision to skip past the table and still have the relevant information from it. Going though a table with a screen reader can be a pain, so a brief summary could be useful (just like sighted people just skim a table, but don’t actually read every cell).

Simon Pieters
Reply with quote Reading through all this, I’m inclined to agree with Terrence – use the summary attribute to describe the structure of the table, and use the caption and other preceding text to describe its content and purpose.

The latter is visible to all users, allowing them to decide immediately if they’re interested in the table, then the summary is for screen reader users, to help them read and interpret the actual data.

Up until now I’ve been using summary for content description, and often tautologically with the caption, but I think this make a lot more sense.
Reply with quote
Quote:
We do understand what you are saying and for things like caption and summary attribute, this can be done. If you can provide examples of other attributes that should have configurable required status, I can recommend that we evaluate them on a case-by-case basis.


Vlad: Offhand, the big one I recall is that we also require reporters to provide “title” attributes in all anchor tag links. Of course title is not required in valid XHTML, but is a requirement we have imposed that XStandard can’t enforce.

Quote:
As far as hiding fields in the dialog boxes, there is already a setting that will hide advanced features:


This feature is a great help, but unfortunately it is somewhat “one size fits all”. You’ve basically picked and chosen which attributes aren’t “advanced”, rather than leaving that decision up to the CMS developer. For example, our users have no need for the “id” tag, but there is no way I can hide it from them in the link dialog.

By the way, our CMS is up for review in the next few months. If, as I expect, most of the griping is about issues related to our current editor, I will likely make another stab at getting the company to evaluate XStandard. But customizability has been one of the big stumbling blocks for the other developers, so we’ll see how it goes.

Display posts from previous:   

All times are GMT

  • Reply to topic
  • Post new topic