- From: Michael Cooper <cooper@w3.org>
- Date: Thu, 02 Dec 2010 22:27:09 +0000
- To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- CC: PFWG Public Comments <public-pfwg-comments@w3.org>
Dear Benjamin Hawkes-Lewis: Thank you for your comments on the 15 December 2009 Working Draft of Accessible Rich Internet Applications (WAI-ARIA) 1.0 (http://www.w3.org/TR/2009/WD-wai-aria-20091215/). 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=6; * 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 332: Clarify whether presentational children contribute to text equivalents Date: 2010-09-12 Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2010JulSep/0049.html Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 5.2.7. Accessible Name Calculation <http://www.w3.org/TR/2009/WD-wai-aria-20091215/#namecalculation> Status: Accepted proposal ------------- Your comment: ------------- Please clarify whether presentational children contribute to text equivalent calculation. In particular, does role="presentation" affect "host language … mechanisms" for associating labels with elements? For example, given this markup: <div role="button"><img role="presentation" alt="Edit" src="pencil.png"></div> Should the accessible name of the button be "Edit" or ""? See also the discussion in this thread on public-html-a11y: http://lists.w3.org/Archives/Public/public-html-a11y/2010Sep/0349.html -------------------------------- Response from the Working Group: -------------------------------- In the presentation role, a normative requirement already mentioned that this would flag an author warning, "Authors SHOULD NOT provide meaningful alternative text (for example, use alt="" in HTML4) when the presentation role is applied to an image. For clarification of user agent implementation requirements, we have incorporated that rule into the text alternative computation. Rule 2A bullet 3 now states: "If aria-labelledby and aria-label are both empty or undefined, and if the element is not marked as presentational (role="presentation"), check for the presence of an equivalent host language attribute…" We are coordinating with accessibility test tool manufacturers to ensure that when authors apply a role of "presentation" to images having non-empty alternative text a warning is generated to web authors. ---------------------------------------------------------------------- Comment 333: Clarify whether how CSS replaced content would be included/excluded in accessible text determination Date: 2010-09-13 Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2010JulSep/0051.html Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 5.2.7. Accessible Name Calculation <http://www.w3.org/TR/2009/WD-wai-aria-20091215/#namecalculation> Status: Answered question ------------- Your comment: ------------- ARIA's accessible text determination method includes CSS generated content: "because it is possible to specify textual content using the CSS :before and :after pseudo-elements, it is necessary for user agents to combine such content with the text referenced by the text nodes to produce a complete text alternative." Currently, web developers use hacks to replace text with CSS added content, such as moving text off-screen and putting a background image in its. While these hacks do have negative accessibility impacts, they do not affect the accessible text calculations. CSS3 Working Drafts proposes new features for replacing content with CSS: * http://www.w3.org/TR/css3-content/#inserting3 * http://www.w3.org/TR/css3-ui/#element Here's some discussions of how web developers might want to use these features to replace their current hacks: * http://www.css3.info/image-replacement-in-css3/ * http://my.opera.com/ODIN/blog/css-3-image-replacement * http://css-discuss.incutio.com/wiki/Image_Replacement * http://dev.opera.com/articles/view/css-generated-content-techniques/ These have some experimental implementations. Both Opera and WebKit will replace content with images, and Opera will also replace content with text. So how does this affect accessible text determinations? Currently, Opera exposes original text *and* new text when text is replaced with text, but exposes nothing when images are replaced. Likewise WebKit exposes nothing when text is replaced with an image. It would be good for ARIA to take a stand on this. Should new text added with such features be included in accessible text determinations? I'm guessing, by the current spec text by analogy with :before and :after, it should be? But then should original text replaced with such features be included in accessible text determinations? If original text is not included in accessible text determinations, then accessibility-aware developers will need to continue to use either "img" (with its costs to performance and skin-ability) or their existing hacks (with their costs to accessibility). If original text and new text are both included which should go first when the accessible text is concatenated? -------------------------------- Response from the Working Group: -------------------------------- The :before and :after CSS textual content rules are handled by requiring the UA to include the 'before' and/or 'after' text when computing the text alternative. This reflects a general rule, namely, that the UA "knows" what the relevant text is. The new CSS content rules provide additional ways to alter how text content is rendered. These include: - image replaces text. - text replaces image. - (new) text replaces (old) text. > It would be good for ARIA to take a stand on this. We agree. - when an image replaces text, then the UA should use the original text, since that text is presumably the equivalent. - when text replaces an image, then the UA should provide that text. - when new text replaces old, then the UA should include the new text, since that is what is rendered on screen. Aside: There is a potential problem with an image replacing text where the original text is the meaningless "put image #1 here". In this case, we would recommend using more descriptive text. Compare this situation with the recommendation that an author not use something like "image #1" for @alt text. > Should new text added with such features be included in accessible text > determinations? I'm guessing, by the current spec text by analogy with :before > and :after, it should be? Yes, but the wording should be done with care. These new CSS content rules are part of a working draft, and are not standard. The ARIA specification ought to reference other specifications that are settled, or nearly so. In addition, future versions of CSS might include even more content rules that ARIA cannot anticipate. It is ultimately up to a group working on CSS to define the accessibility API mapping of that information when applied to a host language. With that mind, we propose to add a general statement about CSS content rules to the text computation algorithm. ---------------------------------------------------------------------- Comment 334: Media types and CSS generated content in accessible text determination Date: 2010-09-13 Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2010JulSep/0052.html Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 5.2.7. Accessible Name Calculation <http://www.w3.org/TR/2009/WD-wai-aria-20091215/#namecalculation> Status: Alternate action taken ------------- Your comment: ------------- ARIA's accessible text determination method includes CSS generated content: "because it is possible to specify textual content using the CSS :before and :after pseudo-elements, it is necessary for user agents to combine such content with the text referenced by the text nodes to produce a complete text alternative." When UAs are generated accessible text, should they only include CSS generated content from the media type they are rendering (typically "screen") and ignore CSS generated content for other modalities that might be relevant to AT (such as the CSS 2.1 "speech" and "braille" types, or the proposed "reader" media type). If so, it would be good to make that explicit. It might be a good idea to have UAs expose multiple sets of accessible text, as calculated for different media types, /if/ this wouldn't impose an unacceptable performance cost on UAs and accessibility platforms would allow that. That way AT could takes its pick. -------------------------------- Response from the Working Group: -------------------------------- Alternative modalities beyond screen are not in scope of ARIA 1.0. We have created an issue to address this topic in a future version of ARIA. This is our issue 425 http://www.w3.org/WAI/PF/Group/track/issues/425.
Received on Thursday, 2 December 2010 22:27:14 UTC