- From: Janina Sajka <janina@rednote.net>
- Date: Tue, 26 Feb 2013 14:58:06 +0000
- 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 16 September 2010 Working Draft of
WAI-ARIA 1.0 Authoring Practices
(http://www.w3.org/TR/2010/WD-wai-aria-practices-20100916/). 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 8 March 2013 to say whether you accept them or to discuss additional
concerns you have with our response. If we do not hear from you by that
date, we will mark your comment as "no response" and close it. If you need
more time to consider your acknowledgement, please let us know. 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=10;
* 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 WAI-ARIA 1.0 Authoring
Practices editors' draft at http://www.w3.org/WAI/PF/aria-practices/.
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 with the
Director before the document is finalized as a Working Group Note, 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 WAI-ARIA 1.0 Authoring Practices.
Regards,
Janina Sajka, PFWG Chair
Michael Cooper, PFWG Staff Contact
Comment 343: Toolbar example incorrect
Date: 2010-10-28
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2010OctDec/0013.html
Relates to: WAI-ARIA 1.0 Authoring Practices - 2. General Steps for Building an Accessible Widget with WAI-ARIA <http://www.w3.org/TR/2010/WD-wai-aria-practices-20100916/#accessiblewidget>
Status: Alternate action taken
-------------
Your comment:
-------------
In the first section titled "General Steps for Building an Accessible
Widget with WAI-ARIA" there is sample toolbar markup which sets the
tabindex of the toolbar to 0, and the tabindex of the first button to 0 as
well. Assuming this is an example of using the roving tabindex technique,
the toolbar shouldn't have a tabindex set, right? It should just be the
first descendant. Additionally, the copy below the HTML example says "By
avoiding tabindex on the toolbar and setting tabindex=0 on the first
button...". So based on that it seems like the tabindex on the toolbar
should be removed.
<div role="toolbar" tabindex="0" id="customToolbar"
onkeydown="return optionKeyEvent(event);"
onkeypress="return optionKeyEvent(event);"
onblur="hideFocus()"
onfocus="showFocus()"
>
<img src="img/btn1.gif" tabindex="0" title="Home"
role="button" id="b1" alt="Home"
onClick="updateText('Home was invoked');">
<img src="img/btn2.gif" tabindex="-1" title="Refresh"
role="button" id="b2" alt="Refresh"
onClick="updateText('Refresh was invoked');">
<img src="img/btn3.gif" tabindex="-1" title="Help"
role="button" id="b3" alt="Help"
onClick="updateText('Help was invoked');">
</div>
--------------------------------
Response from the Working Group:
--------------------------------
There are two techniques for keyboard navigation. One uses the
aria-activedescendant property while the other employs a roving focus. The
example you cite is using both, which is incorrect. The rest of the
section builds on the example, and uses aria-activedescendant throughout.
We have therefore modified the example to be consistent with the active
descendant technique, and amended the text to reflect that.
Thanks for catching this error.
----------------------------------------------------------------------
Comment 344: Avoid inline event listeners in examples
Date: 2010-10-28
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2010OctDec/0013.html
Relates to: WAI-ARIA 1.0 Authoring Practices - 2. General Steps for Building an Accessible Widget with WAI-ARIA <http://www.w3.org/TR/2010/WD-wai-aria-practices-20100916/#accessiblewidget>
Status: Accepted proposal
-------------
Your comment:
-------------
It'd be nice if the example didn't make use of inline JavaScript event
listeners as that is not a best practice. Can't we just update the example
so that it binds the listeners completely via JavaScript? For example:
<div role="toolbar" tabindex="0" aria-activedescendant="button1" id="tb1">
<img src="buttoncut.png" alt="cut" role="button" id="button1">
<img src="buttoncopy.png" alt="copy" role="button" id="button2">
<img src="buttonpaste.png" alt="paste" role="button" id="button3">
</div>
<script>
...
(function () {
function optionKeyEvent(event)
var event = window.event || event;
{
var tb = event.target;
var buttonid;
DOM_VK_ENTER = 13;
// Partial sample code for processing arrow keys
if (event.type == "keydown") {
if (event.altKey) {
return true; // Browser should use this, the menu view
doesn't need alt-modified keys
}
// XXX Implement circular keyboard navigation within the
toolbar buttons
if (event.keyCode == DOM_VK_ENTER) {
ExecuteButtonAction(getCurrentButtonID()); // This is an
author defined function
}
else if (event.keyCode == event.DOM_VK_RIGHT) {
// Change the active toolbar button to the one to the right
(circular) by
var buttonid = getNextButtonID(); // This is an author
defined function
tb.setAttribute("aria-activedescendant", buttonid);
}
else if (event.keyCode == event.DOM_VK_LEFT) {
// Change the active toolbar button to the one to the left
(circular) by
var buttonid = getPrevButtonID(); // This is an author
defined function
tb.setAttribute("aria-activedescendant", buttonid);
}
else {
return true;
}
return false;
}
else if (event.type == "keypress") {
...
}
}
var toolbar = document.getElementById("tb1");
toolbar.onkeydown = optionKeyEvent;
toolbar.onkeypress = optionKeyEvent;
}());
</script>
--------------------------------
Response from the Working Group:
--------------------------------
We agree with your comment. We have changed the examples to use DOM Level 1
JavaScript assignment (instead of inline assignment), and have added the
following note to the introductory section:
Note: Most of the JavaScript examples are written to be understandable by
all readers, including novice and intermediate JavaScripters. For example,
most modern rich web applications use DOM Level 2 event listener assignment
now, but some source code examples in this document use DOM Level 1
assignment (e.g. <code>el.onclick = foo;</code> or <code><el
onclick="foo()"></code>) because it is easier for all readers to
understand. Expert JavaScripters are encouraged to use modern JavaScript
best practices when developing accessible rich internet applications.
----------------------------------------------------------------------
Comment 345: Tabindex in Webkit
Date: 2010-10-28
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2010OctDec/0013.html
Relates to: WAI-ARIA 1.0 Authoring Practices - 3.2.1. Using Tabindex to Manage Focus among Widgets <http://www.w3.org/TR/2010/WD-wai-aria-practices-20100916/#focus_tabindex>
Status: Accepted proposal
-------------
Your comment:
-------------
Section 3.2.1 mentions that the tabindex property was originally
implemented in IE, but has now been implemented in Opera, Firefox, and
Mozilla. You've left out Webkit/Safari - which has had support for
tabindex on all elements since Safari 4.
--------------------------------
Response from the Working Group:
--------------------------------
Yes, thank you for picking that up. We have replaced Mozilla with Safari in
the list. The implementation on all elements is indicated in the first
sentence of the paragraph and Safari was indeed modified to be consistent
with the IE implementation as were the other browses.
----------------------------------------------------------------------
Comment 346: DOM activeElement now supported
Date: 2010-10-28
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2010OctDec/0013.html
Relates to: WAI-ARIA 1.0 Authoring Practices - 3.2.1. Using Tabindex to Manage Focus among Widgets <http://www.w3.org/TR/2010/WD-wai-aria-practices-20100916/#focus_tabindex>
Status: Accepted proposal
-------------
Your comment:
-------------
It states that "currently there is no standard DOM interface to get the
current element with keyboard focus". From my experience that is no longer
the case. All of the modern browsers now support IE's "activeElement"
interface on the Document object - a property that is now in HTML5.
--------------------------------
Response from the Working Group:
--------------------------------
We have modified the authoring practices to reflect that these events would
be used to monitor changes and that this document object function is now
available. We see this function was recently added to Safari 4 and a recent
version of Opera. It is also in Firefox.
----------------------------------------------------------------------
Comment 347: Reinforce native semantics principle
Date: 2010-10-28
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2010OctDec/0013.html
Relates to: WAI-ARIA 1.0 Authoring Practices - 3.2.7.3.1. Header Levels Versus Nesting Levels <http://www.w3.org/TR/2010/WD-wai-aria-practices-20100916/#kbd_layout_nesting_vs_level>
Status: Accepted proposal
-------------
Your comment:
-------------
Section 3.2.7.3.1 has an example of labeling a landmark with its
corresponding header element. It'd be nice if this example illustrated
this using an HTML header element rather than the header role to
re-inforce the best practice of using existing semantics of the host
language when they are provided. So, this:
<div role="main" aria-labelledby="hdr1">
<h1 id="hdr1" aria-level="1">Top News Stories</h1>
</div>
Rather than this:
<p role="main" aria-labelledby="hdr1">
<div role="header" id="hdr1" aria-level="1">Top News Stories</div>
</p>
--------------------------------
Response from the Working Group:
--------------------------------
We have made the change minus the aria-level property as it is already
implied by <h1>
Received on Tuesday, 26 February 2013 14:58:07 UTC