comments on Tutorials concepts page

Priority: mild
location: first paragraph
current wording: "Data tables need structural markup to distinguish 
between header and data cells and define the relationships between them"
suggested revision: "Data tables need structural markup to distinguish 
between header and data cells, and to define the relationships between them"
rationale: I think it is easier to read with the comma before the second 
"and" but please check with someone better at grammar than I am

Priority: medium
location: content overview list
current wording: "Simple tables: Identify the topic of a row or column 
and denote those header cells with <th> elements in the markup."
suggested revision: "Simple tables: Use <th> elements to denote header 
cells for rows and columns."
rationale: more direct and less wordy.

Priority: medium
location: content overview list
current wording: "Complex Irregular tables: For tables where identifying 
header cells programmatically is not easy, they can be defined using the 
scope attribute."
suggested revision: "Irregular tables: Use the scope attribute to 
identify the direction of header cells where it is otherwise ambiguous."
rationale: more direct and less wordy. also don't think we need the word 
"Complex" in front of "Irregular" (that should be lower-case anyhow).

Priority: medium
location: content overview list
current wording: "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."
suggested revision: "Multi-level tables: Use the id and headers 
attributes to specifically associate header and data cells where it is 
necessary."
rationale: more direct and less wordy. also don't think we need the word 
"Complex" in front of "Multi-level" (that should be lower-case anyhow).

Priority: medium
location: content overview list
current wording: text alternatives
suggested revision: put the text in brackets and remove full-stops
rationale: the text alternatives are meant to be part of the sentence 
but the sentences with the text alternatives do not seem to make a lot 
of sense
side note: are screen reader users getting more information from these 
text alternatives than other readers?

Priority: medium
location: content overview list
current wording: "Most tables benefit from the use of a caption to 
describe the overall topic of a table, and summaries to provide 
orientation or navigation hints in complex tables."
suggested revision: "Use the caption element to describe the overall 
topic of a table, and the summary attribute to provide orientation and 
navigation hints in complex tables."
rationale: more direct tone

Priority: mild
location: first note
current wording: "The techniques in this tutorial should be applied only 
when a table is being used to display data in a grid and don’t apply to 
presentational (layout) tables. You shouldn’t use tables for layout 
purposes. Instead, use Cascading Style Sheets (CSS) for visual 
presentation."
suggested revision: "This tutorial applies to tables being used to 
display data in a grid. It does not apply to presentational (layout) 
tables. Tables should not be used for layout purposes. Instead, use 
Cascading Style Sheets (CSS) for visual presentation."
rationale: more direct tone

Priority: mild
location: Why is this important?
current wording: "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."
suggested revision: "Tables without structural markup (as opposed to 
visual cues only) to distinguish between header and data cells, and to 
define the relationships between them create accessibility barriers. The 
information in such tables is not read aloud correctly for screen reader 
users and cannot be presented using custom stylesheets because headers 
and data cells cannot be distinguished programmatically by software."
rationale: the initial text relies too much on the dependency on visual 
cues rather than sticking to the concept of "programmantically 
determined", which is the actual WCAG requirement

Priority: mild
location: Why is this important?
current wording: "People using a screen reader can have [...]"
suggested revision: "People using screen readers can have [...]"
rationale: plural is more consistent with the rest of the text

Priority: mild
location: Why is this important?
current wording: "People using user stylesheets can have header cells 
more prominently styled for easy recognition when there is a difference 
between the elements used for header and data cells."
suggested revision: "People using custom stylesheets can have header 
cells more prominently styled for easy recognition when there is a 
difference between the elements used for header and data cells. People 
may also use stylesheets to present the information to read the data 
cells as lists below their corresponding headers rather than in a matrix."
rationale: changed "user stylesheets" to "custom stylesheets" because I 
think it is more widely understood. Also added another use-case for 
stylesheets (I think from a discussion with Wayne).

Priority: mild
location: How to make tables accessible
current wording: first paragraph
suggested revision: remove "so that they can be interpreted by assistive 
technologies"
rationale: we've already explained the rationale in the earlier section 
- it is repetitive in this section

Priority: medium
location: How to make tables accessible
current wording: first paragraph
suggested revision: add this sentence at the end: "The caption element 
and the summary attribute may also be needed for more complex tables, 
though it is good practice to provide captions for all tables".
rationale: caption and summary have been missed here

Priority: medium
location: How to make tables accessible
current wording: second paragraph
suggested revision: remove: "The structural coding can also be used to 
represent data in different ways, for example by larger or differently 
colored text or backgrounds, Braille, speech and symbols.".
rationale: we've already explained the rationale in the earlier section 
- it is repetitive in this section

Priority: medium
location: How to make tables accessible
current wording: second paragraph
suggested revision: add something about other formats and about 
converting tables from word processors and spreadsheets to HTML. for 
example "Some document formats other than HTML, such as PDF and Open 
Office, may provide similar mechanisms to markup table structures. Most 
word processing applications do not provide such mechanisms to markup 
tables. Tables markup is also often lost when converting from one format 
to another, though some programs may provide functionality to assist 
converting table markup".
rationale: *Please cross-check each statement made in the proposed edit* 
-- this needs review and discussion by at least EOWG :(

-- 
Shadi Abou-Zahra - http://www.w3.org/People/shadi/
Activity Lead, W3C/WAI International Program Office
Evaluation and Repair Tools Working Group (ERT WG)
Research and Development Working Group (RDWG)

Received on Thursday, 22 May 2014 15:24:49 UTC