RE: Drop longdesc, get aria-describedat?

Silvia Pfeiffer wrote:
> 
> That's not concrete enough. If we say "discoverability", we have to
> say how. Context menu is a good answer.

Actually, you are very wrong here.  Context menu is perhaps a possible
answer, however it is not the *only* answer. Are you aware of Indie UI?
(http://www.w3.org/2011/11/indie-ui-charter). How would you invoke a
contextual menu in a mobile browser without a mouse or keyboard?
Discoverable is the correct response, and frankly that should be left to the
browsers to develop how to manifest that. 

Context menu is likely/often a good choice, but other means/methods could
include a visual indicator in the browser chrome (Tell Me More extension for
Opera) or a user-setting that allows the end user to over-ride the
designer/developer and place a visual indicator on-screen (LongDesk
extension for Firefox). Finally, while we can hint on UI patterns and
interactions, it is out of scope for HTML5 to spec such items. (see more,
below)


> >
> > Given that most browser vendors have not lent support to @longdec
> over the
> > past 10+ years, I remain suspicious that they will do anything more
> today
> > with a new attribute that will have essentially the same functional
> > requirements that @longdesc has had since it's inception at HTML4.
> 
> 
> Frankly, that's rubbish. There is a time for everything. @longdesc was
> apparently not sufficiently specified such that the browsers all
> started implementing different support and the screenreaders had to
> come up with tricks to make it work.

With all due respect, if you are going to lecture me on the history of
@longdesc, you had best do your research first, as I have been actively
supporting and encouraging the use of @longdesc since it was introduced in
HTML4, as this example from 2002 will attest
(http://www.wats.ca/show.php?contentid=34). Your perception and
understanding of the history and problem is quite wrong.

For the first number of years we had little-to-no support anywhere (neither
screen readers nor browsers), and there has *never* been usable support from
any of the mainstream browsers, except for Opera and iCab, in the history of
the attribute. When the screen readers that do support @longdesc started to
provide support, they queried the DOM directly for the attribute and its
value, as they continue to do so today. There is no "trickery" involved, and
I suggest you stop believing the FUD and propaganda that the WHAT-WG trolls
are spreading. Surely you are not going to suggest that querying the DOM is
a trick, is wrong, or is something the tools should not be doing?


> Also, in the last years browsers
> have implemented ARIA support so a lot more attention has gone to
> accessibility.

ARIA is a great technology, and I am actively promoting its use today.
However, to be very, very clear, ARIA is not some magic elixir that solves
all problems with regard to accessibility. We don't have "aria-track" for
closed captions in video do we? No - and why? Because closed captions
benefit more than just screen reader users. 

ARIA provides no support for people with cognitive disabilities. ARIA
provides no support for users with mobility impairments. ARIA provides no
support for users with hearing impairments, and ARIA has very little support
for users of screen magnifiers today. In fact, while ARIA is a huge benefit
for non-sighted users, outside of that user-group it does very little for
any other user or user-group.

Equating ARIA to "accessibility-problems-solved" is dishonest and
unrealistic - it is but part of a much larger set of user-requirements and
needs that must be addressed, and shunting off all that pesky accessibility
stuff to ARIA and the AAPIs is simply a dismissive and ill-conceived
"solution" that fails more disabled users than it helps.


> We now understand the issues of @longdesc better and
> can much more clearly explain what the attribute needs to do. Frankly,
> @longdesc is a lost battle and does not apply to new elements such as
> video and audio, so IMO starting from a clean slate and putting our
> effort behind that is bound to be much more successful.

Since we can and have been "much more clearly" explaining what we need from
the attribute, why is it that we still cannot get the browsers to lift even
1 finger towards doing what is needed. Why reinvent the wheel for audio and
video when we could repurpose an existing, serviceable attribute today? Why
*can't* we apply @longdesc to <video>? I've already suggested that we could
and should do so.

> 
> Sure: we got to start somewhere. EPUB is starting somewhere, too. For
> video and audio elements we start from a clean slate, too. I think the
> @longdesc experience is helpful in getting this implemented faster.

I wish I shared your optimism.

> 
> I've never seen progress being made by holding on to the past. That
> cowpath is not one that is working, so I don't know why you're
> clinging to it.

Because it is working Silvia, despite the protestations of Hixie, Matt
Turvey and others, it is seeing continued adoption, emergent author tools,
jQuery plugins and browser extensions, and it has strong and robust support
in the single largest screen-reader on the market. That the engineers behind
Web-Kit, Gecko and other browser engines have not spent the time and effort
to do something useful is a sad state of affairs, but it has not held back
the usage or support from other quarters and other User Agents.


> 
> This has nothing to do with the future: this is about how to deal with
> the past. There are other means of dealing with this. As tools
> implement support for a new attribute, they can continue to support
> the old attribute or even create methods that automatically move
> values from one to the other depending on what was authored.

No argument. But to achieve what you have described we cannot Obsolete
@longdesc today. It needs to be retained in HTML5 to do what you have
proposed, and any discussion that heads in another direction will result in
a failure to create a graceful "hand-off" path.

> 
> 
> > Do we have any evidence that the browsers will do *anything* with
> ARIA
> > attributes beside push them on to the AAPIs, for "AT" to deal with
> it?
> 
> That depends on what the spec tells them. If we want anything else to
> happen, we have to explain that. Other uses won't just magically
> appear.

Once again, it is outside of the scope of the HTML5 spec to prescribe UA
interactions:

	"This specification is limited to providing a semantic-level markup
language and associated semantic-level scripting APIs for authoring
accessible pages on the Web ranging from static documents to dynamic
applications.

	The scope of this specification does not include providing
mechanisms for media-specific customization of presentation (although
default rendering rules for Web browsers are included at the end of this
specification, and several mechanisms for hooking into CSS are provided as
part of the language).

	The scope of this specification is not to describe an entire
operating system. In particular, hardware configuration software, image
manipulation tools, and applications that users would be expected to use
with high-end workstations on a daily basis are out of scope."
http://www.w3.org/TR/2011/WD-html5-20110525/introduction.html#scope 


> 
> 
> > I have concrete proof that in at least one instance they won't in the
> form of
> > how they are handling the HTML5 @required attribute in form inputs
> vs.
> > aria-required="true". For while conceptually they should be *THE SAME
> > THING*, they are not processed the same way, and in the case of
> Mozilla they
> > have no intention of changing that disparity any time soon. (see:
> > http://john.foliot.ca/required-inputs/)
> 
> If they are identical, why would you need two of them?

Good question - why not ask the browsers, who support one but not the other?
It appears that the aria-required is for "screen readers" and @required is
for everyone else. You can perhaps understand then why I remain skeptical
that the browsers will use ARIA attributes for anything, or at best "screen
readers" given their current track-record.
 

> 
> 
> > The problem is, and remains, a User Agent problem, where a few
> 'bully' User
> > Agents refuse to do anything useful with an attribute, while other
> User
> > Agents do do something useful. If the major browsers are not going to
> > actually provide some form of tangible support for a mechanism to
> provide
> > longer textual descriptions upon request (and after providing a means
> to
> > notify the user) then they should step aside and leave this problem
> to those
> > who *WILL* do something. I have repeatedly suggested it's not the
> name of
> > the attribute that matters, it's what User Agents do with it that
> counts
> 
> You can always do an implementation yourself and gain larger
> "bully-power" - WebKit and Firefox are open source.

Give me a break. I could also write a second specification which contradicts
the WHAT WG spec, and in fact have done so once before, where I successfully
managed to block a heart-beat publication at the W3C based on "lazy
consensus" (around @summary and Ian's disregard for process - which led in
part to the establishment of the existing processes we have in place today
within the Working Group). The reality however is that any action which
seeks to fork or divide the mainstream is in fact harmful to the mainstream,
and I have no desire to create the next IE6, whether as a 'different'
browser or alternative spec version.

> 
> 
> Anyway, I think we should write a spec and start shopping it around
> with browser developers to get some feedback and see if there is will
> to implement. Whether we call that attribute @aria-longdesc or
> @aria-describedat or just extend the existing @longdesc to video and
> audio and update its spec (which I frankly think is the maddest path
> of them all) doesn't really matter - a problem needs to be addressed.

Agreed, to the extent that we need to see what, if anything, the mainstream
browsers are prepared to support. To date, the response has been - uh,
nothing.

JF

Received on Tuesday, 13 March 2012 07:40:48 UTC