W3C WBS Home

Results of Questionnaire [Tutorials] Tables Tutorial Review - May 2014

The results of this questionnaire are available to anybody. In addition, answers are sent to the following email address: ee@w3.org

This questionnaire was open from 2014-05-01 to 2014-06-02.

12 answers have been received.

Jump to results for question:

  1. Support for publishing the Tables Tutorial
  2. Tables concepts
  3. Simple tables
  4. Irregular Tables
  5. Multi-level Tables
  6. Caption & Summary
  7. Tips and Frequently asked questions

1. Support for publishing the Tables Tutorial

Note that as a "WAI Resource" (as opposed to a W3C TR/Recommendation/Note), we can make changes quickly if needed later -- with only Working Group approval, we do not need a public review period for this.

Summary

ChoiceAll responders
Results
I support publishing these Tables Tutorial pages as they are 2
I support publishing these Tables Tutorial pages; however, I suggest the changes in the comments sections below (for editors' discretion) 8
I support publishing these Tables Tutorial pages only with the changes in the comments sections below 1
I do not support publishing these Tables Tutorial pages, because of the comments in the comments sections below
I abstain (not vote) 1

Details

Responder Support for publishing the Tables Tutorial
Wayne Dick I support publishing these Tables Tutorial pages as they are
Anna Belle Leiserson I support publishing these Tables Tutorial pages; however, I suggest the changes in the comments sections below (for editors' discretion)
Vicki Menezes Miller I support publishing these Tables Tutorial pages as they are
Shawn Henry I support publishing these Tables Tutorial pages; however, I suggest the changes in the comments sections below (for editors' discretion)
Helle Bjarnø I abstain (not vote)
Howard Kramer I support publishing these Tables Tutorial pages; however, I suggest the changes in the comments sections below (for editors' discretion)
Sylvie Duchateau I support publishing these Tables Tutorial pages; however, I suggest the changes in the comments sections below (for editors' discretion)
Paul Schantz I support publishing these Tables Tutorial pages; however, I suggest the changes in the comments sections below (for editors' discretion)
Shadi Abou-Zahra I support publishing these Tables Tutorial pages only with the changes in the comments sections below
Andrew Arch I support publishing these Tables Tutorial pages; however, I suggest the changes in the comments sections below (for editors' discretion)
Sharron Rush I support publishing these Tables Tutorial pages; however, I suggest the changes in the comments sections below (for editors' discretion)
Bim Egan I support publishing these Tables Tutorial pages; however, I suggest the changes in the comments sections below (for editors' discretion)

2. Tables concepts

Tables concepts (Current work in progress on Github)
For each comment, remember to indicate if it is a suggestion for editor's discretion or if you feel it must be addressed before this version is published.

Details

Responder Tables concepts
Wayne Dick Change "project planning" to "team leadership", "accessibility leadership" or "accessibility team leadership"
Anna Belle Leiserson I love the small graphics used in the initial breakdown. However, the explanations of some of the pages go into actually how to do it, which IMO is unnecessary. Tersify, perhaps, as follows:

(1) Complex Irregular tables: For tables where identifying header cells programmatically is not easy.

(2) Complex Multi-level tables: For tables so complex that a data cell must reference several levels of header cells.
[Alternatively, using the language of the page itself:
Complex Multi-level tables: For tables that have a structure that is too complex to support strict horizontal or vertical association between header and data cells.]
Vicki Menezes Miller Great job!
Shawn Henry priority: medium suggestion

Current wording:
* Simple tables: Identify the topic of a row or column and denote those header cells with <th> elements in the markup.
* Complex Irregular tables: For tables where identifying header cells programmatically is not easy, they can be defined using the scope attribute.
* Complex Multi-level tables: If the table structure is so complex that a data cell needs to reference several levels of header cells, each header cell is assigned an id and each data cell a headers attribute that lists all relevant header cell id values.

Suggestion:
Use consistent, simple sentence structure and mood. I suggest imperative. e.g., along the lines of:
* Simple tables: For simple tables, markup the header cells with <th> elements.
* Complex Irregular tables: For tables where identifying header cells programmatically is not easy, markup the headers with the scope attribute.
* Complex Multi-level tables: For multi-level tables where a data cell is related to more than one level of header cells, markup each header cell with an id and markup each data cell with a headers attribute that lists all relevant header cell id values.

---

priority: medium suggestion
location: first paragraph
I think it needs to start more basic. I think we should consider the non-coder authoring tool reader more. For these readers, it would still be good if they understood the basics, even if they'll use the tool to develop the code.

---

priority: mild suggestion
current wording: "Captions & Summary: Most tables benefit from the use of a caption to describe the overall topic of a table, and summaries to..."
Suggestion: Use either singular (caption and summary) or plural (captions and summaries) consistently here and throughout the sub-page.
Helle Bjarnø I think the work is great, but I don't have time to make serious comments. So I Abstain. I looked at Shawns comments and think they look very relevant.
Cheers Helle
Howard Kramer priority: editors discretion - medium
location: menu navigation
current wording: right now the spacing between 2 lines of wrapped menu items is the same as between 2 separate menu item.
suggested revision: decreasing the line spacing between two lines of the same menu item so that there is better visually indication of each separate menu item.
Sylvie Duchateau
Paul Schantz Medium suggestion for editor's discretion:

After re-reading, I'm inclined to make the following structural edits to make the tables tutorial more consistent with the images tutorial:

Remove the following two paragraphs:

1. "Some document formats other than HTML..."
2. "Many web authoring tools and content management systems..."

Move the "Notes:..." section beneath the "Why is this important?" section.

What makes me think we should do this?

The paragraph starting with "Some document formats other than HTML..." reads awkwardly to me, and I'm not sure how to re-word it. I think it feels awkward because it tries to convey a large amount of "aside information" in just three sentences. Sentences one and two are opposite sides of the same coin - some document formats provide mechanisms to markup tables, while others do not. PDF is also singled out as a format that may provide a mechanism to markup table structures; do we want to specifically call out a format in this way? Sentence three feels like it's just "hanging out there."

The web authoring tools and CMS paragraph, which I agreed was an important element to add with respect to ATAG, feels like a footnote we're shoehorning in.

The larger point about these two paragraphs is that document formats and authoring tools each have their own - often inconsistent - ways of handling table markup.


Again, editor's discretion.
Shadi Abou-Zahra priority: medium
location: first paragraph
current wording: "Accessible tables need special HTML markup that indicates the difference between header cells and data cells, and also ties the two together"
suggested revision: "Accessible tables need special HTML markup that indicates the difference between header cells and data cells, and that indicates the relationship between them" or "that associates them with one another"
rationale: "ties the two together" is too casual and does not seem technically very accurate (depending on how you interpret "tie")

priority: strong
location: second paragraph
current wording: "or more complex tables"
suggested revision: "For more complex tables"
rationale: typo

priority: medium
location: second paragraph
current wording:
suggested revision: add "Using caption helps identify tables, and summary is often useful to describe the structure of the data."
rationale: we should also mention caption and summary in this listing

priority: medium
location: list, first bullet
current wording: "Simple tables: For simple tables, mark up ..."
suggested revision: "Simple tables (typically have one header row and/or column): Mark up ..."
rationale: (1) remove redundant "for simple tables" after "simple tables" (2) put the alt-text for everyone to see

priority: medium
location: list, second bullet
current wording: "Irregular tables: For tables where identifying header cells programmatically is ambiguous, markup header cells with the scope attribute."
suggested revision: "Irregular tables (with unusual headers): Markup header cells with the scope attribute to declare the direction and scope of the headers."
rationale: (1) reduce redundancy (2) simpler and clearer language (3) put the alt-text for everyone to see (alt-text had grammar mistake)

priority: medium
location: list, third bullet
current wording: "Multi-level tables: For multi-level tables where a data cell is related to more than one header cell, markup each header cell with an id and each data cell with a headers attribute that lists all relevant header cell id values."
suggested revision: "Multi-level tables (data cell is related to more than one header): Markup each header cell with an id and each data cell with a headers attribute that lists the id values of all relevant headers[, to explicitly associate header and data cells]."
rationale: (1) reduce redundancy (2) simpler and clearer language (3) put the alt-text for everyone to see (alt-text had information that is not apparent from the icon)

priority: medium
location: list, fourth bullet
current wording: "Caption & Summary: Most tables benefit from a header-like caption to identify the overall topic of a table, and a summary to provide orientation or navigation hints in complex tables."
suggested revision: "Caption & Summary: The caption element is used to identify the overall topic of a table, and is useful in most situations. The summary attribute can be used to provide orientation or navigation hints in complex tables."
rationale: (1) split between caption and summary to avoid confusion about their respective applicability (2) formulate in a way so that you can highlight "caption" and "summary"

priority: medium
location: list, fourth bullet
current wording:
suggested revision: would be great to add an icon here too -- maybe just the multi-level table icon with a dark-gray bar on top to mimic the caption text above the table?
rationale: this bullet is easily lost because of the missing icon (great that you indent it in alignment with the other bullets though!)

priority: mild
location: paragraph after first note
current wording: "Most word processing applications ..."
suggested revision: check "most" vs "many" vs "some" etc
rationale: Wayne disagreed during the previous call

priority: strong
location: first paragraph after "Why is this important?"
current wording: "and to define the relationship between, them"
suggested revision: "and to define the relationship between them,"
rationale: grammar

priority: editors' discretion
location: first paragraph after "Why is this important?"
current wording: "Visual clues only are not sufficient"
suggested revision: "Visual cues alone are not sufficient"
rationale: think "cues" better than "clues", and "alone" better than "only" in this context

priority: mild
location: first bullet after "Why is this important?"
current wording: "so the user never loses context"
suggested revision: "so that users [or readers] don't lose context"
rationale: "never" is a bit too absolute ... never say never :)

priority: mild
location: second bullet after "Why is this important?"
current wording: "prominently styled for easy recognition"
suggested revision: "prominently styled for easier recognition"
rationale: again, adding a qualifier to avoid absolution :)

priority: strong
location: "How to make tables accessible"
current wording: entire section
suggested revision: remove entirely
rationale: nothing to say that isn't already said elsewhere (on this page or the tutorials entry page)
Andrew Arch Priority: medium for editors discretion
Location: somewhere
suggestion: consider adding a note about breaking tables down into their simpler components whenever possible to aid understanding (see my note for multilevel tables). I know it's covered as the first tip, but it is VERY important and is so often overlooked as a solution :(

Overall - very good
Sharron Rush with Git comment suggested (editor's discretion)
Bim Egan Medium priority
Location: all pages
Content: the "Jump to navigation" link
Issue: This remains out of viewport on focus.
Suggestion: It should become visible on focus.
Rationale: Skip or jump links are more useful to sighted keyboard only users than screen reader users. The latter user group is more likely to use heading navigation, which may not be available to keyboard only users.

3. Simple tables

Simple tables (Current work in progress on Github)
For each comment, remember to indicate if it is a suggestion for editor's discretion or if you feel it must be addressed before this version is published.

Details

Responder Simple tables
Wayne Dick Excellent
Anna Belle Leiserson
Vicki Menezes Miller Really clear and easy to understand.
Shawn Henry Priority: important to be addressed before publication
First sentence: "A simple table has one header row and/or header column."
Need to edit 'cause table with one column header is in irregular. so I think: "A simple table has one header row, or a header row and header column."

Priority: medium
Second paragraph: "Additionally, <caption> elements may be used to identify a table in the document. That’s a way for meeting WCAG 2.0 requirements in _specific situations_."
The text and link are not clear and seem to say more than is needed here. I think you can simplify it to: "Additionally, you can use the _<caption> element_ to identify the table."
Helle Bjarnø
Howard Kramer looks good
Sylvie Duchateau
Paul Schantz Why is the example cited in the following sentence linked to the Irregular Tables tutorial?

"If the table has only a header column, see the first example of the Irregular Tables tutorial."

Other than, page looks great.
Shadi Abou-Zahra priority: mild
location: second paragraph
current wording: "Use header cell elements (th) to markup the header cells so that they are distinguishable from data cells and associated with the correct data cells"
suggested revision: "Use header cell elements (th) to markup the header cells so that they are distinguishable from data cells and to associate them the corresponding data cells"
rationale: think it is better grammar and easier to read.

priority: medium
location: second paragraph
current wording: "For example, in the second table below “Closed” is meaningless on its own, but makes sense when it’s associated with time (the row header) and day (the column header)"
suggested revision: "For example, in “Example 2” below, “Closed” is ambiguous on its own but makes sense when it is associated with the corresponding time and day (indicated in the row and column headers)"
rationale: (1) I think “Example 2” is easier to recognize and skim than "second table"; (2) “Closed” is not actually meaningless but ambiguous; (3) tried to improve the reading flow by putting the brackets at the end of the sentence rather than in the middle (you could also remove the brackets by using the words "that are ...".

priority: mild
location: second paragraph
current wording: reference to Example 2
suggested revision: wished it was a reference to Example 1 (I do understand that Example 2 is more convincing but it is still mind boggling)
rationale: (1) less jumping and scrolling around the page; (2) in some cases both sections might be in the same view so that no jumping and scrolling would be needed; (3) begs the question why the headers are marked up in the first example, if it is not necessary

priority: strong
location: third paragraph
current wording: "Additionally, you can use the caption element to identify the table, which in some cases might be a WCAG 2.0 requirement"
suggested revision: "The caption element can be used to identify the table, which is particularly useful for screen-reader users browsing the web page in “tables mode”. It is good practice to provide captions for tables. Even caption it is not required by WCAG 2.0, in some cases it might be necessary. See more in Caption and Summary."
rationale: (1) tried to provide specific reasons for providing captions; (2) tried to further differentiate between what is required and what not; (3) avoided "in some cases caption is required by WCAG 2.0" in favor of "in some cases it might be _necessary_" in case other ways of providing captions exist or emerge in the future (WAI-ARIA, HTMLx, ...) -- WCAG doesn't actually require the use of any particular elements (sometimes there is only one element to meet a requirement, though); and (4) linked to "Caption and Summary" page for more discussion.

priority: editor's discretion
location: fourth paragraph
current wording: "If the table has only a header column, see the first example of the Irregular Tables tutorial"
suggested revision: "If the table has only a header column, see the Irregular Tables: Example 1"
rationale: (1) the whole set of pages is the tutorial -- I don't see "irregular tables" as a separate tutorial; (2) I think it is easier to read and skim "Irregular Tables: Example 1" than the current wording.

priority: mild
location: fourth paragraph
current wording: entire sentence
suggested revision: move as last sentence of the first paragraph
rationale: makes more sense there.

priority: editor's discretion
location: example 1
current wording: "This table of concerts only needs the cells in the top row marked up as th cells. This is partly because it is such a small table and partly because the data itself is distinctly different in each column."
suggested revision: "The headers of this table of concerts are in the first row. The cells in this top row need to be marked up with th to programmatically declare them as header cells. Since this is such a small and simple table, most screen readers will automatically associate the columns with the corresponding header cells."
rationale: tried to be more explanatory of the rationale and mechanics behind the markup.

priority: editor's discretion
location: example 2
current wording: use of top-right cell to provide a caption
suggested revision: use caption (in the full-code) instead -- move this example to "Caption and Summary" page where it can be better explained
rationale: seems premature and confusing to use at this stage, especially without explanation -- better to explain in more detail together with the other captioning approaches.
Andrew Arch priority: medium suggestion for editor's discretion
location: example 2
suggested revision: consider adding an explanation as mentioned by Wayne on 20 May
rationale: top left cell is ambiguous re row or col heading and may sometimes benefit from the addition of a 'scope' attribute

Priority: editor's discretion
Location: related resources - techniques
suggestion: consider adding any technique (e.g. PDF6) that related to table header cells for simple tables
rationale: while the Tables concepts pages states the technologies covered are HTML and WAI-ARIA, when there are are techniques published for other technologies, these should be mentioned to lead developers/authors to the right place for those technologies.
Sharron Rush good
Bim Egan

4. Irregular Tables

Irregular Tables (Current work in progress on Github)
For each comment, remember to indicate if it is a suggestion for editor's discretion or if you feel it must be addressed before this version is published.

Details

Responder Irregular Tables
Wayne Dick Really nice.
Anna Belle Leiserson
Vicki Menezes Miller Again, vey well done.
Shawn Henry I found the second paragraph difficult to parse, but don't have suggestions for fix right now.

Priority: mild/medium
I *really* think we want on this page the first draft of the image we looked at on 9 May that had the arrows!

Priority: medium
https://w3c.github.io/wai-tutorials/tables/examples/scope-offset/
has scope="col" in the first row. Is that necessary for this table?

Priority: medium
"In this example, some of the header cells span multiple rows or columns: the “Zodiac” row header spans 3 rows, and the “Sizes available” column header spans 3 columns."
Add explanation of the markup, e.g.,: "This table uses colspan, rowspan, and colgroup to indicate the headers that span multiple rows and columns."

Needs sentence about caption & summary, & link to page.
Helle Bjarnø
Howard Kramer looks good
Sylvie Duchateau While reading this page, it is not clear to me if the proposed code is the correct one so that it can be correctly interpreted by ATs. I think there is also no indication if when using these examples the table will be easy to understand by an assistive technology or not.
Paul Schantz No editing suggestions, ok to publish.
Shadi Abou-Zahra priority: medium
location: first paragraph
current wording: "Sometimes it is hard for assistive technology to determine which columns or row to associate with a specific header cell"
suggested revision: "Tables with headers that appear at unusual places make it hard for assistive technologies, such as screen readers, to determine which columns or row to associate with a specific header cell"
rationale: disambiguate the "sometimes" using previous wording to describe "irregular tables" (see comments on "Tables Concepts" page).

priority: editor's discretion
location: third paragraph
current wording: "data cell coverage should be clearly associated"
suggested revision: "data cell coverage needs to be clearly associated"
rationale: not sure why -- just reads better to me.

priority: medium
location: example 1
current wording: entire first paragraph
suggested revision: "Assistive technologies such as screen readers typically assume that headers apply to columns. When there the first column of a table contains header information that applies across the rows, such as in this example below, use the scope attribute to programmatically declare the direction of the th cell."
rationale: again, trying to better explain the rationale and the mechanics behind the code. I'm not stuck on the wording but the current wording seems vague and a little confusing.

priority: medium
location: example 2
current wording: "data cells in the first columnand the data cells"
suggested revision: "data cells in the first column and the data cells"
rationale: typo (missing space)

priority: medium
location: example 3
current wording: "A summary can be used to explicitly describe the layout of the table"
suggested revision: "Note:" or "Important:" ... "The layout of this table is complex so that a summary needs to be provided. See Caption and Summary for ways to provide such information"
rationale: (1) need to make it stand out more; and (2) need to be more explicit that it is needed in such a situation.
Andrew Arch Priority: strong for editor's discretion
Location: Example 3
Discussion: seems to me that EG3 is not much different from Multi-level tables EG2, except the span is across rows vs columns. Why doesn't 'full colour' need a scope and why don't we need 'id' and 'headers' for this table? Seems the conditions [Where column headers are repeated or changed part-way through the table.
Those with three or more header cells related to each data cell.] are the same. If not required, then explanation needs to be provided.
Sharron Rush good
Bim Egan

5. Multi-level Tables

Multi-level Tables (Current work in progress on Github)
For each comment, remember to indicate if it is a suggestion for editor's discretion or if you feel it must be addressed before this version is published.

Details

Responder Multi-level Tables
Wayne Dick Excellent, the table split is really great. STEM accommodation sites recommend this.
Anna Belle Leiserson
Vicki Menezes Miller
Shawn Henry The whole introduction needs editing.

Example 1: I thought EOWG suggested deleting the right column to avoid horizontal scrolling.

Needs sentence about caption & summary, & link to page.

---
Priority: mild

Current: It's often possible to split complex tables up into simpler ones, which allows to have simpler and more easy to maintain HTML code. Also, simple tables are much better supported by WYSIWYG editors (“What you see is what you get”).

Suggest: It's often possible to split up a complex table into multiple simple tables, which is usually better for users and easier for coding. The two tables below provide the same information as the mutli-level table in Example 2 above.
[that last sentence is particularly needed because the FAQ jumps right to this example]
Helle Bjarnø
Howard Kramer Looks good.
Sylvie Duchateau
Paul Schantz No editing suggestions, ok to publish. Comment: very well done!
Shadi Abou-Zahra priority: mild
location: first paragraph
current wording: "That headers attribute lists"
suggested revision: "The headers attribute lists"
rationale: not sure why -- just reads better to me.

priority: mild
location: first paragraph
current wording: "Tables that should be marked up this way include:"
suggested revision: make new paragraph
rationale: think it will read better.

priority: medium
location: first paragraph, first bullet
current wording: "Where column headers are repeated"
suggested revision: "Tables with column headers that are repeated"
rationale: not sure why -- just reads better to me.

priority: medium
location: first paragraph, second bullet
current wording: "Those with three or more header cells"
suggested revision: "Tables with three or more header cells"
rationale: not sure why -- just reads better to me.

priority: medium
location: second paragraph
current wording: "ways to restructure the information to the tables to make them less complex"
suggested revision: "ways to restructure the information in such tables to make them less complex"
rationale: think it is better grammar and easier to read.

priority: medium
location: third paragraph
current wording: "Multi-level tables should have a caption and a summary to describe the layout of the table"
suggested revision: "A multi-level table needs to have a caption to identify it and a summary that describes its layout. See Caption and Summary for ways to provide such information"
rationale: not sure why -- just reads better to me.
note: consider moving this sentence after the bullet points (before the paragraph on restructuring)

priority: editor's discretion
location: example 1
current wording: example emails
suggested revision: checked if ok?
rationale: usually example.com and example.org are used -- not sure if other domains are "safe to use" for examples.

priority: medium
location: example 3
current wording: "It’s often possible to split up a complex table into multiple simple tables, which is usually better for users and easier for coding."
suggested revision: remove
rationale: repeats intro section.

priority: medium
location: example 3
current wording:
suggested revision: add "This makes the information easier to understand by everyone and easier to code too" between "the example above" and "Also, simple tables"
rationale: not as repetitive of intro section and fits better with the flow of the text.
Andrew Arch Priority: low for editor's discretion
Location: intro - para 3
Current: Multi-level tables should have a caption and a summary to describe the layout of the table.
Suggestion: Multi-level tables should have also have a caption and a summary to describe the layout of the table.
Rationale: caption & summary is in addition to 'id' and 'headers'

Priority: required
Location intro - para 3
Suggestion: check all link, but 'a caption and a summary' is 404
Rationale: need to be correct

Priority: medium for editor's discretion
location: Example 2
Suggestion: add a note that another solution to this table is discussed in Eg3
rationale: EG 2 and 3 need to be considered together

Priority: low for editor's discretion
Location: example 3
Suggestion: consider adding a note re cognitive load being easier for this solution
Rationale: it's true for all people not just screen reader users and/or those with cognitive impairments
Sharron Rush good
Bim Egan

6. Caption & Summary

Caption & Summary (Current work in progress on Github)
For each comment, remember to indicate if it is a suggestion for editor's discretion or if you feel it must be addressed before this version is published.

Details

Responder Caption & Summary
Wayne Dick Very tedious, but perfect. It really is important material. Pulling it out of line really makes the other difficult discussions go well.

There are some deep concepts in this document.
Anna Belle Leiserson
Vicki Menezes Miller
Shawn Henry priority: mild
location: bullets
current wording:
* Captions can be used to...
* A summary conveys information...
Suggestion: Use either singular (caption and summary) or plural (captions and summaries) consistently throughout as appropriate.

Priority: mild
Current: Captions and summaries provide information that can help navigate and understand tables. While not required in every case to meet WCAG2.0, captions and summaries are relatively simple ways to add information that help many.
Suggest: Captions and summaries provide information that can help users navigate and understand tables. While they not required in every case to meet WCAG 2.0, captions and summaries are relatively simple ways to add information that helps many people.

Priority: mild/medium
Current: Captions can be used to identify tables more easily by associating a table identifier (that acts like a heading) to a table. For example, if a screen reader user chooses to navigate from table to table directly the table may be explicitly identified by the caption. HTML has a dedicated <caption> element for this use case.
Suggest: Captions are like headings for tables. Most screen readers announce captions and people can use captions to navigate between tables. Captions are provided with the <caption> element.

Priority: [important to be addressed before publication]
Current: "Captions are recommended in WCAG 2.0 technique H39…" & " Summaries are recommended in WCAG 2.0 technique H73…"
I'm not sure if we want to say that techniques are recommendations…

Priority: medium
Current: It is usually needed with more complex tables. HTML4 (and XHTML 1.x) provides a summary attribute, take a look at the examples below to see solutions for HTML5.
Suggest: Summary is usually needed for complex tables. HTML4 (and XHTML 1.x) provides a summary attribute. Solutions for HTML5 are below. [no link]

Priority: mild
Current: In this example “Concert dates” tells users what information the table contains as the table otherwise may be ambiguous and could also apply to an art exhibition, for example.
Suggest: In this example, “Concerts” tells users what information is in the table (it could be something else such as an art exhibition).

Priority: mild
The text throughout uses "description" for both the caption and the summary, which could be confusing. ("the caption should be a succinct description" & " the description can be marked up using the summary attribute") Would it work to call the caption the heading or title, or would that be confusing in a different way?
Helle Bjarnø
Howard Kramer Looks good.
Sylvie Duchateau For those two comments, it would be helpful to modify before publication.
1. Location: first bullet at the beginning of the document.
Suggestion: clarify.
Original text: "A caption is like a heading for a table. Most screen readers announce captions and their users can choose between tables. The caption is provided <caption> element."
Rationale: It does not sound clear to me why through captions, the reader could choose between tables. Last sentence is also unclear, may be a word missing? "The caption is provided <caption> element."
Suggested revision: "Most screen readers announce captions and their content. This can help users to understand what the table is about and to choose if they wish to read tables' content or not. The caption is provided by the <caption> element."
2. Example 2, approach 1:
Suggestion: may be it could be helpful to explain what a scree reader conveys to help the reader understand how helpful the sumary can be. It would clarify the fact that this example indicates: "The content of the summary attribute is not available to visual users."
In approach 3, indicate if the use of ARIAdescribed is available for visual users as well. If not, indicate what would be said by a screen reader.
Paul Schantz Mild suggestion for editor's discretion:

In Approach 4, it might be useful to show a code snippet demonstrating the following:

You can explicitly associate the <figcaption> to the table by using the aria-labelledby and/or aria-describedby attributes.
Shadi Abou-Zahra priority: medium
location: first paragraph
current wording: "Captions and summaries provide information that can help navigate and understand tables"
suggested revision: "Captions and summaries provide information that can help find, navigate, and understand tables"
rationale: I think the aspect of finding/identifying is important.

priority: mild
location: first paragraph
current wording: "captions and summaries are relatively simple ways to add information that helps many people"
suggested revision: "captions and summaries are often easy to add, and provide information that improves understandability for many people"
rationale: think it is better grammar and easier to read.

priority: mild
location: first paragraph, first bullet
current wording: "Most screen readers announce captions and their users can choose between tables"
suggested revision: "Most screen readers announce captions to make it easier for users to find tables within a web page."
rationale: think it is better grammar and easier to read.

priority: editor's discretion
location: first paragraph, first bullet
current wording:
suggested revision: consider adding "Some screen readers may browse web pages in "tables mode" (especially web pages with several tables), in which captions are the primary mechanism to identify tables."
rationale: might be an important point to add. maybe too much clutter too?

priority: minor
location: first paragraph, second bullet
current wording: "the user can be told in which row or column content can be found"
suggested revision: "the summary attribute can provide information about the table layout"
rationale: don't like "the user can be told" -- by whom? how? why?

priority: minor
location: example 1
current wording: "If used,"
suggested revision: "When used,"
rationale: not sure why -- just reads better to me.

priority: strong
location:
current wording:
suggested revision: add example where the top-left cell is used to provide the caption (from example 2 of Simple Tables).
rationale: see corresponding comment.
Andrew Arch Not sure why caption & summary is only mentioned as a required in the page on multi-level tables - they could add clarity for all tables complexities (especially 'caption')


Sharron Rush as submitted on Git
Bim Egan

7. Tips and Frequently asked questions

Tips and Frequently asked questions (Current work in progress on Github)
For each comment, remember to indicate if it is a suggestion for editor's discretion or if you feel it must be addressed before this version is published.

Details

Responder Tips and Frequently asked questions
Wayne Dick
Anna Belle Leiserson
Vicki Menezes Miller
Shawn Henry Priority: mild
Current: "Don’t use headers in one column and all data in a second column as it will make it impossible for screen readers to work out the relationships between data across columns."
Suggest: "Don’t use headers in one column and all data in a second column, because as it will make it nearly impossible for screen readers to work out the relationships between data across columns."

Priority: mild
"You should not use line breaks (<br>) to create table rows as the data in the pseudo-rows may no longer align correctly when resizing the text." ->
"Don't use line breaks (<br>) to create table rows because the data in the pseudo-rows may not align correctly when text is resized."

Priority: mild
Current: "However it makes sense to distinguish <th> and <td> cells visually."
Suggest: "It is helpful to differentiate <th> and <td> cells visually."

Priority: mild
Current "It acts as a visual guide, as well as looking cool."
I thought EOWG agreed they didn't like the "looking cool".

Priority: mild
"Make sure that the contrast ratio (“color contrast”) is good for both color combinations though." ->
"Make sure that the contrast ratio between the text and background color is good for both headers and data."

Priority: mild
"Further background on _ensuring that information can be presented in different ways_ in How People with Disabilities Use the Web." ->
"_Content can be presented in different ways_ section of Accessibility Principles in How People with Disabilities Use the Web."
Helle Bjarnø
Howard Kramer Looks good.
Sylvie Duchateau
Paul Schantz Medium suggestion for editor's discretion:

Data Separation: does it make more sense to use HTML examples instead of images here?

A note on layout tables: we should probably say why it's better to use CSS instead of layout tables.
Shadi Abou-Zahra priority: strong
location: note
current wording: "It’s much better to use Cascading Style Sheets (CSS)"
suggested revision: "Use Cascading Style Sheets (CSS)"
rationale: avoid statements that could be perceived as judgment.

priority: strong
location: last point -- color coding
current wording:
suggested revision: try to show color coding in the (more complex) examples and cross-link to this piece of advice?
rationale: it is really lost here -- it seems we mostly focused on screen readers and forgot sighted users throughout the tutorial.
Andrew Arch Priority: low for editor's discretion
Location: alignment
suggestion: not just financial data, all numeric data should be right aligned (in left to right languages)
Sharron Rush OK
Bim Egan

More details on responses


Compact view of the results / list of email addresses of the responders

WBS home / Questionnaires / WG questionnaires / Answer this questionnaire


Maintained by Laurent Carcone, from a development by Dominique Hazaël-Massieux (dom@w3.org) on an original design by Michael Sperberg-McQueen $Id: showv.php3,v 1.129 2015/07/01 16:13:23 kahan Exp $. Please send bug reports and request for enhancements to lcarcone@w3.org with w3t-sys@w3.org copied (if your mail client supports it, send mail directly to the right persons)