- From: Janina Sajka <janina@rednote.net>
- Date: Wed, 18 May 2011 15:40:06 -0400
- To: HTML Accessibility Task Force <public-html-a11y@w3.org>
As I objected to Silvia's comments being posted under the "Second Call" thread, I'm reposting her comments with an amended subject. While it's important to keep the "Second Call" thread on topic, Silvia's comments are also eminently worthy of proper consideration. So, I don't want them to get lost among my procedural concerns. Janina Silvia Pfeiffer writes: Hi Janina & Laura, I've read the change proposal and the suggested text change. I've still got some (late) feedback, sorry. === I am very concerned about the suggested spec text as per http://www.d.umn.edu/~lcarlson/research/ld-spec-text2.html. I'm therefore providing comments on it where I have marked the original text with ">": First paragraph: -- > Some images benefit from a long text alternative that is either too long to be > included in the main flow of the document or requires structured markup that > cannot be included in an alt attribute. Such a long text alternative of the image, > if it has one, may be referenced in the longdesc attribute. This feels like you are arguing for the attribute to exist. A spec is not the right place to argue for an attribute. Rather, the attribute should be introduced and then you should provide example situations for its use. Thus, this paragraph should not be the first one, but come after the introduction of the attribute, which happens in the next paragraph. We can also make it more concise about what the advantage of this attribute is. For example: "Web developers are encouraged to use this attribute for images that contain complex content that is too long to describe in the alt attribute and where there is no description available in the main flow of the document. It is particularly useful in situations where a text description of an image is best described through structured markup, such as for tables." Second paragraph: -- > A longdesc attribute may be present. s/A/The/ - it's not an indetermined attribute, but the one listed above under "content attributes". > This attribute specifies a link to a long description of the image. s/specifies/contains/ - there is no specification of a link here, but the content is a link. > If present, it must contain a valid URL potentially surrounded by spaces. s/a valid URL/a valid non-empty URL/ - an empty @longdesc is not of much use. Third paragraph: -- > To obtain the corresponding long text alternative link, the value of the attribute > must be resolved relative to the element. The link must point to either a > different document from the image or a fragment of the same document that > does not contain the image. OK. > User agents should allow users to access long > text alternatives in a device independent manner. I think this could be more prescriptive about exposing it to all users. For example: "The user agent should expose the longdesc link to all users in a device independent manner, but not interfering with the page's normal rendering. Rendering examples are listed in the <a href="[link to section 10.6.1]">rendering section</a>." Last paragrph: > The longdesc IDL attribute must reflect the element's longdesc content attribute. OK. We could also add an additional paragraph that could make it more interesting for Web developers to add a longdesc page and that is just a note in green: "Note: The long description can for example be made available through a separate Web page that contains the long description of the image among other information about the image, such as publication date, license and copyright information, as well as a thumbnail of the image itself. If such a page is used, the longdesc URL needs to contain a fragment address to the particular section on that page that contains the long description. This page would then be reused for all occurrences of the image on the Website." === I've also found some other issues: 1. http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/Implementation In the section "Recent research on browsers", the text "Opera, Firefox, Chromium, and Internet Explorer all support longdesc DOM reflection." has a dangling pointer. 2. http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/Implementation In the section "Recent research on browsers", the text "iCab has native support for longdesc" could be supplemented with a description for how the browser exposes it, namely "- the longdesc is exposed by changing the mouse cursor icon" 3. http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/AlternativesAreNotViableSolutions Remove the following quote: ""Authoring tool vendors are likely to find it difficult (or even impossible) to build user-friendly interfaces that use the aria-describedby feature. This is likely to result in confusion and little use of the feature." - Vlad Alexander, XStandard authoring tool vendor, April, 20, 2011. " since it is a criticism on aria-describedby and contributes nothing to the discussion about @longdesc. It indicates that we should remove @aria-describedby from common use and deprecate it, which is not our intention with this change proposal. 4. http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/AlternativesAreNotViableSolutions Remove the following: "aria-describedby is not native HTML." since it is a criticism on aria-describedby and contributes nothing to the discussion about @longdesc. It just deepens the divide between accessibility work and the HTML WG. 5. http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/AlternativesAreNotViableSolutions Remove the following everywhere where it is copied: "Protocols and Formats Working Group (PFWG) "likes the idea of having built in semantics in HTML and in particular would prefer to have common document elements." " since it contributes nothing to the discussion about @longdesc and is a call for authority, that will just make conversation more difficult. (Also remove it from http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/Conclusion - the statement provides nothing of technical interest) 6. http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/AlternativesAreNotViableSolutions Remove the following quote: "It is unlikely that many content creators or developers will learn ARIA (something not native HTML). They already feel like they've learned far more than they should have to know under their job description. And in many cases, their supervisors agree. (reference Cliff Tyllick) " since we are not trying to remove ARIA from HTML, but are just trying to re-instate @longdesc. Don't make life for ARIA even more difficult by contributing to its criticism. 7. http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/AlternativesAreNotViableSolutions Remove the following: "aria-describedat is not native HTML. " since this statement has no technical value and sheds again a bad light on ARIA. 8. http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/AlternativesAreNotViableSolutions Remove the following: "It is unlikely that many content creators or developers will learn anything with an ARIA prefix. They already feel like they've learned far more than they should have to know under their job description. And in many cases, their supervisors agree. (reference Cliff Tyllick) " since again this is a criticism of ARIA that is not called for when discussing the technical merits of @longdesc. 9. http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/AlternativesAreNotViableSolutions Remove the following: "The <canvas src> proposal implies that the problem with longdesc is copy/paste errors. It is not. Some browser vendors have a problem in not affording users the option of accessing longdesc content. This could be corrected if they followed User Agent Accessibility Guidelines. " since there is no technical argument and since slashing out at browser vendors is not constructive. 10. http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/AlternativesAreNotViableSolutions You could add to the argument against image maps that: * overloading the mechanism of image maps with that of providing long text alternatives clashes in the case that you need both, image maps and a long text alternative * for a long text alternative provided through a link in an image map to be exposed to AT programmatically would require a special marking on one area, such as a @longdesc boolean attribute 11. http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/AlternativesAreNotViableSolutions Remove the following from the image map section: "Obsolescing longdesc breaks backwards compatibility for numerous company, organizational, governmental, educational, and personal sites throughout the world. Obsolescing longdesc would cause confusion and result in mixed messages between existing Guidelines, Laws, Policy, and Standards and HTML5. " since these arguments have nothing to contribute against the choice of image maps, but are general issues with making longdesc obsolete. These arguments are already used in the section on a new attribute and are ok there. 12.http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/Conclusion Remove the following: "A HTML attribute is easier to teach. Many content creators and developers will not learn ARIA. " since again this is a criticism of ARIA that is not called for when discussing the technical merits of @longdesc. Removing those arguments will make the case stronger, not weaker - it's not quantity that counts, but quality of the argument. == Hope this helps. Cheers, Silvia. -- Janina Sajka, Phone: +1.443.300.2200 sip:janina@asterisk.rednote.net hair, Open Accessibility janina@a11y.org Linux Foundation http://a11y.org Chair, Protocols & Formats Web Accessibility Initiative http://www.w3.org/wai/pf World Wide Web Consortium (W3C)
Received on Wednesday, 18 May 2011 19:40:32 UTC