RE: Should techniques move to HTML5?

Ø  In this particular case, given that the technique of adding a scope attribute to a TD fails in at least the one test-configuration I tested in, leads me to suspect we should also ‘obsolete’ the Technique.

I don’t think this test did fail.  Wednesday had no scope but that was the “control” in the experiment.  The other cells such as Tuesday were the ones that used scope with TD and those were the target of the test.

Jonathan

Jonathan Avila
Chief Accessibility Officer
SSB BART Group
jon.avila@ssbbartgroup.com
703.637.8957 (o)
Follow us: Facebook<http://www.facebook.com/#!/ssbbartgroup> | Twitter<http://twitter.com/#!/SSBBARTGroup> | LinkedIn<http://www.linkedin.com/company/355266?trk=tyah> | Blog<http://www.ssbbartgroup.com/blog> | Newsletter<http://eepurl.com/O5DP>

From: John Foliot [mailto:john.foliot@deque.com]
Sent: Friday, December 18, 2015 2:33 PM
To: 'Mike Elledge'; 'Andrew Kirkpatrick'; Jonathan Avila; 'WCAG'
Subject: RE: Should techniques move to HTML5?

Hi Mike,

I’ll take a stab at that question.

Prior to HTML5, the W3C had a concept of ‘deprecation’ which meant that a feature/function/element/{whatever} could gracefully exit. HTML5 abandoned deprecation in favor of simply “obsolete”, with no middle, in-between quasi-ground. What this means in practical terms however is a bit more nuanced.

Browsers that supported a feature/function in HTML4.1 (or even HTML 3.2) will continue to support that feature/function to preserve backward compatibility. Assistive technology normally follow suit, but not always. The W3C validator however will flag it’s use as non-conformant. The question then becomes, what is the impact on the end user?

In this example, when testing with FF/NVDA the column that should have been scoped Wednesday did not announce that to a non-sighted user, so not only is it a technical non-conformance issue, in my mind it is a practical one as well. Contrast that against a fully conformant HTML4.1 document that you’ve added ARIA to – ARIA wasn’t around when HTML4 was spec’ed, and so a true validator should flag all uses of aria-attributes as “failures” (because at a technical level they are), yet I would never advise a client to remove aria to achieve validator conformance. So it takes some human judgement as well

In this particular case, given that the technique of adding a scope attribute to a TD fails in at least the one test-configuration I tested in, leads me to suspect we should also ‘obsolete’ the Technique.

My $0.05 Cdn

JF

From: Mike Elledge [mailto:melledge@yahoo.com]
Sent: Friday, December 18, 2015 11:38 AM
To: Andrew Kirkpatrick <akirkpat@adobe.com<mailto:akirkpat@adobe.com>>; jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com>; WCAG <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Subject: Re: Should techniques move to HTML5?

Hi Andrew, all--

It seems that deprecation in HTML5 is straightforward and means it shouldn't be used, even if it is supported by AT.

Maybe I don't understand the distinction between it being an HTML5 vs. a WCAG issue, though...

Mike

On Friday, December 18, 2015 12:27 PM, Andrew Kirkpatrick <akirkpat@adobe.com<mailto:akirkpat@adobe.com>> wrote:

It’s a good point Jon.

I tried an HTML5 file with td’s with scope (http://awkawk.github.io/table_td_scope_5.html) and found that at least on OSX that the scope attribute is honored.  I’m not sure how other combinations deal with this…

Thanks,
AWK

Andrew Kirkpatrick
Group Product Manager, Accessibility
Adobe

akirkpat@adobe.com<mailto:akirkpat@adobe.com>
http://twitter.com/awkawk

http://blogs.adobe.com/accessibility


From: Jonathan Avila <jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com>>
Date: Friday, December 18, 2015 at 11:03
To: Andrew Kirkpatrick <akirkpat@adobe.com<mailto:akirkpat@adobe.com>>, WCAG <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Subject: RE: Should techniques move to HTML5?

>  HTML5 explicitly disallows the use of scope on TD elements.

I think the first question we need to agree on is whether  td with a scope in HTML5 is or is not a WCAG 2 violation.  If we see it as a violation then I would propose adding in a comment that this would not be a failure under HTML 4/XHTML.

Jonathan

Jonathan Avila
Chief Accessibility Officer
SSB BART Group
jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com>
703.637.8957 (o)
Follow us: Facebook<http://www.facebook.com/#!/ssbbartgroup> | Twitter<http://twitter.com/#!/SSBBARTGroup> | LinkedIn<http://www.linkedin.com/company/355266?trk=tyah> | Blog<http://www.ssbbartgroup.com/blog> | Newsletter<http://eepurl.com/O5DP>

From: Andrew Kirkpatrick [mailto:akirkpat@adobe.com]
Sent: Friday, December 18, 2015 10:47 AM
To: WCAG
Subject: Should techniques move to HTML5?

Hey, we received a new issue from Mark Rogers (https://github.com/w3c/wcag/issues/127) which notes an issue in F91.  F91 includes an allowance for a table header to be identified with <td scope=“col”> but HTML5 explicitly disallows the use of scope on TD elements.

We could:

  1.  Add in "(HTML4 and XHTML only)” for the line in the procedure that allows for this
  2.  Change the entire technique to HTML5 and removing the TD scope line in the procedure.
  3.  Make a new, very similar failure for HTML5 that removes the TD scope line.
I’m sure that we aren’t interested in encouraging TD with scope, but as a failure we need to be careful.

What do people think?  Is there a downside to adapting this and other techniques to HTML5, even if it means losing some HTML4 content?

Thanks,
AWK

Andrew Kirkpatrick
Group Product Manager, Accessibility
Adobe

akirkpat@adobe.com<mailto:akirkpat@adobe.com>
http://twitter.com/awkawk

http://blogs.adobe.com/accessibility