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

On Thu, Apr 29, 2010 at 7:03 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 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.
>

No, most of the new elements do not have a mapping in the ARIA strong
semantics table. Of the ones in my change proposals, only the progress
element is mentioned.

Were you thinking of another table?

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

But there's nothing semantically interesting about the details element
-- it emulates a common JavaScript behavior.

It is the use that is semantically interesting.

When used in a popup menu, the semantic is the menu, not the behavior.
If used with table rows, it is the table, and the rows, that are
semantically interesting, not the behavior. The same with the use with
form elements, or even a way to provide additional information.

It is the use not the behavior that has the semantics. The behavior is
nothing more than a bit of animation. And even then, details cannot be
used for most of these. You can easily add new behaviors to existing
HTML elements, but you cannot easily change the structure.


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

The lack is not in ARIA, the lack is the fact that you're packaging up
JavaScript and calling it meaningful _in and of itself_. And then when
it doesn't map to ARIA, you're saying, well, it's ARIA's fault.

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

Go for it. Have lots of fun.

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

Does anyone seriously believe that developers are going to use this
far more cumbersome workaround waiting for this less that useful
element to get broad implementation?

Seriously?

> ~TJ
>

Shelley

Received on Friday, 30 April 2010 03:26:13 UTC