Re: General Response to the Accessibility Task force on Issues 90, 91, 93, 96, 97

fyi...

---------- Forwarded message ----------
From: Laura Carlson <laura.lee.carlson@gmail.com>
Date: Thu, 22 Apr 2010 15:37:01 -0500
Subject: Re: General Response to the Accessibility Task force on
Issues 90, 91, 93, 96, 97
To: Janina Sajka <janina@rednote.net>, "Michael(tm) Smith"
<mike@w3.org>, Shelley Powers <shelley.just@gmail.com>
Cc: HTML Accessibility Task Force <public-html-a11y@w3.org>, John
Foliot <jfoliot@stanford.edu>

> we have numerous items on our collective plate.

This is true. Jon G, mentioned this on the survey that "I think the
more we can simplify HTML 5 elements the easier it will be to get HTML
5 and accessibility implemented and to explain to authors how to
create accessible content in HTML5. Browser developers will probably
not implement these elements anyway if they don't like them or do it
inconsistently. There is a lot in HTML5 and I think we have enough to
discuss without spending time on elements that may never be
implemented."

Jim Allan commented further on implementation, "Creation of orphaned,
poorly implemented or non-implemented elements is not the goal. Having
rich semantics that do not require an accessibility api to function
(not all people with disabilities use AT) is laudable. But, only if
implemented. Current implementations - 0, aria workarounds - 5."

Sean commented about making the case,"I think this needs more work in
the justification before its advanced to the WG. I'm not convinced by
the arguments we are currently putting forward, nor the manner in
which we are expressing them. However I'm not fundamentally opposed to
the idea that semantic elements are good for accessibility, but we
havent really made that case. Clearly we aren't in a position to
include every semantic element that might be required, so some
assembly will still be required by authors, if we include aria to make
those accessible, its not clear to me what is special about these
elements."

I share these same concerns.

The biggest concern at this point is the one Sean's had in the manner
in which the task force expressed the resolution and lack of
rationale. Shelley, I apologize for this.

I tried to go through the a11y TF face to face minutes and list out all of the
the rationale that I could find for each of your issues. Corrections
and additions from the task force members would be appreciated.

<figure>
* It's a landmark that is useful. there was a lot of argument about
the content model. Shelley said it should be just images, but people
suggested that almost anything could be a figure. People want the
language to be descriptive not prescriptive.
* Figure associates stuff. In general, semantic elements that have no
behaviour aren't used well (HTML is full of examples) but more
semantic elements that do have behaviour are useful.
* Not sure there is browser behaviour associated - maybe on certain
types of devices but UA isn't expected to do anything with it.
* If we want the figure to be equivalent to aria-labelledby we would
need figcaption to be available outside <figure>. Complete equivalence
between figure and aria-labelledby would require the figcaption can go
anywhere and have a pointer to the caption.
* Browsers on small screens can use these to linearise helpfully, and
think that is valuable
* Native semantics for these are better than annotation+style+ARIA.

<aside>
* Native semantics for these are better than annotation+style+ARIA.
* Browsers on small screens can use these to linearise helpfully, and
think that is valuable
* Magnifiers have a valid use case for changing layout based on the semantics.
* aside is WAY to vague a catch-all.
* expect the landmark elements will eventually have browser behavior,
particularly on small-screen devices.

<details>
* Specific behaviour associated.
* Makes a control for a behavior that is frequently done in script.
what details does is frequently done (badly and inaccessibly) in
script.
* Specifically useful for accessibility.
* Authors often roll their own without getting the accessibility
right, and it is expensive.
* Details isn't trivial to do in Javascript.
* There are things without elements, like accordions - I'd like to see
elements for those too, rather than removing this one...from an
interaction design perspective she might have a point that these are
similar.

<progress>
* Has specific behaviour associated.
* People want the native semantics.
* For the progress element, there are things that don't work as well
as the aria approach
* Should be improved, not removed.
* Not convinced any of these new elements will be used widely. They
may end up unloved like kbd, but they are useful and I wouldn't remove
them.
* Shouldn't it be noted that the hidden attribute is read-only?
* For the progress element, there are things that don't work as well
as the aria approach

<meter>
* Has specific behaviour associated.

<hidden>
* Not so strong on keeping the hidden attribute.
* Hidden does what the ARIA equivalent does, and seems useful.
* Could live without it given we will get it in aria.
* It's like display:none but without the nasty side effects.
* It is slightly different from aria-hidden...
* HTML5 hidden applies to ALL elements
* Not sure this has an accessibility impact...
* There is some impact (but not a lot).

Best Regards,
Laura
-- 
Laura L. Carlson

Received on Thursday, 22 April 2010 21:05:26 UTC