Re: Table tutorial comment

Hi Sailesh,

see comment inline.

On 16 Jun 2015, at 16:14, Sailesh Panchang wrote:

> Eric and EO-WG,
> Sorry I am bringing this up again but it disturbs me every time I come
> across it.
> Reference: the 3-col table with Date, Event, Venue on
> http://www.w3.org/WAI/tutorials/tables/one-header/
> I do not agree with the reasoning: due to the smallness of the table,
> it is alright not to have row headers marked up.
> Even for the 3x4 table I'd like to know the date as I navigate down 
> col#3.
> And who gets to decide what is small? A content author may say, in his
> opinion, a 3x12 table is small.
> One can argue the table illustrated on  table with 2 headers on the
> WAI page too is small.

Smallness of the table is not the reasoning behind this. The reasoning 
is having data in each row/column that “is descriptive on its own and 
unambiguous”. Basically that means that each row/column could be 
interpreted correctly if there was no markup applied as well, for 
example:

12 February, Waltz with Strauss, Main Hall

This is descriptive and and unambiguous. It the table had twelve dates 
on it in that format, it would still meet the reasoning for simple 
tables.

> A simple data table usually has row and column headers.
> So I do not believe a 3+ col table can not have row headers marked up.

Of course it can, but it must not. As said, this has nothing to do with 
the number of columns but with the identification of the content.

> Account transactions on a bank's website  often do not have row
> headers marked up and that is problematic for me as a user.

I think that bank statements won’t fit the description above, maybe 
they would for the simplest case, like:

John Doe, Rent, USD -1000

but not if there are additional information and/or interactive functions 
(see details) in there.

> Maybe the date or transaction type or description col  may serve as a
> suitable row header and can be marked up with scope=row.
> HTML 4 recognized this reality and has an explicit note to this effect
> in the specs.

I guess you refer to the second sample in this section: 
http://www.w3.org/TR/html4/struct/tables.html#non-visual-rendering

(If you don’t, please point me to the example, please.)

Note that they don’t use row headings in the example although I’d 
argue that the data in the table is _not_ unambiguous (J. Dinnen, 5, 
Decaf, Yes) and thus the name should be marked up as a row cell.

> Alas HTML5 does not allow scope on TD cells  but that may be a mere
> validation issue not a SC 4.1.1 issue. So I still recommend use of
> scope=row on TD.

And the tutorials suggest that as well, yet it is not exactly required 
by WCAG 2.0, for example it uses this technique: 
http://www.w3.org/TR/2014/NOTE-WCAG20-TECHS-20140916/H63.html

> So this is a dangerous path.
> I have seen the "1-dimension table with single row / col of headerss"
> being mentioned since the introduction of HTML5.
> Before that all discussion of data tables only mentioned simple tables
> and complex / irregular tables.

Single row/col header tables are just a special form of simple tables. 
We had them all the time, this is not something that HTML5 introduced. 
In contrary, I found many people struggling implementing single row/col 
header tables in practice (they are also used in newspapers, books and 
other media). They do not want to use a th in the body of the table as 
that has often styling attached to it and they don’t want any data 
item emphasized in a row. A header cell would automatically be 
emphasized.

>
> Recommendation: do away with the category of "Tables with one header 
> ".
> Sighted users see the column headers and may associate the date or
> event as a row header mentally  as it serves as a reference point or
> row identifier although it may not be marked up as a header cell or
> appear bold / centered.
> The content author has to decide which column logically is the row
> identifier  and mark it up as TH or TD scope=row (H63).

All examples on the page DO pass the test in H63. The recommendation is 
based on it. Quote from H63:

> 1. Check that all th elements have a scope attribute.

Check.

> 2. Check that all td elements that act as headers for other elements 
> have a scope attribute.

This is not applicable, as there are no cells that act as headers.

> 3. Check that all scope attributes have the value row, col, rowgroup, 
> or colgroup.

All scope attributes have the value "col" (or "row").


> Only if there is no visible  row header as in a calendar grid or a
> column header row in a 2-column table with name-value pairs of data,
> that table  can certainly have a single table row or column  marked up
> as header cells.
> So I believe the recommendation on above referred  page stems from the
> constraint introduced in HTML5  that prohibits use of scope attribute
> on a TD cell. Understandably UI designers may not want a TH in the
> middle of a table if col#1 is not the row header column.

> The reasoning that prohibits scope on TD may make a lot of sense
> technically or in  computer science terms but if a vision-impaired
> user cannot determine the row identifier for a data table as he
> navigates a data table column while his sighted peers can, I think the
> content is inaccessible and fails as noted in F91.

If there is no visible row header (because all data is considered to be 
on the same level and one cell does not make sense with all the others 
involved as well), then this is not a failure according to H91. Quote 
from there:

> 1. headers marked up with table header (th) elements
> 2. scope attributes on th for tables with more than a single row or 
> column of table headers.
> 3. scope attributes on th for tables with more than a single row or 
> column of table headers.
> 4. headers and data cells associated using headers and id attributes
> 5. headers marked up as td elements with the scope attribute
> 6. headers marked up with ARIA role attributes rowheader or 
> columnheader
>
> If _all_ checks #1 - #4 are false, then this failure condition applies 
> and the content fails the Success Criterion.

According to my understanding all headers do have th elements (as the 
individual rows in the table body are headerless), and they have the 
scope attribute. Thus it doesn’t fail those two checks and thus is not 
failing this failure.

I welcome continued discussion on this, and think the misunderstanding 
is that I (and, based on the discussion with EO, the Group) think there 
are legitimate reasons for headerless rows/columns _in special 
circumstances_ and you think there aren’t.

WCAG WG has also vetted the tutorial and didn’t see anything to not be 
conforming to WCAG 2.0. There have been no comments on this at all.

I will check back with EO and WCAG WG chairs to see how we can address 
this issue, probably the advice in the WCAG techniques has to change, 
maybe we need to make changes to the tutorial, maybe both.

Best,
Eric


> Thanks,
> Sailesh Panchang
> Principal Accessibility Consultant
> Deque Systems Inc
> Phone 703-225-0380 ext 105
> Mobile: 571-344-1765
>
>
> On 1/7/15, Eric Eggert <ee@w3.org> wrote:
>> Hi Sailesh,
>>
>> On 6 Jan 2015, at 15:36, Sailesh Panchang wrote:
>>
>>> I thought we are giving objective  suggestions to meet WCAG 2
>>> compliance not based on opinions but on documented specs and facts.
>>
>> Sure, the foundations for the tutorials are
>>
>> - WCAG 2.0 and Techniques
>> - HTML5, CSS and other W3C specifications
>> - Established best practices
>> - The aim to communicate solutions in a clear and less complicated
>> manner to web developers as a primary audience.
>>
>>> If the doctype is HTML4, td with scope is valid and breaks nothing.
>>
>> I’m not arguing with that, but it is a technique that is not often
>> used. HTML is describing the content and I am sure a lot of people 
>> would
>> argue that a td with a scope is used as a heading and therefor the td 
>> is
>> semantically the wrong choice and a th needs to be used when scope is
>> used. (And that is reflected by the changes to HTML5.)
>>
>>> Please refer to the reasoning in the HTML4 specs .
>>> In fact TH in the second column may not be agreeable  to some UI
>>> designers (even with HTML5) because they may not want centered and
>>> bolded content in the middle of a table.
>>
>> The HTML is about semantics, not about the visual style. This 
>> argument
>> could be easy interpreted as “If a UI designers doesn’t want 
>> their
>> main heading too big they are free to use an h4”. The th is the
>> semantically correct element to use, the visual appeal should never
>> inform the usage of elements to keep the content and presentation
>> separated.
>>
>>> Using CSS to do away the
>>> visual effect of TH  negates the proper use of TH.  So when it does
>>> not suit UI design, using TD and scope may be the  way to go ... 
>>> sure
>>> it may not be valid in HTML5 but that does not fail SC 4.1.1 or any
>>> WCAG2 SC.
>>
>> I do not agree here. Usually the centered style is unwanted, a bold
>> style is usually applied. If it is data like other data in that row 
>> and
>> thus has doesn’t need any visual or semantic differentiation, it
>> should be a plain td (without a scope attribute). If the developer
>> doesn’t see the need to style the cell differently it may sometimes
>> not be a header cell to begin with.
>>
>> If it is indeed a heading for that column, it should be styled
>> differently to enable easier parsing by visual users.
>>
>> I see that the scope for td is mentioned in failure [F91] and 
>> technique
>> [H63] but it doesn’t feel appropriate to me, considering [G115]. I
>> will check back with EOWG and WCAG WG to see what to do here. For me
>> this looks like a technique from a time where CSS wasn’t widely
>> available and th styling wasn’t really easy to change.
>>
>> Considering the audience of the tutorials, we can expect them to 
>> write
>> modern code and knowing their way around CSS. I’m still not 
>> convinced
>> that this is a technique that should be thought and thus recommend 
>> for
>> the future in the tutorials.
>>
>> I will bring this to EOWG and see if and how we want to cover this.
>>
>>
>>>>> 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. ... scope
>>>>> never makes the table >>less accessible.
>>> Besides informing FS, I had also filed a bug with nvaccess.org. Both
>>> SRs (current and previous version)  work as expected now. Telling
>>> developers to put in  more markup than what's required based on
>>> testing with SRs  that had bugs  is not helpful for developers or
>>> testers. Would you fail a table if it had only TH and no scope? How 
>>> do
>>> you define small or 'most simple' table?
>>> Thanks for your consideration; I hope the comments are reviewed by
>>> more within EO-WG.
>>
>> We had people using the tables with current Jaws and NVDA and they
>> reported an increase in accessibility when using scope. I can check 
>> back
>> with them, but in general we agreed to use scope and recommend people 
>> to
>> use scope on most tables. I like to convey clear actionable
>> accessibility instructions, as they are easy to follow. If people 
>> need
>> to think a lot about how to approach something, they’ll likely do 
>> what
>> is less effort and/or complexity. Even if it is wrong.
>>
>> (If I had to decide, scope or headers and IDs would be required on 
>> every
>> table as the concepts are fairly simple and if developers used it
>> throughout their projects they wouldn’t be confused from what table
>> complexity it is necessary. But I am not making decisions on this ;-)
>>
>> As for “most simple tables”, those have easily distinguishable 
>> data
>> like “Date – Event name – City” and don’t have too many
>> columns.
>>
>> I will bring this to EOWG once again, although we had a lot of
>> discussions before.
>>
>> Best, Eric
>>
>> [F91]: http://www.w3.org/TR/WCAG20-TECHS/F91.html
>> [H63]: http://www.w3.org/TR/WCAG20-TECHS/H63.html
>> [G115]: http://www.w3.org/TR/WCAG20-TECHS/G115.html
>>
>>> Sailesh Panchang
>>>
>>>
>>> On 1/6/15, Eric Eggert <ee@w3.org> wrote:
>>>> Hi Sailesh,
>>>>
>>>> the majority of your amendment was covered by my earlier response,
>>>> just
>>>> a quick note on one aspect here:
>>>>
>>>> On 2 Jan 2015, at 14:27, Sailesh Panchang wrote:
>>>>
>>>>> Amendment to item #5 sent on Dec 31:
>>>>> "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".
>>>>> should read:
>>>>> "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 if they are marked 
>>>>> up
>>>>> as TD and not TH. It is valid in HTML4 to use TD with the scope
>>>>> attribute and there is an explicit remark about this in the HTML4
>>>>> guidance doc".
>>>>
>>>> While the use of scope in on a TD element seems possible in HTML4, 
>>>> I
>>>> wouldn’t consider this as best practice. With HTML5, scope 
>>>> isn’t
>>>> allowed on TD elements anymore, so I don’t think including this 
>>>> is
>>>> too
>>>> relevant and would complicate the message that we try to convey.
>>>>
>>>> Thanks again for your suggestions,
>>>> Eric
>>>>
>>>>
>>>>>
>>>>> Thanks,
>>>>> Sailesh Panchang
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Eric Eggert
>>>> Web Accessibility Specialist
>>>> Web Accessibility Initiative (WAI) at Wold Wide Web Consortium 
>>>> (W3C)
>>>>
>>
>>
>>
>>
>> --
>>
>> Eric Eggert
>> Web Accessibility Specialist
>> Web Accessibility Initiative (WAI) at Wold Wide Web Consortium (W3C)




--

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