Re: aria-describedat

On Wed, Mar 28, 2012 at 5: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?
>>
>>
> 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.
>
> 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.
>
> 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>).
>
> The benefits of retaining @longdesc include backwards compatibility in
> both existing content, authoring tool-chains and consuming tools (that
> support @longdesc today). Your question pre-supposes that the need *does*
> exist, which is something that some of us have maintained for quite some
> time now (and was the reason why @longdesc was added to HTML 4
> way-back-when). The long-known problem is that back then, there was no
> guidance on how it should work in browsers, and back then without clear
> guidance and the race that was "the original browser wars" @longdesc got
> left on the shelf, an important concept in need of love, but neglected.
>
> The benefits of introducing an equivalent aria-attribute is that it
> becomes language agnostic, and the same functionality can be extended to
> other mark-up languages. Once spec'ed and implemented in user-agents it
> could also pave the way to retire older, less robust means of achieving the
> end goal. As well, introducing something "new" (even if it is really an old
> concept) might see better take-up by the latest generation of web
> developers who never really learned about @longdesc, or how to use it,
> because testing it was complicated - you needed to have JAWs or some other
> @longdesc consuming tool.  HOWEVER we don't have a spec yet, and we
> certainly don't have support yet, so this would be a "in the future, moving
> forward" exercise (which is how I believe the ARIA-WG and PFWG envision it
> today). Not ready for prime time, but "in development".
>
> What benefit do you see deriving from introducing a new, native HTML5
> attribute that would outweigh either of the above? Honest and genuine
> question.
>
>
Hi John.

I thought of you jovially when I wrote my email :) The idea for a new name
is to avoid the baggage/politics, stop energy, lack of usage/support, or
whatever has prevented 'longdesc' from blossoming in the past as well as to
make it sound (and be) more general purpose. I note Silvia might think this
is a weakness and that's fair. Regarding the ARIA route, my biggest concern
with having an ARIA attribute affect browser UI for everyone out-of-the-box
is that I believe part of the beauty of ARIA is that it is purely
annotative semantics that can be added to describe existing UI without
interfering with that UI. This is a nice promise to make to people who toil
to make custom web UI work across browsers. I spent a year doing this in
dijit (dojo UI) and adding ARIA (my primary role) never broke anything
thank goodness. Ultimately I personally think this helps uptake of ARIA and
I'm aware we don't all agree. In my world ARIA is a non disruptive way to
make custom web UI accessible. I think the behavior we want for something
like @duck_soup should live as an attribute outside ARIA territory.

If the majority think we should open ARIA up to driving web UI for
everyone, and break the promise above I think we'll be making a mistake.

I don't usually add this kind of thing but I want to note: we all want to
do the right thing for optimizing web accessibility now and in the long
term and we all may have different perspectives on how to do that. That's
fine.

Cheers,
David