RE: Moving longdesc forward: Recap, updates, consensus

Benjamin Hawkes-Lewis wrote:
>
>
> I'm wary of constraining the user agent conforming classes to do
> *anything*
> with the semantics we are defining in HTML5 and in general the spec
> shies away
> from imposing such constraints. It should be possible to define loading
> behaviors, semantic interpretation, and APIs for documents without also
> mandating the adoption of particular user interface goals as well.

Hi Ben,

While I can accept that statement on face value, I am not sure how you would 
see this manifest. By default the 'link' (and that is what it is) operates 
in the same fashion as any other link: if it is a HREF it loads in a new 
window unless scripted otherwise, and if it is an IDREF the focus is placed 
at that point in the document tree. Are you suggesting that we might be 
either more specific or suggest other behaviors? As an attribute of the 
parent <img> element, the semantic interpretation seems to me fairly 
straightforward as well, so I am not grasping what you are aiming at. Having 
spent some time talking with a few engineers who have an accessibility bent 
to their work (including the 2 core developers of NVDA) I see a consensus 
pattern emerging around the contextual menu as the means to interact with 
the longdesc attribute value. Could you elaborate more please?

>
> I think UAAG 2.0, not HTML5, is the right place to specify
> accessibility
> requirements for browsers, such as universal access to text
> alternatives:
>
> http://www.w3.org/WAI/UA/2011/ED-UAAG20-20110406/#gl-access-
> alternative-content

I have no real issue with the means by which user-agents expose the 
functionality, or where it may be defined/recommended/described, I am more 
concerned that we retain the functionality of @longdesc in the HTML 
specification. I think that your point is in some ways orthogonal to the 
central discussion.

>
> Irrespective of whether we propose "SHOULD" or "MUST", I think it might
> be a good idea to provide spec text concisely explain how text
> alternatives, short and long, can be useful to different user groups.
> (Otherwise we may end up with implementations optimized for one user
> group such as users who are blind.)

I agree with you here.

>
> If we do shift to "MUST", I think we should talk about "interactive
> user agents" rather than just "user agents". For a discussion of this
> distinction, see the conformance classes section of the spec:
>
> http://dev.w3.org/html5/spec/infrastructure.html#conformance-classes

Can you please elaborate more?

JF

Received on Friday, 6 May 2011 20:39:18 UTC