Re: Table tutorial comment

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)