Re: ISSUES 90, 91, 93, 96, 97 -- if you support these change proposals

On Thu, Apr 29, 2010 at 12:19 PM, Laura Carlson
<laura.lee.carlson@gmail.com> wrote:
> You have pointed out specific and detailed accessibility flaws in
> these elements. The a11y task force has said that they will make these
> elements better but have no action plan that I am aware of to do so.
> Nothing is in the Tracker. How are these elements going to be made
> accessible? I don't have the cycles for it. Who does? How will they be
> made accessible?

Several/most of the new elements have a mapping in the "strong aria
semantics" table.  Assuming their mappings are correct, we're covered
on those elements (I'm merely familiar, not fluent, with aria, and so
can merely say that they look okay to me).  Since aria is the go-to
solution for plugging accessibility holes, if the aria mapping table
is insufficient to address these semantics, it seems like *no*
existing technology could do so.

So, either the aria mapping is sufficient (assuming it's correct), or
no current technology is sufficient.  (If the aria mapping is wrong,
that's all the more reason to do it right, once, in the language spec
so authors don't have to puzzle their way past the same conundrum
every time.)

One notable absence in the list of aria mappings is the <details>
element.  I'm not sure if this is due to a weakness in aria, or if
it's simply an oversight.  The debate in the jQuery-<details> blog
comments about the proper aria to use, though, suggests *strongly*
that we should be solving this problem once and not just passing the
buck to authors.  The <details> functionality is *very* common on the
web, and it's basically *never* given any explicit semantics through
aria.

Figuring out the correct aria semantics for it, though, shouldn't be
more than a 5-minute review of the aria roles for someone fluent in
the technology, assuming that there is an appropriate aria role for
it.  If there isn't, it will obviously take more time, but then it's
an obvious lack in the aria spec, which renders both native <details>
and script-created disclosure elements incapable of being properly
annotated.  (Of course, a native <details> can still be picked up and
properly presented by a screenreader that knows about it even without
an aria mapping, which isn't true for a script-created disclosure
element.)

For now, I've filed a bug to add a mapping for <details> and <summary>
to the aria mapping table.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9623

> Another thing that is worrisome is using JavaScript to patch a native
> element which is supposed to be a solution for not having to write
> JavaScript.
> http://mathiasbynens.be/notes/html5-details-jquery

I don't understand this objection, Laura.  Rather, I find it
nonsensical, which makes me suspect that you're misunderstanding the
intention of that plugin.  It is not "patching" <details> - it's
providing <details> functionality for browsers that don't yet have it
natively.  In browsers that do implement <details>, the plugin
gracefully does nothing at all - the whole thing starts with a trivial
feature test for implementation status.

This is an interim helper while browsers still exist that don't
implement <details> (which is all of them right now, but after it
gains implementations there will of course still be legacy browsers
around for some time).  Once <details> is implemented in a sufficient
percentage of browser-share, the plugin becomes unnecessary.

~TJ

Received on Friday, 30 April 2010 00:04:48 UTC