- From: Sailesh Panchang <sailesh.panchang@deque.com>
- Date: Wed, 31 Dec 2014 12:21:03 -0500
- To: wai-eo-editors@w3.org
Hello EO-WG, Here are some comments for your consideration presented with the hope the tutorial will become better and more robust. 1. Table concept: Data tables are used to organize data in grids. Comment: Does not really say what a data table is. A layout table too organizes data into grids, so what's the difference? Need to highlight that for a data table: - at least 2x2 - logical relationship exists between cells / rows of data - every row is a record analogous to a row in a database table - data in a single column presents a single attribute for each record. As against this, a layout table is used to present content in a grid but the content of cells bear no relationship with other cells. The tabular format is only for formatting. 2. Accessible tables need HTML markup that indicates the difference between header cells and data cells, and indicate the relationship between them. Comment: Consider instead the following: With proper accessibility markup, header cells are exposed as such to assistive technology. or For a data cell, AT is able to identify related header cells. 3. Under 'Why is it important?' it says: Tables without structural markup to differentiate between header and data cells, and to define the relationship between them, create accessibility barriers. Comment: Needs editing to make it meaningful. 4. Maybe a sub section with heading, "How do individuals with disavilities / screen reader users navigate a table?" will help some users understand the significance of proper table markup. 5. Basic tables: When the content of a simple table is descriptive on its own, only a header row or column is needed to give the user an impression of the data in the table. Comment: Not clear what "descriptive on its own" means. A table does not describe anything... it only presents data in a grid. Also "give impression of the data in the table" needs re-wording. It should refer to the ability to comprehend data relationships. i.e. relationship of data cells to their header cells. 6. "If the table is larger or its content is more ambiguous, the scope attribute should be used to avoid confusion". And in example 1: "The following table of concerts has the cells in the first row marked up as <th> cells without any scope direction. This is only acceptable because it is such a small table and the data itself is distinctly different in each column. Note: Some screen readers will read “Date – Event – Venue” on the “Venue” cell because the direction of the <th> elements is ambiguous". Comment: "larger or its content is more ambiguous" is itself vague /not well defined. Use of scope is not warranted merely based on number of rows or columns. Secondly, for a simple table with TH in first row and / or first column, the scope attribute really does not add value and is unnecessary. It is merely redundant markup. (It only prevented older versions of JAWS from reading all TH cells above current cell in the first column of TBODY as header cells ). Also older versions of JAWS(before JFW 15) may have read all cells to left of current cell in the first row as headers. This is a bug and is not the case now. I had pointed this out to FS a while ago. Please refer to definition or description of "data table" in comment#1 above. Every column of a data table indeed presents a distinct attribute so it is not useful to justify not using scope with "such a small table and the data itself is distinctly different in each column". The only instance where scope is needed in a simple data table is where the row identifier is not in the first column like in "Example 4: Table with an offset column of header cells". 7. Refer to Example 1: Table with ambiguous data. Comment: Merely using <th> for cells in the first column is sufficient and it does not fail to correctly expose the cells as column headers. The scope attribute does not add value. See comment#6 above. Also this table may fail because the rows have no row identifier that is marked up a TH. One cannot go down the 3rd column with a screen reader and understand the context for the data cells. A calendar table on the other hand is a good example where only cells in the first row need TH markup if the intent is to present such a table. 8. Refer to Example 2: Table with header cells in one column only Comment: The table works fine with TH in first column with no scope. See comment#6 above. 9. Example 3 with Country and Capital City as column headers as well as table with Delivery Slots". Comment: The table works fine with only TH markup for column / row header cells and no scope. Also note there is no caption for 'delivery slots' table. ... needs to be corrected. Thanks and best wishes for the new year. Sailesh Panchang Principal Accessibility Consultant Deque Systems Inc. Phone 703-225-0380 ext 105 Mobile 571-344-1765
Received on Wednesday, 31 December 2014 17:21:31 UTC