- From: <bugzilla@jessica.w3.org>
- Date: Fri, 13 Jun 2014 17:22:32 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26086 Bug ID: 26086 Summary: UAWG comments on the HTML5 Image Description Extension Product: HTML WG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: HTML Image Description Extension Assignee: chaals@yandex-team.ru Reporter: mark@w3.org QA Contact: public-html-bugzilla@w3.org CC: public-html-admin@w3.org Originally filed by Jim Allen on behalf of UAWG: http://lists.w3.org/Archives/Public/public-html-a11y/2014Jan/0068.html 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. 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. 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. 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. 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.). 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? 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. 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. 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. 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 Thank-you User Agent Working Group Jim Allan, Kelly Ford Co-Chairs Jeanne Spellman, Team Contact -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Friday, 13 June 2014 17:22:34 UTC