Re: Table tutorial comment

Hello Eric,
Thanks for your responses. Here are my thoughts:

Right, on that HTML 4 page
(http://www.w3.org/TR/html4/struct/tables.html#non-visual-rendering) I
am specifically referring to:
"Note that it's not always possible to make a clean division of cells
into headers or data. You should use the TD  element for such cells
together with the  id  or  scope  attributes as appropriate".
The moment content is marked up as a data table, it is a two-dimension
representation. By its very nature, it permits  functionality that is
not possible in content  marked up as a list i.e. single dimension.
So if "12 February, Waltz with Strauss, Main Hall" is a list item, one
cannot navigate down just the date column or the event column or venue
column.
If this indeed were marked up as a list, sighted users and screen
reader users will be able to access only the intended functionality
i.e. read an entire list item one by one.
For a screen reader user, going down any of the 3 columns is like just
going down a list of dates, events or venues. These are not marked up
as 3 separate lists but as a data table for a very precise reason: to
expose data relationships through presentation in a manner that offers
functionality that a single dimension list cannot.
In a table, visually one can run down a column and  also be imbibing
referential data from an adjacent cell  so the content makes complete
sense.
A screen reader user cannot do so unless row header cell is marked up
as a header.
In a sales invoice with item code, item description, rate, quantity
and amount as column headers, if I navigate down say, the rate or
quantity column, I'd like the item code or description announced as a
reference point.
I agree in a bank transaction table with date, transaction type,
description, debit/credit and amount as five columns, neither the date
or transaction type or even description may be unique or distinct to
identify a row.
Yet, marking up one of those with scope=row provides the needed
reference. Sure it is  not the only meaningful "header" for a row, but
it serves as a very useful reference point and thus as a row header.
I believe this principle is ensconced in the H63 test:Check that all
td elements that act as headers for other elements have a scope
attribute.
The cells in a column act as row header or a reference point. When
this relationship is not strong / unique or not in the first column
(general convention for row headers), the scope attribute is very
handy.
Relevant normative definitions:
relationships:  meaningful associations between distinct pieces of content
presentation:  rendering of the content in a form to be perceived by users
functionality:  processes  and outcomes achievable through user action

Basically a data table contains record(s) of data and every cell
represents an attribute of the record. In a table one at most times
wants to understand / compare / look for  a cell value and a column /
row header provides the necessary reference or identity.
Actually in a simple table pulled from a database too, it may not be
possible to uniquely identify every record simply by its primary key
and one may need to use primary+secondary key to do so. So in a table
of bank transactions too header-id method that exposes 2-3 cells as a
row header may be really useful. But  this may be  impractical to do
for a simple table. At the minimum, exposing the date or tran type or
description is a compromise.

On the WAI-EO tables tutorial page, reference to "smallness" of the
table is prominent:
"The following table of concerts has the cells in the first row marked
up using the <th> element. This is only acceptable because it is such
a small table
and the data itself is distinctly different in each column, so that
the relationship between the header and data cells is evident".
And you added: "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”.

So does this mean that a developer must always look and examine the
data to verify if it is distinct and "unambiguous" as you put it and
then determine the markup? So if the data is pulled from a  database
or  represents a set of transactions, then a table with the same set
of column headings might need row headers for one set of data and not
for another because one fails to meet the test of "unambiguous"? And
what if the one that meets the test has 15 rows in 3 columns? Is that
big or small?

You misinterpret my words when you say : "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".
I did not say HTML5 introduced them but remarked that I have observed
the trend to separate them out as a class of simple tables has gained
prominence since the intro of HTML5.
So previously, if an accessibility tester noticed that a data table
did not have row headers and col#2  was the ideal candidate for row
headers, H63 (td scope=row)  was the fix. Now developers may think
twice because scope cannot be used with TD cells in HTML5 and they may
resist the idea of marking col#2 cells as TH.
Placing role=rowheader will expose it as header cells to screen readers.
Role=rowheader on a TD says "I am a row header" to AT and that is what
scope=row on TD does too, right?
If it is wrong for a TD cell to be exposed as a header cell to user
agent, does switching one attribute with another make it less wrong?

Thanks very much,
Sailesh Panchang







On 6/16/15, Eric Eggert <ee@w3.org> wrote:
> 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)
>
>

Received on Wednesday, 17 June 2015 20:00:34 UTC