W3C home > Mailing lists > Public > public-pfwg-comments@w3.org > April to June 2009

Comments on WAI-ARIA Role, from a WebApps and SVG Perspective

From: Doug Schepers <schepers@w3.org>
Date: Sat, 18 Apr 2009 05:20:45 -0400
Message-ID: <49E99B6D.8040908@w3.org>
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:

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>
<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>
<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:

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?

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":

Why "img" and not "image"? "image" is a real word, much more descriptive 
than the HTML element name.

This role really needs a simple example to remove some of the vagueness.

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.

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:

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.

"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.

-Doug Schepers
W3C Team Contact, SVG and WebApps WGs
Received on Saturday, 18 April 2009 09:20:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:45:57 UTC