- From: Janina Sajka <janina@rednote.net>
- Date: Tue, 15 Dec 2009 00:34:38 +0000 (GMT)
- To: Doug Schepers <schepers@w3.org>
- CC: PFWG Public Comments <public-pfwg-comments@w3.org>
Dear Doug Schepers: 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 176: Conformance Targets? Date: 2009-04-18 Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0071.html Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 7. Conformance <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#conformance> Status: Accepted proposal ------------- Your comment: ------------- This document seems to contain conformance criteria for both User Agents and authors, but it is not always clear where particular statements are aimed, or if the statement is advisory or a conformance criterion. For example, this statement is in a section marked informative: [[ There should be an obvious, discoverable way, either through tabbing or other standard navigation techniques, for keyboard users to move the focus to any interactive element. ]] This could be interpreted several ways: [[ Authors should provide an obvious, discoverable way, either through tabbing or other standard navigation techniques, for keyboard users to move the focus to any interactive element. ]] [[ User Agents should provide an obvious, discoverable way, either through tabbing or other standard navigation techniques, for keyboard users to move the focus to any interactive element. ]] or even, informatively (though unlikely), [[ It is likely that there is an obvious, discoverable way, either through tabbing or other standard navigation techniques, for keyboard users to move the focus to any interactive element. ]] I suggest you clarify the spec by changing normative statements to have a specific conformance target, as in the wording examples above. Here's some specific instances where the meaning is ambiguous: [[ The following steps are recommended as ARIA is applied to content: ]] Should be: [[ Content authors should adhere to the following guidelines in applying ARIA to content: ]] -------------------------------- Response from the Working Group: -------------------------------- We have added a description of the various types of audience to whom the specification is of interest, and indicated for each conformance requirement to which audience it is targeted. ---------------------------------------------------------------------- Comment 177: Owned by Date: 2009-04-18 Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0071.html Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - aria-owns (property) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#aria-owns> Status: Alternate action taken ------------- Your comment: ------------- It seems peculiar to me that there is no corresponding aria-ownedby attribute. Maintaining (via script) a list of IDREFs in the aria-owns attribute seems like it would take more overhead than maintaining it on the individual elements that belong to the owner. Here's a variation on your example: <h3 id="header">Vegetables</h3> <ul role="list" aria-labelledby="header" aria-owns="asparagus artichoke arugula aubergene"> <li role="listitem">Carrot</li> <li role="listitem">Tomato</li> <li role="listitem">Lettuce</li> </ul> … <div role="listitem" id="asparagus">Asparagus</div> <div role="listitem" id="artichoke">Artichoke</div> <div role="listitem" id="arugula">Arugula</div> <div role="listitem" id="aubergene">Aubergene</div> If I were to dynamically add and remove a set of <div>s like that, I would have to also touch the DOM to get the current aria-owns value of the <ul>, parse the set of id-strings, and add or remove the relevant string. By contrast, if I had an aria-ownedby attribute, I could do this: <h3 id="header">Vegetables</h3> <ul id="veggies" role="list" aria-labelledby="header"> <li role="listitem">Carrot</li> <li role="listitem">Tomato</li> <li role="listitem">Lettuce</li> </ul> … <div role="listitem" aria-ownedby="veggies">Asparagus</div> <div role="listitem" aria-ownedby="veggies">Artichoke</div> <div role="listitem" aria-ownedby="veggies">Arugula</div> <div role="listitem" aria-ownedby="veggies">Aubergene</div> Creating or removing any given element takes care of the relationship maintenance, with less of a performance hit and less script to maintain. -------------------------------- Response from the Working Group: -------------------------------- Currently, user agents are required to compute the reverse relationship from the aria-owns property for assistive technologies. Due to user agent implementation issues that vary across operating system platforms that result in performance concerns we have opened an issue to consider introducing an aria-ownedby attribute that would be managed by the author in a future working draft. ---------------------------------------------------------------------- Comment 178: composite abstract role Date: 2009-04-18 Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0071.html Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - composite (abstract role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#composite> Status: Alternate action taken ------------- Your comment: ------------- The idea of composite widgets is in some ways more interesting than simple widgets like buttons or tree controls, because unlike those simpler roles, some more complex widget controls don't have HTML equivalents, and so authors are forced to improvise. You have some predefined composites, but how can an author roll their own? I'm thinking, for example, of a pivot table: http://en.wikipedia.org/wiki/Pivot_table I can see that being composed of a grid and a combobox or listbox, but showing a concrete example of just how one could do that would help in more complex authoring scenarios (which of course are the ones that would most need some accessibility help). Or maybe this is what is meant by a "treegrid"? If so, then another example of a common complex control widget could serve as an example? -------------------------------- Response from the Working Group: -------------------------------- We realize the need to have this capability, however this is out of scope for ARIA 1.0. We have an existing issue (Issue 9) "how to define custom roles" that has been deferred to ARIA 2.0. We have noted your response in that issue to be sure that you are included when it is addressed in ARIA 2.0. ---------------------------------------------------------------------- Comment 179: Columns Date: 2009-04-18 Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0071.html Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - row (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#row> Status: Alternate action taken ------------- Your comment: ------------- It's not clear to me why there shouldn't be a "column" role, when there is a "row" role. Sometimes data makes more sense organized into columns than into rows, especially when you take into account aria-sort. This may not be necessary for HTML, which already has tables, but for SVG, making accessible table-like widgets needs the full range of semantics. Here's an example of a document that could benefit from "column": http://www.svg-whiz.com/svg/tables/svg-table.svg -------------------------------- Response from the Working Group: -------------------------------- At this point in our requirements we have not had a need to allow restructuring of grids or treegrids to support columns. This would require us to allow for expandable columns as well as rows. If we were to have both row and column expansion capability, it would require a new set of WAI-ARIA properties to indicate that for a given cell you could expand the row and the column. This would also require an expansion in accessibility API support as well as a deeper look into key bindings. If your requirement is to just add a column to your grid, it is possible to have an aria-haspopup on any element, such as a columnheader, where the user could choose to expose a popup menu containing a menuitem to insert a new column. Due to the complexity of having bidirectional row/column expansion and navigation, from the perspective of users and accessibility APIs, we have an existing issue for ARIA 2.0 to investigate column expansion which shall include a discussion about rows and columns. This is in line with our efforts to address SVG accessibility in ARIA 2.0. ---------------------------------------------------------------------- Comment 180: "img" vs "image" Date: 2009-04-18 Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0071.html Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - img (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#img> Status: Alternate action taken ------------- Your comment: ------------- Why "img" and not "image"? "image" is a real word, much more descriptive than the HTML element name. -------------------------------- Response from the Working Group: -------------------------------- While we agree that "image" is a real word and more descriptive. We chose the role "img" as it was consistent with the img element with HTML which people were most familiar with. At this point "img" has extensive browser implementation support so we we will be keeping that name for the role. ---------------------------------------------------------------------- Comment 181: region example Date: 2009-04-18 Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0071.html Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - region (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#region> Status: Accepted proposal ------------- Your comment: ------------- This role really needs a simple example to remove some of the vagueness. -------------------------------- Response from the Working Group: -------------------------------- We have added the following text to the role to clarify it: <change> This role defines a group of elements that together form a large perceivable section that the author feels should be included in a summary of page features. </change> <to> This role defines a group of elements that together form a large perceivable section that the author feels should be included in a summary of page features, for example, an area of the page containing live sporting event statistics. A summary is a structure created dynamically from the page after it is loaded as a means of quickly describing its overall organization. It is created either by the author using a script, or by an AT. <to> ---------------------------------------------------------------------- Comment 182: Unbounded spinbuttons Date: 2009-04-18 Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0071.html Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - spinbutton (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#spinbutton> Status: Alternate action taken ------------- Your comment: ------------- Spinbuttons are also a good way to represent unbounded numerical values using a set format or increment, unlike sliders, which have a fixed range, and unlike text inputs, which don't limit format or establish increments. You could account for this by allowing the author to omit the aria-valuemax and/or aria-valuemin (as appropriate), like you do the aria-valuenow in the progress role. You may or may not want to have an aria-increment property (for this and "slider"), too. -------------------------------- Response from the Working Group: -------------------------------- This would be an approach to addressing numerical data without a fixed range. Unfortunately, today, platform accessibility APIs in general do not provide for an increment property. Microsoft Active accessibility provide a value property, however later generations of accessibility API are such that the assistive technology vendors depend on a maximum and minimum value. Consequently, if authors do not provide a maximum and minimum value the user agent will set them to zero. To address your concern we have created an ARIA 2.0 issue to address unbounded numerical values with author specified increments. ---------------------------------------------------------------------- Comment 183: Editable text Date: 2009-04-18 Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0071.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: Answered question ------------- Your comment: ------------- Would this apply to an ersatz html:textarea, as well as a text input? I guess this is the purpose of 'aria-multiline'? While SVG doesn't have an explicit textbox, SVG Tiny 1.2 does have an 'editable' attribute; is there a way to indicate that text with an 'editable' attribute is implicitly a "textbox"? -------------------------------- Response from the Working Group: -------------------------------- Yes the role of textbox would apply to html:textarea as well as text input. The aria-multiline attribute would apply to each. However, by using standard html elements the user agent would automatically provide the mapping to the accessibility API that would be provided by the ARIA properties you refer to. In referring to the SVG 1.2 tiny specification it would appear that you provide the editable property on both text and textarea. However, there is no way to state that text is indeed a textbox. You can achieve this by simply providing a role="textbox." As for textarea this is a clearly defined textbox area that is multiline. Your user agent would simply provide the platform equivalent of role of textbox and aria-multiline="true" which can be determined from the normative WAI-ARIA implementation guide. ---------------------------------------------------------------------- Comment 184: whitespace-delimited lists Date: 2009-04-18 Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0071.html Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 5.3. Values for States and Properties <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#state_prop_values> Status: Alternate action taken ------------- Your comment: ------------- You might consider allowing these lists to be whitespace-and/or-comma delimited, since it shouldn't cause problems (ids can't contain commas) and might be more intuitive for some authors. SVG is moving to this more forgiving delimiter syntax. -------------------------------- Response from the Working Group: -------------------------------- We have made ARIA attribute types abstract without inherent formats. Host languages would use corresponding types from that language for each ARIA type. In this way documents can use the syntax for token lists that is appropriate for the language of the document as a whole. If SVG supports commas as delimiters in token lists, ARIA attributes in SVG documents would inherit this capability. ---------------------------------------------------------------------- Comment 185: Mirror aria-describedby and aria-labelledby Date: 2009-04-18 Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0071.html Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - aria-describedby (property) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#aria-describedby> Status: Answered question ------------- Your comment: ------------- aria-describedby and aria-labelledby Why aren't there corresponding aria-describes and aria-labels, which could be IDREFS of multiple things they describe/label? -------------------------------- Response from the Working Group: -------------------------------- The reason for this is that if we were to provide for reciprocity the author has the opportunity to interject an error through a mismatch. Under the covers the user agent defines the reciprocity you suggest in their accessibility API mapping depending on the API used. This is covered in the WAI-ARIA Implementation Guide. We chose to define the "by" portion as the assistive technology would process this information when it processes the element being described or labeled. ---------------------------------------------------------------------- Comment 186: Coordinate with Clipboard APIs Date: 2009-04-18 Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0071.html Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 5.5.3. Drag-and-Drop Attributes <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#dragdrop> Status: Accepted proposal ------------- Your comment: ------------- aria-dropeffect, aria-grabbed This is related to the Clipboard APIs spec that the WebApps WG is (slowly) working on: http://www.w3.org/TR/clipboard-apis/ It seems that there should be some coordination here... -------------------------------- Response from the Working Group: -------------------------------- The specification you suggest is based on an events driven interface similar to HTML 5. Today, browser DOM interfaces do not provide vehicles to enumerate event handlers. This makes it near impossible to identify the state of draggable objects and drop targets which is the crux of the problem not addressed in the HTML 5 specification. The ARIA specification is designed to provide this information to assistive technologies in such a way as to provide this information to allow them to aid the user in the drag/drop decision making and on older versions of HTML and browsers. This can also be seen by our indication that aria-dropeffect also allows the author to tell the assistive technology that the target supports a popup window that would allow the user to choose among available drop effect options. Our solution is designed to not impact the use the API suggested by the Clipboard API and HTML 5 specification that support standardized drag/drop eventing. What we do see is inconsistencies in the values of aria-dropeffect and the HTML 5/Clipboard API dropeffect. We shall rename the aria-dropeffect value of reference to link (to be consistent with HTML 5) and recommend that HTML 5 and the WebApps WG address the issue of execution on a drop which they do not today. Finally, clipboard operations were not addressed in ARIA 1.0. We shall address them in ARIA 2.0. This is our ISSUE-388. ---------------------------------------------------------------------- Comment 187: Conformance requirements for Authoring Tools Date: 2009-04-18 Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0071.html Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 7. Conformance <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#conformance> Status: Accepted proposal ------------- Your comment: ------------- The spec provides no normative conformance criteria for authoring tools. Therefore, no authoring tool can claim conformance to ARIA, and there is less incentive to do so; it may be a selling point, for example, to development shops seeking to comply with Section 508. I suggest that specific criteria be developed for Authoring Tools; for example, it could be integrated into the sections discussing authoring guidelines and steps. -------------------------------- Response from the Working Group: -------------------------------- We have added a description of the various types of audience to whom the specification is of interest, and indicated for each conformance requirement to which audience it is targeted. However, we are not adding requirements specifically for authoring tools because they would be redundant with the requirements of Authoring Tools Accessibility Guidelines. ---------------------------------------------------------------------- Comment 188: Mutation Events Date: 2009-04-18 Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0071.html Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 7.3. Web Application Notification of DOM Changes <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#ua_domchanges> Status: Accepted proposal ------------- Your comment: ------------- You call out mutation events as a means of are particularly inefficient, and may not be interoperably implemented. There is some desire by browser vendors to remove or change mutation events. Introducing a dedicated ARIA-specific equivalent method might be better, because it would require fewer events being fired, and they would always be relevant to AT. Would you be interested in exploring this? -------------------------------- Response from the Working Group: -------------------------------- Same as comment 24. ---------------------------------------------------------------------- Comment 189: Implicit structural relationship? Date: 2009-04-18 Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0071.html Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 <http://www.w3.org/TR/2009/WD-wai-aria-20090224/> Status: Answered question ------------- Your comment: ------------- How can SVG indicate, in ARIA/AT terms, that an element's child <title> and <desc> elements implicitly serve the equivalent role of aria-labelledby and aria-describedby for the element, without explicitly marking them up as such (which is redundant). -------------------------------- Response from the Working Group: -------------------------------- aria-labelledby is used when an object visibly labels another object such as when an author creates a label for a text field. The label is not part of the same document element. It is separate. In the case of svg, <title> is an attribute and would be used as part of the text equivalency calculation for determining the name of the element similar to the title attribute in HTML. This is addressed by 2E of the Text Equiv Computation in IMPLEMENTATION. "…if the native markup provides a text equivalent, append it to the text equivalent. An example of a native markup text equivalent is alt for HTML <img> or a label from <label for>." aria-describedby shows a relationship between an element and the element that describes it. When mapping this information to platform accessibility APIs it can be exposed to an assistive technology as additional non-visible help information or as a relationship to the visible prose that describes the object in the document. In HTML, the text can be made non-visible and in this scenario it would be mapped to the non-visible help information. This is equivalent to what you would do with the <description> attribute and you would recommend authors use a declarative technique in SVG to provide the help information. Non-visible help information is very useful to describe the purpose of widgets in the context of web applications or even basic form controls. Yet, unlike with aria-describedby, SVG does not provide a vehicle to relate visible prose to an object. In this case you would recommend that authors use aria-describedby to relate the two elements. ---------------------------------------------------------------------- Comment 190: Define Accessible Name Date: 2009-04-18 Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0071.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: Accepted proposal ------------- Your comment: ------------- Please provide a link to the definition of "accessible name" in the first instance of use (section 4.2.7. Accessible Name Calculation). Also, please give an example in the definition of what an accessible name is, and maybe how an AT user would use it. -------------------------------- Response from the Working Group: -------------------------------- There is actually a link to the accessible name definition but due to a styling error it did not show up properly. That has been corrected. We have now included an OK button example in the accessible name definition. ---------------------------------------------------------------------- Comment 191: Move glossary Date: 2009-04-18 Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0071.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: Accepted proposal ------------- Your comment: ------------- I would recommend placing the glossary in the front of the spec, since it contains definitions critical to understanding concepts in the specification itself, and it's relatively short. Please link at least the first instance (and preferably every instance) of a term to its glossary definition. -------------------------------- Response from the Working Group: -------------------------------- We have moved the glossary to the beginning of the non-introductory content of the spec. ---------------------------------------------------------------------- Comment 192: Typos Date: 2009-04-18 Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0071.html Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 <http://www.w3.org/TR/2009/WD-wai-aria-20090224/> Status: Accepted proposal ------------- Your comment: ------------- "attributes that change with user actions" -> "Attributes that change with user actions" "a grid and gridcell elements" -> "the grid and gridcell elements" -------------------------------- Response from the Working Group: -------------------------------- We have fixed these. ---------------------------------------------------------------------- Comment 193: Declarative models Date: 2009-04-18 Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0071.html Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 <http://www.w3.org/TR/2009/WD-wai-aria-20090224/> Status: Accepted proposal ------------- Your comment: ------------- As a point of reference for declarative models, if you haven't looked at SCXML or SMIL state, you might be interested in it. -------------------------------- Response from the Working Group: -------------------------------- Thank you. We will suggest that the WAI-PF working group consider looking at SCXML and SMIL state for ARIA 2.0 when discussing custom widgets support.
Received on Tuesday, 15 December 2009 00:34:49 UTC