w3c/wbs-design or
by mail to sysreq.
W3C
Site Navigation
Nearby
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:
- Support for publishing the Tables Tutorial
- Tables concepts
- Simple tables
- Irregular Tables
- Multi-level Tables
- Caption & Summary
- 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
| Choice | All 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 Lawton 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.
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 Lawton 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.
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 Lawton 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.
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 Lawton 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.
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 Lawton 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.
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 Lawton 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.
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 Lawton 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
- Wayne Dick: last responded on 14, May 2014 at 19:31 (UTC)
- Anna Belle Leiserson: last responded on 15, May 2014 at 18:34 (UTC)
- Vicki Menezes Miller: last responded on 15, May 2014 at 20:30 (UTC)
- Shawn Lawton Henry: last responded on 17, May 2014 at 00:45 (UTC)
- Helle Bjarnø: last responded on 23, May 2014 at 13:21 (UTC)
- Howard Kramer: last responded on 30, May 2014 at 01:29 (UTC)
- Sylvie Duchateau: last responded on 30, May 2014 at 10:59 (UTC)
- Paul Schantz: last responded on 30, May 2014 at 17:49 (UTC)
- Shadi Abou-Zahra: last responded on 1, June 2014 at 23:12 (UTC)
- Andrew Arch: last responded on 2, June 2014 at 12:00 (UTC)
- Sharron Rush: last responded on 2, June 2014 at 23:12 (UTC)
- Bim Egan: last responded on 3, June 2014 at 07:20 (UTC)
Compact view of the results / list of email addresses of the responders
WBS home / Questionnaires / WG questionnaires / Answer this questionnaire
Report issues
on GitHub project