Re: Moving longdesc forward: Recap, updates, consensus

On Fri, May 6, 2011 at 9:38 PM, John Foliot <jfoliot@stanford.edu>
wrote:
> 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'm saying HTML5 conforming user agents should not be required to
implement user stories like:

    * Allow users to follow links.  Allow users to fill out forms.
    * Allow users to play videos.  Allow users to read web page titles.
    * Allow users to read page metadata.  Allow users to navigate by
    * heading.

To put it another way, I believe HTML5 user agents should be free to
define how they are agents for the user, and what renderings and UI is
required for that.

For example, if you make an app that just screenshots a given URL, it
makes sense to require you to follow HTML5 loading rules and render
elements according to their semantics. It makes no sense to require you
to make the links clickable or @longdesc discoverable.

Often user agents define their agency in terms of behaving like a
typical web browser like Firefox or Internet Explorer. The spec includes
an informative rendering section to help them do that.

Often user agents additionally define their agency in terms of
accessibility to lots of different user groups. We have UAAG 2.0 and the
HTML-accessibility APIs mapping guide to help them do that.

>> 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?

The spec doesn't require printer software (say) to allow users to
activate links in a page being printed; I think it would be odd to
require them to allow users to access long descriptions for images in
the page being printed.

It's more reasonable to require implementing these user stories in an
interactive user agent such as a run-of-the-mill web browser.

--
Benjamin Hawkes-Lewis

Received on Friday, 6 May 2011 21:17:24 UTC