Re: aria-describedat

On Wed, Mar 28, 2012 at 2:05 PM, John Foliot <john@foliot.ca> wrote:
> Quoting david bolter <david.bolter@gmail.com>:
>
>> Hi all,
>>
>> If there is increased need for media and visually complex html to have a
>> URL to something like a transcript or a description, isn't html ready for
>> a
>> straight-up @hasurl which a browser would expose to everyone?


While a nice idea, @hasurl is a broad concept and doesn't state what
you're supposed to find behind the url. I believe what we're after is
something a bit more semantic - a link that takes a user to a Web page
that contains (mainly textual) metadata about the element (and
possibly its subelements) to which the url is attached. As usual,
finding a good name is very hard.



> Hi David,
>
> Good to see you comment here.  Without wanting to be confrontational, what
> in your mind would be different between @hasurl and @longdesc outside of the
> name?
>
> There has been some discussion about extending
> "the_native_HTML_thing_that_takes_a_URL_and_points_to_additional_text_description"
> so that it might be applied to a broader range of elements beyond <img>
> (which I think has broad support in principle), which would be one of the
> goals and benefits of an aria-attribute solution, although there is no
> reason why a new native HTML attribute (@hasurl) or even an existing HTML
> attribute (@longdesc) could not also do the same.

@longdesc has existing implementations and specifications.

Going forward, we want a solution that does all of the following:
* need a way to associate a long text representation of an element
with an element
* an URL to a Web resource (preferably a HTML page or fragment) is
likely to be sufficient
* need this to work on any HTML element
* needs to be machine discoverable (i.e. just relying on <a> elements
underneath the element won't cut it)
* need a visual representation of the availability of such a URL (e.g.
in the shadow dom, similar to how video controls are randered)
* need authors to be able to style the visual representation if it's
in-page (i.e. in the shadow dom) and not just in-browser (i.e. on a
browser toolbar)
* need to recommend interaction means that allow a user to follow the
URL (e.g. context menu, or shift-click/shift-enter, or ??)
* need the URL to be announced to screenreaders (i.e. this has both a
visual requirement as well as a a11y API requirement)
* would like to be able to just copy and paste the element to another
Web page and retain the link (i.e. <a href with link_for=element>
somewhere on the page won't do)
* would like to have the text representation link also usable as the
fallback for old browsers for new elements like <video> (this may not
be automatic, but require the author to duplicate the URL link - e.g.
in the case of <video> it might require putting an additional <a>
element inside the <video> element)

What other requirements do we have to solve the general need for
attachment of long descriptions?


> To many of us, the key is the last part of your question: "...which a
> browser would expose to everyone".  Without browser support, any benefit
> derived must be gleaned directly by 3rd party agents. This is what JAWs does
> today with @longdesc, and/but this is also why NVDA does not support
> @longdesc: both Jamie and Mick confirmed to me at CSUN '11 that they didn't
> want to have to create a new user-interaction, but wanted instead to map to
> an existing browser interaction method. If Firefox had a means for all users
> to discover and act on the longer textual descriptions, then NVDA could map
> to *that* and NVDA users would benefit as equally as sighted users.

JAWS and NVDA seem determined to not want to introduce a new
user-interaction for @longdesc (which I think is fair enough, seeing
as it's an attribute that's only used for accessibility). This is a
fundamental problem when we allow the new attribute on any element and
for all users: e.g. <a href longdesc> would create a conflict as to
what url a "click" has to follow. We definitely need a new user
interaction for the new attribute. Therefore, giving it a new name and
new interaction and new applicability makes more sense to me.


> I have long maintained (personally) that "what" we call it is less important
> than the functionality we get from the "thing" that we are naming. We could
> call it @duck_soup and I would be happy if we got the functionality we
> required from the attribute, which is: a) Discoverability, b) Choice in
> consuming or not consuming, c) supports rich HTML markup (including tab-able
> elements such as <a>, <li> and <td>).

Excellent. My wish list is even longer. :-)


> The benefits of retaining @longdesc include backwards compatibility in both
> existing content, authoring tool-chains and consuming tools (that support
> @longdesc today).

None of which satisfy our requirements.

I would prefer we leave @longdesc with its current semantics for now
and when we introduce the new attribute, we deprecate it in favor of
the new attribute. This means that backwards compatible browsers will
still have to support @longdesc in the way it was originally
specified, but that they can at the same time implement the new
functionality for the new attribute and actually give us a way to move
forward into a better world.

Cheers,
Silvia.

Received on Thursday, 29 March 2012 18:31:24 UTC