Re: aria-describedat

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.

Thank in advance for your thoughts.

JF

Received on Wednesday, 28 March 2012 21:06:11 UTC