Tutorials/Feedback/Tables: Difference between revisions
No edit summary |
|||
(25 intermediate revisions by 6 users not shown) | |||
Line 1: | Line 1: | ||
{{MovedToGithub|w3c/wai-tutorials}} | |||
== Resources == | == Resources == | ||
Current revision: https://w3c.github.io/wai-tutorials/tables/ | Current revision: https://w3c.github.io/wai-tutorials/tables/ | ||
== Comments after Sept publication == | |||
* Comment <span class="quiet">{Name, 2014-Month-Day}</span> | |||
== Feedback needed == | == Feedback needed == | ||
=== [https://w3c.github.io/wai-tutorials/tables/ambiguous/ Ambiguous Tables] === | === [DONE <span class="quiet">{Eric, 2014-May-05}</span>] <span class="done">[https://w3c.github.io/wai-tutorials/tables/ambiguous/ Ambiguous Tables]</span> === | ||
This section itself has an ambiguous name, and I think it isn’t clear that you can find tables where it is unclear which cells are header cells and which cells aren’t. Can you think of a better name? <span class="quiet">{Eric, 2014-Apr-22}</span> | This section itself has an ambiguous name, and I think it isn’t clear that you can find tables where it is unclear which cells are header cells and which cells aren’t. Can you think of a better name? <span class="quiet">{Eric, 2014-Apr-22}</span> | ||
* How about a different approach, for example something along the lines of below -- and then '''provide images''' to show what we mean. <span class="quiet">{Shawn 24-Apr-2014}</span> | * How about a different approach, for example something along the lines of below -- and then <span style="background:yellow">'''provide images''' to show what we mean</span>. <span class="quiet">{Shawn 24-Apr-2014}</span> | ||
** Tables with one row &/or column header<br/>''or'' Simple tables with one row &/or column header | ** Tables with one row &/or column header<br/>''or'' Simple tables with one row &/or column header | ||
** Tables with unclear headers | ** Tables with unclear headers | ||
Line 15: | Line 22: | ||
* Brainstorming: Complex tables, Confusing tables, Weird tables, Tables with confusing headers, Tables with Unclear headers, ... <span class="quiet">{Shawn 23-Apr-2014}</span> | * Brainstorming: Complex tables, Confusing tables, Weird tables, Tables with confusing headers, Tables with Unclear headers, ... <span class="quiet">{Shawn 23-Apr-2014}</span> | ||
+1: Complex tables, confusing tables <span class="quiet">{Vicki 24-Apr-2014}</span> | * +1: Complex tables, confusing tables <span class="quiet">{Vicki 24-Apr-2014}</span> | ||
* +1: Complex tables, confusing tables <span class="quiet">{Sylvie 2-May-2014}</span> | |||
==== [DONE <span class="quiet">{Eric, 2014-May-05}</span>] <span class="done">Irregular tables?</span> ==== | |||
<div class="done"> | |||
Wayne has proposed at the EO meeting last week to call the section “Irregular Tables” as that was a common term. He showed this example to us: http://wayne.knowbility.org/sceAcc/wcag2Lec02/IrregularTable.html | |||
* I think this would be a good term to use, so +1 <span class="quiet">{Eric, 2014-Apr-28}</span> | |||
* Me too for irregular tables, don't like confusing tables, think it gives wrong impression. <span class="quiet">{ Helle, 2014-MAy-01}</span> | |||
* Much prefer "irregular tables" - don't like "complex tables" in this context as it is commonly used as the term for multi-level tables and "confusing tables" is subjective ... the author may not find them confusing.<span class="quiet">{Bim, 2014-May-05}</span> | |||
* Works for me, too <span class="quiet">{Vicki, 2014-May-08}</span> | |||
* Comment <span class="quiet">{Name, 2014-Mon-DD}</span> | |||
</div> | |||
=== [https://w3c.github.io/wai-tutorials/tables/summary/ | === [DONE <span class="quiet">{Eric, 2014-May-02}</span>] <span class="done">[https://w3c.github.io/wai-tutorials/tables/caption-summary/ Caption & Summary]</span> === | ||
This section has multiple examples and approaches, some of them are only valid in HTML4. Does it make sense to keep the HTML4 example? Are the other examples clear and easy to understand? | This section has multiple examples and approaches, some of them are only valid in HTML4. Does it make sense to keep the HTML4 example? Are the other examples clear and easy to understand? | ||
* Summary is also in the XHTML spec., not just HTML4, I did a random sample of 10 UK council websites, and found that about half are using XHTML. So I think it's valid to keep the Summary technique. The descriptions are good, but approaches 2 and 3 don't programmatically associate the orientation help text to the table. <span class="quiet">{Bim, 2014-April-23}</span> | * Summary is also in the XHTML spec., not just HTML4, I did a random sample of 10 UK council websites, and found that about half are using XHTML. So I think it's valid to keep the Summary technique. The descriptions are good, but approaches 2 and 3 don't programmatically associate the orientation help text to the table. <span class="quiet">{Bim, 2014-April-23}</span> | ||
* I would keep the html4 example. The examples are clear <span class="quiet">{Vicki, 2014-April-24}</span> | * I would keep the html4 example. The examples are clear and easy to understand except for Example 2 which I find a bit odd at a glance with the days in the second column which adds some confusion. Typo after "Approach 3: Useing" > "Approach 3: Using"<span class="quiet">{Vicki, 2014-April-24}</span> | ||
* | * '''Resolved:''' Kept the HTML4 example, merged the captions in, added XHTML 1.x where appropriate. <span class="quiet">{Eric, 2014-Apr-30}</span> | ||
== Misc == | == Misc == | ||
Line 30: | Line 49: | ||
''Typos, wording suggestions and things that generally not need EOWG input/concensus.'' | ''Typos, wording suggestions and things that generally not need EOWG input/concensus.'' | ||
* "personal stylesheets" -> "user stylesheets" <span class="quiet">{Shawn, 23-April-2014}</span> | * [DONE <span class="quiet">{Eric, 2014-May-05}</span>] <span class="done">"personal stylesheets" -> "user stylesheets" <span class="quiet">{Shawn, 23-April-2014}</span></span> | ||
* [DONE <span class="quiet">{Eric, 2014-May-05}</span>] <span class="done">In [https://w3c.github.io/wai-tutorials/tables/ambiguous/ Irregular tables], second example, row 7 for Michael is empty. May be add a dash if there is no information or any number of days that was planned. <span class="quiet">{Sylvie, 2-May-2014}</span></span> | |||
=== Comments === | === Comments === | ||
Line 38: | Line 58: | ||
==== Concepts page ==== | ==== Concepts page ==== | ||
* I found this difficult to understand: <blockquote>When data is presented in tabular format, the position and styling of header cells may be sufficient to let most people know that these contain key information that gives meaning to related data cell content. However, the published style is not available to people who need to use personal stylesheets, and the position alone can’t help screen readers identify the cells that contain the header information. The header cells need to be explicitly identified so that correct associations can be made to data cells, especially in more complex tables. </blockquote> Maybe it can be simplified to something along the lines of: <blockquote>Some people can determine the header cells of tabular data from the visual cues. However, screen reader users and people with user stylesheets might not get those visual cues. Therefore, header cells need to be explicitly identified in the markup so that they are clear to everyone."</blockquote> <span class="quiet">{Shawn, 23-April-2014}</span> | * [DONE <span class="quiet">{Eric, 2014-May-02}</span>] <span class="done">I found this difficult to understand: <blockquote>When data is presented in tabular format, the position and styling of header cells may be sufficient to let most people know that these contain key information that gives meaning to related data cell content. However, the published style is not available to people who need to use personal stylesheets, and the position alone can’t help screen readers identify the cells that contain the header information. The header cells need to be explicitly identified so that correct associations can be made to data cells, especially in more complex tables. </blockquote> Maybe it can be simplified to something along the lines of: <blockquote>Some people can determine the header cells of tabular data from the visual cues. However, screen reader users and people with user stylesheets might not get those visual cues. Therefore, header cells need to be explicitly identified in the markup so that they are clear to everyone."</blockquote> <span class="quiet">{Shawn, 23-April-2014}</span></span> | ||
+1 for simplified paragraph <span class="quiet">{Vicki, 24-April-2014}</span> | * [DONE <span class="quiet">{Eric, 2014-May-02}</span>] <span class="done">+1 for simplified paragraph <span class="quiet">{Vicki, 24-April-2014}</span></span> | ||
* "Note: Other formats available on the Web such as ODF, PDF and Word have similar mechanisms to mark-up table structure." Not sure we want to put these types of comments throughout. <span class="quiet">{Shawn, 23-April-2014}</span> | ** '''Resolved:''' Used the simplified paragraph. <span class="quiet">{Eric, 2014-Apr-30}</span> | ||
* [DONE <span class="quiet">{Eric, 2014-May-02}</span>] <span class="done">"Note: Other formats available on the Web such as ODF, PDF and Word have similar mechanisms to mark-up table structure." Not sure we want to put these types of comments throughout. <span class="quiet">{Shawn, 23-April-2014}</span></span> | |||
** I’m pretty sure we don’t need them. Removed. <span class="quiet">{Eric, 2014-Apr-30}</span> | |||
** I think they should be mentioned once, perhaps on the Concepts page both to inform and to avoid kick-back on format exclusivity. <span class="quiet">{Bim, 2014-May-05}</span> | |||
==== Simple Tables ==== | ==== Simple Tables ==== | ||
* "A simple table consists of not more than one header row and/or header column." -> "A simple table has one header row and/or header column." <span class="quiet">{Shawn 23-Apr-2014}</span> | * [DONE <span class="quiet">{Eric, 2014-May-02}</span>] <span class="done">"A simple table consists of not more than one header row and/or header column." -> "A simple table has one header row and/or header column." <span class="quiet">{Shawn 23-Apr-2014}</span></span> | ||
* "Use header cell elements (<th>) to point out the information that is critical to understand the data in a table... Those <th> elements make header cells distinguishable from and associated with the correct data cells (<td>)." -> "Use <th> header cell elements to markup the header cells so that they are distinguishable from data cells and associated with the correct data cells." | ** Done. <span class="quiet">{Eric, 2014-Apr-30}</span> | ||
* [DONE <span class="quiet">{Eric, 2014-May-02}</span>] <span class="done">"Use header cell elements (<th>) to point out the information that is critical to understand the data in a table... Those <th> elements make header cells distinguishable from and associated with the correct data cells (<td>)." -> "Use <th> header cell elements to markup the header cells so that they are distinguishable from data cells and associated with the correct data cells." <span class="quiet">{Shawn 23-Apr-2014}</span></span> | |||
** Done. <span class="quiet">{Eric, 2014-Apr-30}</span> | |||
==== Multi Level Tables ==== | ==== Multi Level Tables ==== | ||
* [Bim via email, me paraphrasing] In the examples th cells need to have an headers attribute referencing | * [Bim via email, me paraphrasing] In the examples th cells need to have an headers attribute referencing a blank cell, else the (now obsolete) headers peek through and you get table headings like “Example1 Ltd Example4 Ltd”. <span class="quiet">{Eric, 2014-Apr-23}</span> | ||
====Caption and Summary==== | |||
* [DONE <span class="quiet">{Eric, 2014-May-05}</span>] <span class="done">Could the page include the info that if both caption and summary are used, the summary should not duplicate the caption. It could be part of one of the introduction paragraphs or a third bullet point. <span class="quiet">{Bim, 2014-May-5}</span></span> | |||
** Sentence is added. <span class="quiet">{Eric, 2014-May-05}</span> | |||
=== Proposals === | === Proposals === | ||
Line 55: | Line 87: | ||
* Comment <span class="quiet">{Name, 2014-Month-Day}</span> | * Comment <span class="quiet">{Name, 2014-Month-Day}</span> | ||
== Done == | |||
=== Quick Fixes === | |||
=== Comments === | |||
=== Proposals === |
Latest revision as of 14:08, 29 May 2015
Resources
Current revision: https://w3c.github.io/wai-tutorials/tables/
Comments after Sept publication
- Comment {Name, 2014-Month-Day}
Feedback needed
[DONE {Eric, 2014-May-05}] Ambiguous Tables
This section itself has an ambiguous name, and I think it isn’t clear that you can find tables where it is unclear which cells are header cells and which cells aren’t. Can you think of a better name? {Eric, 2014-Apr-22}
- How about a different approach, for example something along the lines of below -- and then provide images to show what we mean. {Shawn 24-Apr-2014}
- Tables with one row &/or column header
or Simple tables with one row &/or column header - Tables with unclear headers
- Tables with several headers per data cell
or Complex tables with several headers per data cell
- Tables with one row &/or column header
- Brainstorming: Complex tables, Confusing tables, Weird tables, Tables with confusing headers, Tables with Unclear headers, ... {Shawn 23-Apr-2014}
- +1: Complex tables, confusing tables {Vicki 24-Apr-2014}
- +1: Complex tables, confusing tables {Sylvie 2-May-2014}
[DONE {Eric, 2014-May-05}] Irregular tables?
Wayne has proposed at the EO meeting last week to call the section “Irregular Tables” as that was a common term. He showed this example to us: http://wayne.knowbility.org/sceAcc/wcag2Lec02/IrregularTable.html
- I think this would be a good term to use, so +1 {Eric, 2014-Apr-28}
- Me too for irregular tables, don't like confusing tables, think it gives wrong impression. { Helle, 2014-MAy-01}
- Much prefer "irregular tables" - don't like "complex tables" in this context as it is commonly used as the term for multi-level tables and "confusing tables" is subjective ... the author may not find them confusing.{Bim, 2014-May-05}
- Works for me, too {Vicki, 2014-May-08}
- Comment {Name, 2014-Mon-DD}
[DONE {Eric, 2014-May-02}] Caption & Summary
This section has multiple examples and approaches, some of them are only valid in HTML4. Does it make sense to keep the HTML4 example? Are the other examples clear and easy to understand?
- Summary is also in the XHTML spec., not just HTML4, I did a random sample of 10 UK council websites, and found that about half are using XHTML. So I think it's valid to keep the Summary technique. The descriptions are good, but approaches 2 and 3 don't programmatically associate the orientation help text to the table. {Bim, 2014-April-23}
- I would keep the html4 example. The examples are clear and easy to understand except for Example 2 which I find a bit odd at a glance with the days in the second column which adds some confusion. Typo after "Approach 3: Useing" > "Approach 3: Using"{Vicki, 2014-April-24}
- Resolved: Kept the HTML4 example, merged the captions in, added XHTML 1.x where appropriate. {Eric, 2014-Apr-30}
Misc
Quick fixes
Typos, wording suggestions and things that generally not need EOWG input/concensus.
- [DONE {Eric, 2014-May-05}] "personal stylesheets" -> "user stylesheets" {Shawn, 23-April-2014}
- [DONE {Eric, 2014-May-05}] In Irregular tables, second example, row 7 for Michael is empty. May be add a dash if there is no information or any number of days that was planned. {Sylvie, 2-May-2014}
Comments
Comments on the current incarnation of the tutorial, can be longer and may require EO.
- Comment {Name, 2014-Month-Day}
Concepts page
- [DONE {Eric, 2014-May-02}] I found this difficult to understand:
Maybe it can be simplified to something along the lines of:When data is presented in tabular format, the position and styling of header cells may be sufficient to let most people know that these contain key information that gives meaning to related data cell content. However, the published style is not available to people who need to use personal stylesheets, and the position alone can’t help screen readers identify the cells that contain the header information. The header cells need to be explicitly identified so that correct associations can be made to data cells, especially in more complex tables.
{Shawn, 23-April-2014}Some people can determine the header cells of tabular data from the visual cues. However, screen reader users and people with user stylesheets might not get those visual cues. Therefore, header cells need to be explicitly identified in the markup so that they are clear to everyone."
- [DONE {Eric, 2014-May-02}] +1 for simplified paragraph {Vicki, 24-April-2014}
- Resolved: Used the simplified paragraph. {Eric, 2014-Apr-30}
- [DONE {Eric, 2014-May-02}] "Note: Other formats available on the Web such as ODF, PDF and Word have similar mechanisms to mark-up table structure." Not sure we want to put these types of comments throughout. {Shawn, 23-April-2014}
- I’m pretty sure we don’t need them. Removed. {Eric, 2014-Apr-30}
- I think they should be mentioned once, perhaps on the Concepts page both to inform and to avoid kick-back on format exclusivity. {Bim, 2014-May-05}
Simple Tables
- [DONE {Eric, 2014-May-02}] "A simple table consists of not more than one header row and/or header column." -> "A simple table has one header row and/or header column." {Shawn 23-Apr-2014}
- Done. {Eric, 2014-Apr-30}
- [DONE {Eric, 2014-May-02}] "Use header cell elements () to point out the information that is critical to understand the data in a table... Those elements make header cells distinguishable from and associated with the correct data cells ()." -> "Use header cell elements to markup the header cells so that they are distinguishable from data cells and associated with the correct data cells." {Shawn 23-Apr-2014}
- Done. {Eric, 2014-Apr-30}
Multi Level Tables
- [Bim via email, me paraphrasing] In the examples th cells need to have an headers attribute referencing a blank cell, else the (now obsolete) headers peek through and you get table headings like “Example1 Ltd Example4 Ltd”. {Eric, 2014-Apr-23}
Caption and Summary
- [DONE {Eric, 2014-May-05}] Could the page include the info that if both caption and summary are used, the summary should not duplicate the caption. It could be part of one of the introduction paragraphs or a third bullet point. {Bim, 2014-May-5}
- Sentence is added. {Eric, 2014-May-05}
Proposals
Proposals for new sections and examples can go here.
- Comment {Name, 2014-Month-Day}