- From: Janina Sajka <janina@rednote.net>
- Date: Tue, 15 Dec 2009 00:34:28 +0000 (GMT)
- To: Todd Kloots <kloots@yahoo-inc.com>
- CC: PFWG Public Comments <public-pfwg-comments@w3.org>
Dear Todd Kloots:
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 161: The "activedescendant" attribute
Date: 2009-04-17
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0067.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - aria-activedescendant (property) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#aria-activedescendant>
Status: Alternate action taken
-------------
Your comment:
-------------
- I don't understand the need for this attribute and think that it should
be
deprecated. Use of the "Roving TabIndex Technique" as a means of
managing a widget's active descendant is a much better backward and
forward
compatible solution. I wrote up a blog entry on this topic back in Feb.,
you can find my arguments against the "activedescendant" attribute here:
http://yuiblog.com/blog/2009/02/23/managing-focus/
--------------------------------
Response from the Working Group:
--------------------------------
We understand your point regarding the roaming tab index being supported by
today's user agents now and for the forseeable future. Consequently, our
best practices guide recommends that authors use the roaming tabindex
technique until future browsers are able to support aria-activedescendant.
At this point our views deviate. What your argument does not address is the
amount of effort required to have the author support the roaming tabindex,
the platform accessibility infrastructures available, the emerging browser
support, and how desktop application authors manage large amounts of data
in large lists and spreadsheets.
Let's start with the roaming tabindex. Every time one navigates a complex
container, like a grid, one has to have a keyboard handler, for arrow keys,
which actively resets the tabindex to -1 on the one to lose focus, setting
it to zero on the one to receive focus and then setting the focus on the
new element. With aria-activedescendant you need only set the id of the
child element you want to receive focus. The browser fires the focus change
event on your behalf. Also, we are unconvinced that the use of default
renderings for tabindex will be adequate. When creating these complex UI
elements it is more than likely that special styling will be required.
Also, since aria-acttivedescendant stores the last known id to have focus
allowing the author to not be concerned with which element to is receive
focus when you leave the component and return.
Next, there is the platform accessibility API support. Both UNIX and
Windows platforms (IAccessible2) support an activedescendant property. This
feature works and is used extensively by desktop applications.
aria-activedescendant is also, now, implemented in IE 8, FF 3 on Windows,
and FF 3 on Linux and Solaris.
Furthermore, activedescendant was designed to model how application
developers build large components that manage large amounts of data. In
particular, spreadsheet application developers treat each cell as a
lightweight component to be managed by the container. aria-activedescendant
is consistent with that developer mentality.
It should be noted that some host languages don't have a tabindex
attribute available. Therefore, the aria-activedescendant may be the only
approach authors can use in those languages.
In conclusion, we believe that just because you can do something in the
browser today does not mean it is the only way to do it nor does it mean it
is the right way. If that were the case we would never have driven browser
manufacturers to make the changes to tabindex, now used in the roaming
tabindex, nor would we have created ARIA. For the points stated we will not
be removing aria-activedescendant. Meanwhile web authors may continue to
use the roaming tabindex technique if they so choose.
A point you raise that would make things even better would be to define a
CSS pseudo class that could show visual indication of focus on HTML
elements identified by the aria-activedescendant property. This would make
it much easier for the developer to render focus. We shall pursue a new
pseudo class to do this with the CSS working group.
----------------------------------------------------------------------
Comment 162: Typo "Specialize Regions"
Date: 2009-04-17
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0067.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 4.3. Categorization of Roles <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#roles_categorization>
Status: Accepted proposal
-------------
Your comment:
-------------
- Currently there is a typo in the list that introduces the six categories.
The item labeled "Specialize Regions" should be "Application Structure"
--------------------------------
Response from the Working Group:
--------------------------------
This is indeed a typo that we will fix.
----------------------------------------------------------------------
Comment 163: Simplify role categorization
Date: 2009-04-17
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0067.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 4.3. Categorization of Roles <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#roles_categorization>
Status: Alternate action taken
-------------
Your comment:
-------------
- I think that the current categorization of ARIA roles could be further
simplified, and as a result, improved. My suggestions are to:
1. Kill the "Application Structure" category and combine what is
currently
"User Input Widgets," "User Interface Elements," and
"Application Structure" into a single category called "Widgets".
2. Pull the "application" role from the "Landmark Roles" category and
create a new category called "Specialized Regions" that includes just
the roles of "document" and "application"--since these two roles are
truly "special" in that the set/control the overall context the user
is working in. They're also "special" in that they can be used to
control weather or not a screen reader's virtual buffer is toggled
on or off.
This would leave five categories of ARIA roles:
1. Base Types
2. Widgets
3. Document Structure
4. Landmark Roles
5. Specialized Regions
--------------------------------
Response from the Working Group:
--------------------------------
{Response from comment 119}
----------------------------------------------------------------------
Comment 164: Remove roles
Date: 2009-04-17
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0067.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 4.3. Categorization of Roles <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#roles_categorization>
Status: Alternate action taken
-------------
Your comment:
-------------
- There are a handful of ARIA roles that I believe should be either removed
or deprecated, as they duplicate rather than supplement native language
semantics. The roles I would remove or deprecate are:
- img
- separator
- heading
- link
- list
- listitem
** The removal of these roles is important considering that their
presence
seems to contradict the intend use of ARIA as mentioned in section
1.2 of the specification titled "Use Cases" which says: "ARIA is
intended to be used as a supplement for native language semantics,
not a replacement"
--------------------------------
Response from the Working Group:
--------------------------------
WAI-ARIA is indeed intended to be used as a supplement to the native host
language and not a replacement, meaning we would prefer the author use the
native host language constructs. That said, we also believe that if the
author feels they must not use the standard host language constructs that
they can still produce an equally accessible web page. Where we have found
use cases for these instances we have provided roles.
All of the roles have explicit use cases and needs for these roles and we
have decided to keep these in our specification. Let us share with you our
reasoning.
role="img": There are situations where authors aggregate multiple images
to form a single image. For this reason we have created the role of img to
encompass the aggregated image. The HTML specification does not provide for
this.
role="separator": Although host languages, like HTML provide a form of
separator such as <br> it is too restrictive. The role of "separator" is
found in drop down menus which have separators between groups of menu items
in a menu (Pull down the browser file menu). Also, split panes have a
separator in between which can be used to adjust the size of the panes on
each side. One javascript toolkit uses the role of "separator" on this
object. No such construct is provided in HTML.
role="heading" We are aware of instances of customers not wanting to be
restricted to using HTML header tags to provide headers. This allows the
author to semantically provide the equivalent by supplementing the host
language. When using "heading", additionally aria-level may be applied
indicating the heading nesting level when HTML header tags "Hx" is not
used.
role="link": Like heading, we agree that we would prefer to have the
author use the host language markup, yet we feel the notion of a link is
critical to our taxonomy - especially when you consider the role attribute
to be intended to be a cross-cutting specification. We have found instances
in which it is desirable to remove links from the tab order. While this
can be done using tabindex=-1 in HTML, the link role is another solution to
this problem.
role="list", and listitem: Like heading and link, we agree that we would
prefer to have the author use the host language markup, yet we feel the
notion of a list and listitem are critical to our taxonomy - especially
when you consider the role attribute to be intended to be a cross-cutting
specification. For example, SVG does not have list and listitem structural
constructs. Finally, as in the case of headings it is entirely possible for
the author to avoid standard HTML constructs and while we do not endorse it
this provides a vehicle to still be interoperable with assistive
technologies. What we did uncover, in response to your review, was a
duplication of functionality between an option and a listitem. We are
therefore changing the definition of a listitem:
<change>
A single item in a list, listbox, or directory.
</change>
<to>
A single item in a list or directory.
</to>
We shall also add aria-posinset and aria-setsize as properties of the
option role. Although this was supported in one implementation it was not
reflected in the specification.
----------------------------------------------------------------------
Comment 165: Recategorization proposal
Date: 2009-04-17
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0067.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 4.3. Categorization of Roles <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#roles_categorization>
Status: Alternate action taken
-------------
Your comment:
-------------
- With all of the above changes in place, this is how I would see the
breakout of the individual roles:
- Base Types (unchanged)
- Widgets
- checkbox
- combobox
- input (abstract role)
- listbox
- option
- radio
- radiogroup
- range (abstract role)
- select (abstract role)
- slider
- spinbutton
- textbox
- button
- menu
- menubar
- menuitem
- menuitemcheckbox
- menuitemradio
- tablist
- tabpanel
- tab
- toolbar
- tooltip
- tree
- treegrid
- treeitem
- alert
- alertdialog
- dialog
- log
- marquee
- progressbar
- status
- timer
- Document Structure
- article
- columnheader
- definition
- directory
- grid
- gridcell
- group
- math
- note
- presentation
- region
- row
- rowheader
- section (abstract role)
- sectionhead (abstract role)
- Landmark Roles
- banner
- complementary
- contentinfo
- main
- navigation
- search
- Specialized Regions
- application
- document
--------------------------------
Response from the Working Group:
--------------------------------
We agree with your point about separating input widgets and user interface
elements is confusing and requires simplification. We also agree with
another comment that separating out abstract roles and base types is a bit
confusing and that adding a base type (a categorization of some abstract
classes) creates more confusion.
What we do feel is important is to ensure there is an understanding of
which widgets convey structure. Regarding the application role, the group
resolved, a while back, to have the application role be included in the
list of landmarks.
This is also reflected in the WAI-ARIA Best Practices Guide.
So we will be adopting a hybrid of your proposal, as shown at
http://www.w3.org/WAI/PF/aria/20091214/roles#roles_categorization.
Received on Tuesday, 15 December 2009 00:34:39 UTC