Re: Table tutorial comment

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.

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.
Account transactions on a bank's website  often do not have row
headers marked up and that is problematic for me as a user.
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.
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.
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.

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

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)

Received on Tuesday, 16 June 2015 14:14:33 UTC