- From: Shadi Abou-Zahra <shadi@w3.org>
- Date: Thu, 22 May 2014 17:24:16 +0200
- To: wai-eo-editors <wai-eo-editors@w3.org>
- CC: Eric Eggert <ee@w3.org>
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