Re: UAWG comments on the HTML5 Image Description Extension

Dear Jim, thank you for your comments. Please let us know if you are
satisfied with our replies, detailed below.

We have published an updated editors' draft, which we hope to make a  
Candidate Recommendation. Please review it at  
https://dvcs.w3.org/hg/html-proposals/raw-file/default/longdesc1/longdesc.html

We therefore hope to completely resolve these before the end of June.

On Thu, 23 Jan 2014 18:26:07 -0500, Jim Allan <jimallan@tsbvi.edu> wrote:

> Below are UAWG comments on the HTML5 Image Description Extension
> (longdesc)  
> (https://dvcs.w3.org/hg/html-proposals/raw-file/default/longdesc1/longdesc.html).
>
> Important Comments:
>
> 1.  Other image types: We don't understand the decision to allow the
> new longdesc to apply only to img elements, as it seems to be just as
> appropriate for things like groups of images (which may make up one
> whole image as far as the user is concerned), svg elements, objects,
> and even tables or arrangements of colored divs. We recommend allowing
> longdesc to apply to other elements.

There may be work on a new aria attribute that would generalise the
applicability. We wanted to preserve backward-compatibility with the HTML
4 attribute, without trying to take up work that probably makes more sense
in the context of ARIA - which can also be applied outside HTML e.g. to
SVG.

> 2.  Discoverable by users: Section 3.0.03 says 'User agents should
> enable users to discover when images in a page contain a long
> description. We believe that the spec should make this a requirement
> (MUST instead of SHOULD), and also ensure that the user does not need
> to try clicking on every element to find which have longdesc
> properties.

This is a compromise the group arrived at. There has been push in both the
direction of making it more of a requirement, and removing the requirement
altogether.

> Suggested wording, "User agents MUST enable users to discover when
> images in a page contain a long description without having to query
> each element individually.

While it is certainly true that querying each individual image is a
poor-quality implementation, we believe it does minimally satisfy the
critical requirement for users. We certainly encourage higher-quality
implementation strategies and better user experience to put users in a
more equal position with those who do not need the long description.

> A similar change should be made in the Requirements section where it
> currently says "A user SHOULD be able to determine that there is a
> description available for a given image." This should also be changed
> from SHOULD to MUST.

Same rationale applies.

> 3.  Provide UI guidance: The document should provide some guidance or
> examples of how user agents could implement linked images with
> longdesc. Section 3.0.3 says "If the longdesc value is valid, User
> agents must make the link available to all users through the regular
> user interface(s)." That's ambiguous as to whether it means "through
> the user agent's own UI (rather than relying on assistive technology)"
> or "through the user agent's normal clicks and keystrokes for
> activating links". It's clear that the user agent can't simply provide
> a single standard hyperlink when the img is inside an anchor and also
> contains a longdesc unless that pops up a choice of jumps, but it
> could instead append a separate hyperlink to the longdesc, or it could
> provide a separate command on the link's context menu and/or on a menu
> bar menu when the element has focus, etc. Of course, any guidance
> should be suggestions, rather than prescriptive, as we don't want to
> prevent user agent developers from providing new, innovative UI or UI
> that's appropriate for their product and its platform. We also
> recommend you explicitly state that the longdesc link be actionable
> rather than allowing the user agent to merely display the URI (as is
> done by Firefox's View Image Info command in the Context menu for an
> image.).

We avoided giving advice on implementation strategies. In part because
this has a history of going wrong: doing so lead us to a situation where
accesskey was effectively rendered unusable for over a decade, because
implementors followed a poor interpretation of the advice given, and in
part because we do not want developers to aim at the minimal possible
implementation but compete to provide the functionality better. Indeed,
our experience during the development of the specification was that we
continually learned of new and often better strategies.

> Editorial Comments:
>
> 1. Use Case keywords seem random: In the section on Use Cases, the
> Requires and Helped By keywords (which link to appropriate entries in
> "Requirements for an Image Description Functionality") are a nice
> touch. However, we don't understand the choices made as to which
> keywords are listed for each use case. For example, why would
> Discountability be important for "Identifying a well-known image", but
> not for "Describing a complex diagram", or why would Simple Return be
> useful for the latter but not the former?

We have made some editorial tweaks to the document and hope this has
clarified things.

> 2. Contrast with ARIA DescribedBy: The use case "Referring to an
> existing description" sounds like exactly what ARIA DescribedBy is
> used for, so it might be good to clarify why longdesc is also needed,
> and whether you're recommending one or both be used.

aria-describedBy must be used on the same page as the thing it describes.
Among other things, this means a single description at a given URI cannot
be re-used by multiple instances of the same image. This would fail to
meet the "Re-use" requirement, which is relied on by several use cases.

> 3. Delimit blocks in the document: As a purely editorial/formatting
> issue, the document should not convey information by using CSS :before
> pseudo elements or graphical formatting alone. The problem with
> :before is the content is not in the DOM and screenreaders don't see
> it. The problem with graphical formatting is that the blocks starting
> with "This section is informative" are indented and have a differently
> colored background, but there is nothing textual to denote where the
> block ends.

We have used HTML5 section elements and ARIA to delimit regions, and put
the content that was in :before pseudo elements into the document
directly. We hope this satisfies the requirement - if not, we could add
text at the end of each informative section.

> 4. Web page contains insecure content: FYI, when loading the page
> https://dvcs.w3.org/hg/html-proposals/raw-file/default/longdesc1/longdesc.html,
> Firefox 26.0 generates a warning saying "Firefox has blocked content
> that isn't secure. Most websites will still work properly even when
> this content is blocked." It links to the following page for details:
> https://support.mozilla.org/en-US/kb/how-does-content-isnt-secure-affect-my-safety.

Thanks. This has been fixed.

> 5. Under the requirement "Structured Markup" is "A user should be able
> to determine that there is a description available for a given image."
> This is not really related to structured markup, so should be under
> the requirement "Discoverability". We suggest moving "A user should be
> able to determine that there is a description available for a given
> image. " in the definition of Structured Markup to the definition

We have made edits to the use cases and requirements, to make them more
compehensive and comprehensible.

cheers

Chaals

-- 
Charles McCathie Nevile - web standards - CTO Office, Yandex
chaals@yandex-team.ru         Find more at http://yandex.com

Received on Friday, 13 June 2014 17:49:22 UTC