Re: Table tutorial comment

Hi Sailesh,

as promised, I checked back with WCAG WG chairs. This discussion had 
come up in WCAG several times and the resolutions support the approach 
as noted in the tutorial.

As one example of such resolutions I got handed this email: 
https://lists.w3.org/Archives/Public/public-comments-wcag20/2012Nov/0003.html

The WCAG WG has been consistent about this point.

Of course, if you disagree, you’re invited to talk to WCAG on that 
matter by sending comments to public-comments-wcag20@w3.org or by using 
this form: http://www.w3.org/WAI/WCAG20/comments/techniques.php

Best,
Eric

On 17 Jun 2015, at 22:00, Sailesh Panchang wrote:

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




--

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