- From: Doug Schepers <schepers@w3.org>
- Date: Sat, 18 Apr 2009 05:20:45 -0400
- To: public-pfwg-comments@w3.org, "wai-xtech@w3.org" <wai-xtech@w3.org>
Hi, WAI-farers- First, I want to reiterate my support for WAI-ARIA, and the SVG WG looks forward to integrating WAI-ARIA more directly. I have reviewed the WAI-ARIA 1.0 spec <http://www.w3.org/TR/2009/WD-wai-aria-20090224/>, and have a few comments. Some of these comments are general, and some are from the SVG and WebApps WG perspectives; while I did speak to some WebApps and SVG WG participants about ARIA, these comments aren't necessarily comprehensive or representative of all those participants. Sorry these final comments come so late. As a high-level note, the SVG WG is interested in writing a set of ARIA extensions specifically for diagrams, maps, charts, and other explorable data visualizations, so we are interested in the extension mechanisms you touch on in ARIA 1.0. We look forward to talking to you more about this in the future. ============= Conformance Targets? 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: ]] ============= aria-owns 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. ============= composite abstract role 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? ============= Columns 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 ============= "img" Why "img" and not "image"? "image" is a real word, much more descriptive than the HTML element name. ============= region This role really needs a simple example to remove some of the vagueness. ============= spinbutton 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. ============= textbox 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"? ============= whitespace-delimited lists 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. ============= 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? ============= 5.5.3. Drag-and-Drop Attributes 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... ============= Authoring Tools 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. ============= Mutation Events 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? ============= Structural relationship? 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). ============= Accessible Name 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. ============= Glossary (suggestion) 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. ============= Typos: "attributes that change with user actions" -> "Attributes that change with user actions" "a grid and gridcell elements" -> "the grid and gridcell elements" ============= As a point of reference for declarative models, if you haven't looked at SCXML or SMIL state, you might be interested in it. Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Received on Saturday, 18 April 2009 09:20:55 UTC