Re: Table tutorial review - comments

Hi Sailesh,

thanks for your feedback, we will take it into account. You can find 
some comments inline:

On 31 Dec 2014, at 18:21, Sailesh Panchang wrote:

> 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.

We try to have the intro paragraphs short to make pages more inviting, 
yet we are oversimplifying here. I’ll take it into account when we 
apply other feedback from WCAG WG.

> 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.

I think we have this covered. The aim of the sentence is to give a more 
general overview on what tables are.

What about this sentence: “Accessible tables need HTML markup that 
indicates header cells and data cells, and defines their relationship. 
Assistive technologies use this information to provide context to 
users.”

> 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.

Noted for rewording.

> 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.

While writing those tutorials we noticed a wide variety on how data 
tables are parsed and used. That would add a lot of complexity and I 
also think that the individual examples make a good case for the 
significance of such 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.

I see that “on its own” is ambiguous, it basically should mean 
„descriptive without (associated) header cells“. For example “Oct, 
26th 2015 TPAC Saporro, Japan” is easy to understand as a date, event 
name and location.


> 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".

During the creation of the tutorials we tested with a variety of 
different screen readers and configurations. Almost every screen reader 
interpreted adjacent header cells as headings for the current header 
cell. We decided after long discussions in EOWG that we’d like to 
recommend scope in all but the most simple instances.

It also is a simple change for implementers and I think it is good to 
create less situations for them to think about, especially as adding a 
(correct) scope never makes the table less accessible.

>
> 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.

(see response to #6 above)

> 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.

(see response to #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.

(see response to #6 above)
I have added the caption to the example.


Thanks for your very valuable feedback, it is much appreciated.

Best wishes for this year as well,
Eric


>
> 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




--

Eric Eggert
Web Accessibility Specialist
Web Accessibility Initiative (WAI) at Wold Wide Web Consortium (W3C)