- From: Janina Sajka <janina@rednote.net>
- Date: Tue, 15 Dec 2009 00:34:15 +0000 (GMT)
- To: Erik Dahlström <ed@opera.com>
- CC: PFWG Public Comments <public-pfwg-comments@w3.org>
Dear Erik Dahlström: Thank you for your comments on the 24 February 2009 Last Call Working Draft of Accessible Rich Internet Applications (WAI-ARIA) 1.0 (http://www.w3.org/TR/2009/WD-wai-aria-20090224/). 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 1 February 2010 to say whether you accept them or to discuss additional concerns you have with our response. 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=1; * 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/20091214/. Due to the scope of changes made in response to comments on the Last Call Working Draft of WAI-ARIA, we are returning the specification to Working Draft status. We will shortly publish a public "stabilization draft" of WAI-ARIA and updated Working Drafts of the accompanying documents. While these versions will not incorporate further discussion based on your acknowledgement of our response to your comments, we will work with you on your feedback as part of our preparation for the following version. You are also welcome to submit new comments on the new public versions in addition to sending your acknowledgement of our response to your previous comments. 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 91: SVG focus Date: 2009-04-16 Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0062.html Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 2.3. Managing Focus <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#managingfocus> Status: Accepted proposal ------------- Your comment: ------------- == 2.3. Managing Focus Doesn't mention svg navigation, http://www.w3.org/TR/SVGTiny12/interact.html#navigation, the nav-* attributes especially. SVG doesn't have the 'taborder' attribute. Please clarify how it relates to the svg nav-* attributes. -------------------------------- Response from the Working Group: -------------------------------- We will address your comment but not in detail. HTML was used as it is the most popular host language that people are familiar with. It is outside the scope of our document to list every possible host language and how they implement keyboard focus. For example, WAI-ARIA could also be implemented in Adobe Flex. We have looked at SVG and it allows the author to manipulate the navigation order also. Consequently, we shall make the following change to this section that you supported on the joint WAI-ARIA/SVG call on July, 10, 2009: <change> When using standard (X)HTML and basic WAI-ARIA widgets, application developers can simply manipulate the tab order or use a script to create keyboard shortcuts to elements in the document. Use of more complex widgets requires the author to manage focus within them. </change> <to> When using standard (X)HTML and basic WAI-ARIA widgets, application developers can simply manipulate the tab order or use a script to create keyboard shortcuts to elements in the document. Use of more complex widgets requires the author to manage focus within them. SVG Tiny provides a similar navigation "ring" mechanism that by default follows document order and which should be implemented using system dependent input facilities (the TAB key on most desktop computers). SVG authors may place elements in the navigation order by manipulating the <a href="http://www.w3.org/TR/SVGTiny12/interact.html#FocusableAttribute">focusable</a> property and they may dynamically <a href="http://www.w3.org/TR/SVGTiny12/interact.html#specifyingnavigation">specify the navigation order</a> by modifying elements <a href="http://www.w3.org/TR/SVGTiny12/intro.html#TermNavigationAttribute">navigation attributes</a>. </to> ---------------------------------------------------------------------- Comment 92: Include xlink:title Date: 2009-04-16 Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0062.html Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 4.2.7. Accessible Name Calculation <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#nameref> Status: Alternate action taken ------------- Your comment: ------------- == 4.2.7. Accessible Name Calculation For 'author': Should mention the 'xlink:title' attribute, which can be used on anchor tags in SVG. -------------------------------- Response from the Working Group: -------------------------------- The browser implementations of WAI-ARIA, today, have been limited to HTML and XHTML 1.X. Consequently, we will not have an SVG implementation of WAI-ARIA at the time we go to recommendation. Introducing partial, untested solutions now would do SVG an injustice. Therefore, we are limiting API computation references to HTML and XHTML for WAI-ARIA 1.0. The group has raised an issue (http://www.w3.org/WAI/PF/Group/track/issues/338) to address the use of SVG xlink:title attribute in the Accessible Name computation for WAI-ARIA 2.0. We have also created an issue (http://www.w3.org/WAI/PF/Group/track/issues/339) to create an SVG ARIA implementation guide for ARIA 2.0 We look forward to working with the SVG working group. ---------------------------------------------------------------------- Comment 93: Scrollbar role Date: 2009-04-16 Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0062.html Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 4.3.3. User Interface Elements <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#ui> Status: Accepted proposal ------------- Your comment: ------------- == 4.3.3. User Interface Elements It's not uncommon to have scrollbars in an application, why isn't that particular UI element listed here? Is the idea that one has to use multiple buttons instead for this use-case or is there another role defined somewhere for this purpose? slider? -------------------------------- Response from the Working Group: -------------------------------- Per our joint meeting with the SVG working group on July 10, 2009 we have agreed to add a scrollbar role and an aria-orientation property to reflect the orientation of the scrollbar. ---------------------------------------------------------------------- Comment 94: Nav related concept Date: 2009-04-16 Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0062.html Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - navigation (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#navigation> Status: Accepted proposal ------------- Your comment: ------------- == http://www.w3.org/TR/2009/WD-wai-aria-20090224/#navigation Isn't <nav> from HTML5 a related concept here? -------------------------------- Response from the Working Group: -------------------------------- We have added a related concept to the nav element of HTML 5. ---------------------------------------------------------------------- Comment 95: SVG text input Date: 2009-04-16 Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0062.html Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - textbox (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#textbox> Status: Accepted proposal ------------- Your comment: ------------- == http://www.w3.org/TR/2009/WD-wai-aria-20090224/#textbox The statement about SVG not having a text input element isn't fully accurate. SVG Tiny 1.2 does have text input support. Any text content block element (http://www.w3.org/TR/SVGMobile12/intro.html#TermTextContentBlockElement) can accept text input when editable="simple" is specified. Please correct the erroneous statement. -------------------------------- Response from the Working Group: -------------------------------- Per the July 10, 2009 joint discussion with the SVG working group we agreed that although text input support was not provided in SVG 1.0, it was in SVG Tiny 1.2. Consequently, in an effort to be more forward thinking we have removed the reference to SVG not having support for a text input. ---------------------------------------------------------------------- Comment 96: SVG text equivalent calculation Date: 2009-04-16 Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0062.html Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 4.2.7.3. Text Equivalent Computation <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#textequivalentcomputation> Status: Proposal not accepted ------------- Your comment: ------------- == http://www.w3.org/TR/2009/WD-wai-aria-20090224/#textequivalentcomputation Rule 2C will not work for the following (simplified) example: <svg> <text id="t" display="none">mylabel</text> <text><tref xlink:href="#t"></text> </svg> The behaviour is that tref points to some text, and the textcontent itself isn't a descendant of tref.parentNode and concatenating won't return anything at all even though "mylabel" is what a user would see on screen. For reference http://www.w3.org/TR/SVG11/text.html#TRefElement. I think it might make more sense for these cases to talk about rendered text (or refer to what's in the rendered tree, http://www.w3.org/TR/SVGTiny12/intro.html#TermRenderingTree). There are other cases too, like a textPath that has text that would go off either end of the defined path (such characters are not rendered), and when elements with display="none" are descendants of a visible element. Note however that visibility="hidden" still means elements are in the rendertree, even though they're not actually visible on screen. So another term may need to be defined for what I think is the purpose of this, which is to get the text that a user would see on screen. -------------------------------- Response from the Working Group: -------------------------------- Following our discussion with you, we will address text equivalents in SVG in ARIA 2. We have created an issue in our tracker for this. ---------------------------------------------------------------------- Comment 97: SVG title Date: 2009-04-16 Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0062.html Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - application (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#application> Status: Accepted proposal ------------- Your comment: ------------- == http://www.w3.org/TR/2009/WD-wai-aria-20090224/#application == http://www.w3.org/TR/2009/WD-wai-aria-20090224/#document Should mention <svg:title> as equivalent to <html:title> for the purposes of labelling the application/document. Possibly with fallback to <svg:desc> for a longer description. -------------------------------- Response from the Working Group: -------------------------------- Given that we have not completed a full ARIA implementation for SVG we have decided to limit our reference to the use of <svg:title> to labelling the entire svg document whether it be an application or document. Application (role) is a navigational landmark and many users will want to see the label when navigating to it. That does not mean it has to be visible all the time. In future work with the SVG working group, on ARIA support, we might consider vehicles for having the title temporarily rendered when navigating to the landmark. We do understand that SVG should be treated somewhat differently from HTML as the focus is the graphics and that title rendering should be limited to "as needed." We have created an issue for ARIA 2.0 to further examine how navigational landmarks labeling should be supported with SVG. With regards to <svg:desc>, this is used for a long description intended for additional help information. <svg:desc> was namespace referenced in ODF to provide additional help information about drawing objects. For these reasons it is not intended to be used as a label. Platform accessibility API, like MSAA and ATK/ATSPI provide an interface to get access to this additional help information in a consistent way. For this reason SVG should also be consistent with its use of <svg:desc>. ---------------------------------------------------------------------- Comment 98: Landmark confusing Date: 2009-04-16 Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0062.html Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - landmark (abstract role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#landmark> Status: Proposal not accepted ------------- Your comment: ------------- == http://www.w3.org/TR/2009/WD-wai-aria-20090224/#landmark 'landmark' is a common cartography term, and so would make sense to use in an SVG mapping context. Would it be possible to use another name for this abstract role, or to allow it for maps? -------------------------------- Response from the Working Group: -------------------------------- The definition of landmark is really based on the the context which it operates in. See http://wordnetweb.princeton.edu/perl/webwn?s=landmark >From an accessibility perspective we view this as a navigational landmark which is very abstract and which could be adapted for different contexts. At this point the notion of a landmark is very well known within WAI-ARIA and while it is abstract changing it now would require a lot of discussion by a number of parties. That said, WAI-ARIA is a taxonomy that is extensible. There is no reason, for SVG that we could not subclass it to say a cartographylandmark or some abridged version of it. We then have the option of creating cartography specific landmarks that are commonly used. In fact, these are the types of discussions we should have with the SVG working group when we work on WAI-ARIA 2.0. The groups agrees it will retain its definition of landmark and address the SVG issues in WAI-ARIA 2.0. We will also create an issue to address cartographical landmarks in WAI-ARIA 2.0. ---------------------------------------------------------------------- Comment 99: SVG shadow trees Date: 2009-04-16 Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0062.html Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 9.2. Glossary <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#Terms> Status: Alternate action taken ------------- Your comment: ------------- == http://www.w3.org/TR/2009/WD-wai-aria-20090224/#def_owned_element What about SVG shadowtrees? For reference http://www.w3.org/TR/SVG11/struct.html#UseElement and http://www.w3.org/TR/SVG11/struct.html#InterfaceSVGElementInstance. The SVGElementInstances don't have the DOM Node interface, so depending on what is meant with DOM descendants they're either covered or not. This should be clarified. -------------------------------- Response from the Working Group: -------------------------------- Per our joint discussions with the SVG working group, we have agreed that full ARIA support for SVG would be addressed in ARIA 2.0. Consequently, we have created an ARIA 2.0 issue to address the effect of SVG shadow trees on the ARIA implementation for conveying document structure to assistive technologies. ---------------------------------------------------------------------- Comment 100: Multiple applications Date: 2009-04-16 Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0062.html Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - application (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#application> Status: Alternate action taken ------------- Your comment: ------------- == http://www.w3.org/TR/2009/WD-wai-aria-20090224/#application > An author should set the role of application on the element that encompasses the entire application. If the application consists of multiple independent applications, what's the recommendation? Set role=application on each of them? For SVG images, sometimes scripting is disabled (depending on how you reference the image) and so it can sometimes be an application and sometimes a resource (say for example a static image). What's the recommendation in such cases? It may not be possible to alter the DOM, or to have an aria- attribute that describes each (re)use. -------------------------------- Response from the Working Group: -------------------------------- Yes, if content contains multiple applications you would assign role="application" to each. To date ARIA neither addresses the effects of scripting turned off or on in the browser. This may require additional properties in both ARIA and the platform accessibility API. We have created an issue to address this in ARIA 2.0
Received on Tuesday, 15 December 2009 00:34:18 UTC