W3C home > Mailing lists > Public > public-html@w3.org > May 2012

Re: HTML-A11Y Task Force Consensus on Issue-204 (Updated)

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 23 May 2012 16:09:38 -0700
Message-ID: <CA+c2ei8cWjqFMNKSJ82w6VqSc159vOHrS0KBVnBLvT99EtXQ=w@mail.gmail.com>
To: Sam Ruby <rubys@intertwingly.net>, Maciej Stachowiak <mjs@apple.com>, Paul Cotton <Paul.Cotton@microsoft.com>, "Michael(tm) Smith (mike@w3.org)" <mike@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>, public-html@w3.org, Judy Brewer <jbrewer@w3.org>
On Fri, May 11, 2012 at 5:35 PM, Janina Sajka <janina@rednote.net> wrote:
> Colleagues:
> The Issue-204 Change Proposal supported by the HTML-A11Y Task Force on
> 26 April last was modified slightly, but significantly during the
> recently concluded HTML-WG Face to Face meetings in Mountain View,
> California.
> The updated proposal is available at:
> http://www.w3.org/html/wg/wiki/Correct_Hidden_Attribute_Section_v3

Hi everyone!

While I wish I had more time to track the conversations happening here
regarding issue 204, I wanted to at least provide a comment to this
"v3" proposal.

I definitely think it's a big step in the right direction. Allowing
user agents to do their best to make a page accessible to all users is
definitely the first step that we need to take.

However, there are a couple of things I would like to see changed
before fully supporting this proposal over the other ones proposed.

While allowing UAs to expose the accessibility tree of @hidden content
is great, I think we should make it a MUST level requirement. I don't
see any benefit in allowing UAs to stringify the contents of the
element when pointed to by aria-describedby and other similar
attributes. Doing so seems strictly worse for AT users.

I would be ok with, as is proposed, putting wording in the
specification stating that older UAs stringify the contents of @hidden
elements, and that authors should be aware of this when creating

However I don't understand why we think it's more important to point
this out for the @hidden feature, than for example for <input
type=date> [1]. Here too authors need to be aware that older UAs don't
expose the experience for neither AT users nor non-AT users.

Likewise the @defer attribute doesn't work in older UAs [2] which will
result in scripts executing in a different order which often makes
pages completely unusable for everyone. In fact, it's true for almost
any feature introduced by HTML5 that authors need to be aware that it
doesn't work in older UAs and thus take appropriate precautions.

A good example is aria itself which isn't even fully supported by over
50% of browsers, and 13% of browsers doesn't support it at all[3]. Yet
I can't find any mention of the need to be cautions in the aria
specification. Neither in the  Authoring Practices section, nor in the
description of the individual features.

But to be clear, I'm definitely ok with putting a warning in the
specification. But maybe such a warning better belongs in a generic
introduction at the top of the specification generally warning authors
to not depend on new features, or even in a separate primer document
describing practical aspects of how to author HTML5 documents which
surely would contain a section about authoring for non-compliant

[1] http://caniuse.com/#feat=input-datetime
[2] http://caniuse.com/#feat=script-defer
[3] http://caniuse.com/#feat=wai-aria

/ Jonas
Received on Wednesday, 23 May 2012 23:10:39 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:52 UTC