- From: Michael Cooper <cooper@w3.org>
- Date: Thu, 02 Dec 2010 22:26:46 +0000
- To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- CC: PFWG Public Comments <public-pfwg-comments@w3.org>
Dear Leif Halvard Silli: Thank you for your comments on the 16 September 2010 Last Call Working Draft of Accessible Rich Internet Applications (WAI-ARIA) 1.0 (http://www.w3.org/TR/2010/WD-wai-aria-20100916/). The Protocols and Formats Working Group has reviewed all comments received on the draft. We would like to know whether we have understood your comments correctly and whether you are satisfied with our resolutions. Please review our resolutions for the following comments, and reply to us by 9 December 2010 to say whether you accept them or to discuss additional concerns you have with our response. If we do not hear from you by that date, we will mark your comment as "no response" and close it. If you need more time to consider your acknowledgement, please let us know. You can respond in the following ways: * If you have a W3C account, we request that you respond online at http://www.w3.org/WAI/PF/comments/acknowledge?document_version_id=9; * Else, by email to public-pfwg-comments@w3.org (be sure to reference our comment ID so we can track your response). Note that this list is publicly archived. Please see below for the text of comments that you submitted and our resolutions to your comments. Each comment includes a link to the archived copy of your original comment on http://lists.w3.org/Archives/Public/public-pfwg-comments/, and may also include links to the relevant changes in the Accessible Rich Internet Applications (WAI-ARIA) 1.0 editors' draft at http://www.w3.org/WAI/PF/aria/20101202/. Note that if you still strongly disagree with our resolution on an issue, you have the opportunity to file a formal objection (according to 3.3.2 of the W3C Process, at http://www.w3.org/2005/10/Process-20051014/policies.html#WGArchiveMinorityViews) to public-pfwg-comments@w3.org. Formal objections will be reviewed during the candidate recommendation transition meeting with the W3C Director, unless we can come to agreement with you on a resolution in advance of the meeting. Thank you for your time reviewing and sending comments. Though we cannot always do exactly what each commenter requests, all of the comments are valuable to the development of Accessible Rich Internet Applications (WAI-ARIA) 1.0. Regards, Janina Sajka, PFWG Chair Michael Cooper, PFWG Staff Contact Comment 335: @longdesc implemented as ARIA construct Date: 2010-09-15 Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2010JulSep/0053.html Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - img (role) <http://www.w3.org/TR/2010/WD-wai-aria-20100916/#img> Status: Alternate action taken ------------- Your comment: ------------- I hereby formally propose that role="img" permits a long description link inside. That is: there should be some way to make sure that a long description link inside a role="img" element, is presented to AT users as a link. One motiviation for this request is to allow @longdesc be implemented as a normal link. And I hope ARIA will explain how AT which already support @longdesc should treat @longdesc when they see a parallel long description link. (They should probably ignore the @longdesc and use the long description link instead.) Currently, ARIA requires AT to treat children of role="img" elements as presentational. And, even if you point to a link inside the role="img" elment via aria-labelledby, the link is only presented as a text string, without link features. The method I would propose is that the first link with a rel="longdesc" or aria-longdesc="true" attribute inside the role="img" element, is treated as a long description link and presented to the user user as a link. This idea was first described in the following letters, which I recommend to read for more detail: http://lists.w3.org/Archives/Public/wai-xtech/2010Sep/0030 http://lists.w3.org/Archives/Public/wai-xtech/2010Sep/0031 http://lists.w3.org/Archives/Public/public-html-a11y/2010Sep/0429 http://lists.w3.org/Archives/Public/wai-xtech/2010Sep/0033 -------------------------------- Response from the Working Group: -------------------------------- ARIA today supports an aria-describedby by property intended for longer descriptions. The reason for this is platform accessibility APIs support short names (labels), descriptions descriptions, and relationships to long descriptions. Today, aria-describedby supports an id value as it was intended that the description relationship reference prose on the page that would also be readily available to users with cognitive impairments. Rather than introduce another attribute for longdesc the group has agreed to consider extending aria-describedby to also support a URL. We have opened ISSUE-411 to track this. If longdesc is removed from HTML 5 we will push for a fast track ARIA specification enhancement that expands aria-describedby to support this new feature. ---------------------------------------------------------------------- Comment 336: Give @alt is not given due consideration in ARIA Date: 2010-09-16 Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2010JulSep/0055.html Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 5.2.7. Accessible Name Calculation <http://www.w3.org/TR/2010/WD-wai-aria-20100916/#namecalculation> Status: Alternate action taken ------------- Your comment: ------------- These are some comments to the status of @alt inside ARIA 1.0 as per 31 of Agust 2010's working draft, http://www.w3.org/WAI/PF/aria/complete Please *do* read my message to wai-xtech as well: http://lists.w3.org/Archives/Public/wai-xtech/2010Sep/0018 I will not repeat all that is said there, here. I will however rephrase the summary of that letter, as follows (mostly identical). Please note that my main focus is on how @aria-label, @aria-labelledby and @alt works on the <img> element. Howeer, as I wrote al this, I also tested role="img" on other elements, so it is not without relevance for other elements than <img>. 1) GENERAL. @alt is under-mentioned and under-specced in ARIA. The underspecification of @alt has lead to differing implementations. Bad for authors and users! Examples if the lack of attention to @alt: #namecalculation Section 5.2.7 on the accessible name calculation algorithm mentions many attributes as example of "author" values - amongst them it mentions HTML @title, @aria-label and @aria-labelledby. But it does *not* mention @alt, which is the most important author provided content of HTML4 ... #aria-label Likewise, when it comes to the definition of @aria-label, then @title is mentioned as its HTML parallel. Does that mean that @aria-label is not need in HTML, since it has @title? Isn't @alt a more natural parallel? #textalternativecomputation Going back to the section 5.2.7, then @title is only mentioned at step 2D, after the text node content has been considered. How can @aria-label, with it high priority, be considered similar to the low priority @title attribute? Please rather compare aria-label with @alt. #textalternativecomputation @alt is mentioned under the last list item of step 2A, and the text says that aria-labelledby if present should have highest priority, then comes aria-label if present and finally @alt if present. In practise, for <img>, then ARIA supporting ATs first considers the role of element. In most AT, the default role of <img> is affected not only by the presence of @role but also of whether @alt is empty or none empty. * Thus, in practise, many AT consider if @alt is empty or non-empty first, * if non-empty then they prioritize aria-label - if present, else they prioritize @alt's content. * If @alt was emtpy, then they may not consider whether @aria-label nor @aria-labelledby (AT differ on this) * but if @role="img" is present and alt is empty, *then* and only do they look at @aria-labelledby Thus, it is all very convoluted. 2) What is supposed to happen if aria-labelledby points to an element whose only content is located inside @alt, @title or @aria-label? AT differ in what they do: OSX10.5's VoiceOver and Jaws11+Firefox consider @alt as the content, Jaws12+Firefox consider aria-label as the content, NVDA consider both. I don't see where in the spec this explained. (I think most authors will expect that aria-label points to an element whose text node contetn will be used.) It is clear that author provided values, such as aria-labelledby, has priority over the element's own content text node. The question is what if @aria-labelledby points to an element whose content author content only, or a mix of author content and text node content? 3) ATs generally give @alt higher priority than ARIA says, and most of them ignore @labelledby if @alt is non-empty. 4) For <img>, then ATs in practise links a double meaning to the empty @alt: aria-labelledby generally only work as expected when the @alt is the empty string. At the same time HTML5 says that empty @alt means role="presentation". 5) A consequence of the fact that aria-labelledby is ignored when @alt is non-empty (see 3) and 4) above) is that it is impossible to get an aria-labbelledby which points to <img> itself (<img id=A alt=FOO aria-labelledby="A B">) to work, despite that ARIA says it should work. (This might work better for <div role="img"> tha for <img role="img"> - please check.) 6) The algorithm doesn't say what role it plays that the @alt is or isn't the empty string. Which is just an example of how ARIA doesn't incorporate the semantics @alt. But while ARIA doesn't take it in, it is clear that AT in various degrees take it in. E.g consider the convoluted way AT prioritize between @alt, @aria-label and @aria-labelledby. (I don't claim that AT do it correct and tha ARIA do it wrong - proably both AT and ARIA need fixing ...) A really important point to me is that AT should see the @alt as the content of <img>. Perhaps ARIA should consider @alt more like text node content than author content? Or, when I think about it: perhaps, that is what you do - and perhaps that's the problem! Because, for other elements, it doesn't matter for the element's semantics whether it is empty or non-empty. Whereas for <img>, the <img alt=""> and <img alt="non-empty"> are considered different beasts. Sorry, a convoluted response to a convoluted problem. -------------------------------- Response from the Working Group: -------------------------------- We have modified section 5.2.7 to bullet 1. "values" to include the alt attribute such that it is on par with aria labeling. Thank you for identifying this omission. You should note, however, that alt is referenced in bullet 2A in the name computation putting it on equal footing with aria. To address your question regarding equivalence between aria-label and title, title is not equivalent as user agents use the title attribute to generate tool tips during a hover. This is not the behavior desired in most rich internet applications. For example, you would not want a menuitem in a menu to generate a tooltip. You would also not want to have to use a labelledby relationship in all instances as it requires a separate element reference to the label. It is for these use cases that we have aria-label to be used to fulfill the accessible name computation in accessibility API supported by user agents. Certainly, if you have an image with an alt attribute the accessible name can be computed by the alt text. The name computation does not preclude this. We would like to point out that the specification does not place title at a higher priority or on parallel with aria-label and aria-labelledby. In fact, in section 2A under name computation it recommends the use of @alt when aria-label and aria-labelledby are not present. It also references the appropriate sections in both HTML 4 and 5 for as to what is used for alternative text. Consequently, we agree that @title should not be given equal rating to @alt and @title is really the last resort for computing alt text when all other mechanisms fail. However, we do believe the specification addresses this. Regarding your point about ATs preference of computing alt as a label mechanism, we prescribe what a user agent is to do to compute the accessible name of an element. Firefox, does compute the name with precedence given to aria-labelledby over alt. If an AT uses the @alt attribute, over aria-labelledby, it would need to circumvent the accessibility mapping as defined in ARIA and may need to access the DOM directly to get it. We have found that AT vendors often do not always follow industry specifications and we do not control how an AT renders ARIA content. VoiceOver reads the aria labelledby with the alt text treating both alt and labelledby equally. JAWS incorrectly reads the alt text and ignores the labelledby reference. We have raised this issue with Freedom Scientific and they agreed this is a problem. ATK and IAccessible2 provide an aria-labelledby relationship. In that instance the alt text is stored in the accessible name and the label is referenced in the relationship. The implementation varies based on the accessibility API used and the AT. Our specification does not state how an assistive technology is to process an accessibility.
Received on Thursday, 2 December 2010 22:26:50 UTC