- From: Janina Sajka <janina@rednote.net>
- Date: Tue, 15 Dec 2009 00:31:12 +0000 (GMT)
- To: Loretta Guarino Reid <lorettaguarino@google.com>
- CC: PFWG Public Comments <public-pfwg-comments@w3.org>
Dear Loretta Guarino Reid:
Thank you for your comments on the 24 February 2009 Working Draft of
WAI-ARIA 1.0 Authoring Practices
(http://www.w3.org/TR/2009/WD-wai-aria-practices-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=2;
* 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/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 WAI-ARIA 1.0 Authoring Practices.
Regards,
Janina Sajka, PFWG Chair
Michael Cooper, PFWG Staff Contact
Comment 211: Example for external long description
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0064.html
Relates to: WAI-ARIA 1.0 Authoring Practices <http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/>
Status: Proposal not accepted
-------------
Your comment:
-------------
We suggest including an example to cover the use case where an author may
not want to include the long description on the same page. (ex. a complex
chart where a describedby attribute points to an id on the page which
contains a link to a second resource containing the complete description).
--------------------------------
Response from the Working Group:
--------------------------------
WAI-ARIA does not provide for long description references outside the page.
We have not found longdesc to be supported by industry due to the extensive
work needed to create the alternative content. Also, it forces people to go
to another page and lose context. Consequently, WAI-ARIA only supports an
ID reference for local descriptive text. This does not preclude authors
from using external long descriptions instead when supported by the host
language; it is simply a semantic that ARIA does not add to host languages.
Authors can also provide a link to a description via an in-page anchor.
----------------------------------------------------------------------
Comment 212: Problems with example
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0064.html
Relates to: WAI-ARIA 1.0 Authoring Practices - 2. General Steps for Building an Accessible Widget with ARIA <http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#accessiblewidget>
Status: Alternate action taken
-------------
Your comment:
-------------
There are a number of problems with the Step 2 example:
* It seems unrelated to the other code examples in this section.
* It uses tabindex instead of activedescendant. Code for the first
button in the toolbar has tabindex="0" whereas description below states
that the first button has tabindex="1".
* Regarding setting a tabindex value of -1 so that the toolbar will
receive focus in the document order: a negative tabindex value will remove
the item from the tab order; a value of "0" is required for the item to
fall into the default tab order.
* Why does the example include multiselectable="false" ? Since this is
the default value, the property isn't needed. If it is useful to keep this
for demonstration purposes, a comment should mention that it is redundant.
--------------------------------
Response from the Working Group:
--------------------------------
> * It seems unrelated to the other code examples in this section.
The example fits well to the Step 2 text above. No action needed here.
Other issues:
tabindex and multiselectable isues will be corrected. Thanks for input.
----------------------------------------------------------------------
Comment 213: Need alt
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0064.html
Relates to: WAI-ARIA 1.0 Authoring Practices - 2. General Steps for Building an Accessible Widget with ARIA <http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#accessiblewidget>
Status: Accepted proposal
-------------
Your comment:
-------------
Steps 3-5: Please add alt attributes to the img elements in the example
code.
--------------------------------
Response from the Working Group:
--------------------------------
We shall make the changes.
----------------------------------------------------------------------
Comment 214: Explain how focus indicated
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0064.html
Relates to: WAI-ARIA 1.0 Authoring Practices - 2. General Steps for Building an Accessible Widget with ARIA <http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#accessiblewidget>
Status: Accepted proposal
-------------
Your comment:
-------------
Step 9: "It also ensures that visual focus is indicated when the element
receives focus." - We don't understand how this follows from setting the
alt attribute.
--------------------------------
Response from the Working Group:
--------------------------------
This is an error. This text shall be deleted.
----------------------------------------------------------------------
Comment 215: Don't bring up tooltips on focus
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0064.html
Relates to: WAI-ARIA 1.0 Authoring Practices - 3.2.5.1. Supporting Tooltips with the Keyboard <http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#kbd_tooltips>
Status: Alternate action taken
-------------
Your comment:
-------------
See Comment 42 on the WAI-ARIA spec on this topic. We believe that
automatically bringing up tooltips on focus is often bad design that will
create an unpleasant experience for keyboard users. A keyboard command
should request that the tooltip be displayed. (It would also be possible to
introduce a delay before bringing up the tooltip, as happens with hover,
but this makes perhaps unwarranted assumptions about the manual dexterity
of the keyboard user.)
--------------------------------
Response from the Working Group:
--------------------------------
After discussion it has been concluded that the display of tooltips on
focus is preferrable to their display being dependent on a user action. For
mouse users the display of tooltips is based on incidental behaviour, they
do not have to 'query' an element to find out if the element has an
associated tooltip. If the tooltip behaviour for keyboard diverges from
this incidental behaviour model, there is an undue burden on the user to
query each element that he/she thinks may have an associated tooltip. Your
suggestion that a delay is placed on the display of tooltips that appear on
focus is agreed and the specification will be modified to reflect this.
----------------------------------------------------------------------
Comment 216: Clarify presentation role effects
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0064.html
Relates to: WAI-ARIA 1.0 Authoring Practices - 3.2.6.4.1.1. Use of the Presentation Role versus CSS <http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#kbd_layout_impact_mode_css2>
Status: Alternate action taken
-------------
Your comment:
-------------
It is clear that the element with attribute presentation is removed from
the accessibility hierarchy. However, this section implies, for a table,
that the table substructure elements will also be removed. How does an
author or user agent implementor know which additional subelements elements
are also covered by a presentation attribute? If a ul or ol element is
given role presentation, are its children li elements also removed? Or are
all descendent elements removed (but not their contents)? What if a layout
table contains important structural markup within its table cells? The spec
needs to be clearer about the meaning of role presentation.
--------------------------------
Response from the Working Group:
--------------------------------
We agree that the WAI-ARIA Specification itself was unclear regarding the
role of presentation. The description in the specification itself has
received extensive edits such that this content in the BPG is now
redundant.
----------------------------------------------------------------------
Comment 217: group vs row
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0064.html
Relates to: WAI-ARIA 1.0 Authoring Practices - 3.2.6.4.2. Groups and Their Applicability <http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#kbd_layout_whatgroup>
Status: Accepted proposal
-------------
Your comment:
-------------
The first example in the discussion of the group role is a row in a grid.
Does this imply that group could/should be used instead of row within a
grid? Are group and row equivalent roles within grids?
--------------------------------
Response from the Working Group:
--------------------------------
No, role is a subclass of group in the taxonomy meaning it is a form of
group. As such, it is listed here for groups. The specification states that
row is a required child of a grid. This not to state that a group could not
be used in a gridcell such as for a collection of radio buttons.
Since this is not clear we will make clarify that a row is a specialized
group representing a row in a grid.
----------------------------------------------------------------------
Comment 218: Focusable grid cells
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0064.html
Relates to: WAI-ARIA 1.0 Authoring Practices - 3.2.6.5.1. Tabular Structure-Related Roles Supporting Tabular Widgets <http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#kbd_layout_remaining_tabular>
Status: Accepted proposal
-------------
Your comment:
-------------
"Gridcells are focusable within a grid unlike a table." Does this mean that
the author is (always) responsible for making them focusable, via tabindex
or aria-activedescendant? or can the author assume that the user agent will
make them focusable? We have similar questions about expanding and
collapsing rows.
--------------------------------
Response from the Working Group:
--------------------------------
We agree that it is helpful to add this direction to a gridcell and have
added similar text to your comment in the Best Practices Guide.
----------------------------------------------------------------------
Comment 219: Is alt text part of the text?
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0064.html
Relates to: WAI-ARIA 1.0 Authoring Practices - 5.2.1. Live Region Properties and How to Use Them <http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#liveprops>
Status: Accepted proposal
-------------
Your comment:
-------------
aria-relevant='text' "Textual content includes text equivalents, such as
the alt attribute of images." This seems different from the interpretation
given for role=presentation, where alt attributes of images are not
considered text content (hence not exposed). Please be consistent about
whether alt text is considered the text of an element or not.
--------------------------------
Response from the Working Group:
--------------------------------
Yes, this should refer to alternative text. We are clarifying the spec to
include all parts of the text equivalent computation in the aria-relevant
value of "text". We will come back to the issue of whether alt text still
applies as a text node when <img role="presentation" alt="foo"/> or <span
role="presentation" aria-label="foo">...</span>.
----------------------------------------------------------------------
Comment 220: All source objects grabbed
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0064.html
Relates to: WAI-ARIA 1.0 Authoring Practices - 7. Drag-and-Drop Support <http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#dragdrop>
Status: Answered question
-------------
Your comment:
-------------
Item 3: How can it be determined that all source objects have been grabbed?
By nature of the functionality, the user is free to keep adding or removing
source objects. It seems like it would be necessary to set the
aria-dropeffect attributes every time the source objects change.
--------------------------------
Response from the Working Group:
--------------------------------
The first sentence of item three in the drag-and-drop section is badly
worded. It conveys poorly that the determination of when all source
objects have been grabbed is in the hands of the user. We have reworded
it.
When using a mouse, users click, hold the mouse button, and drag the mouse
when moving the selected objects, and, by implication, are no longer
selecting them. With respect to keyboard users, the previous section, Item
2, "Allow the user to initiate the appropriate drag operation using the
keyboard", recommends using Control+M to indicate the end of the selection
phase.
Items two and three together mean that when the set of grabbed objects
changes, and the user indicates that they are about to move them, then the
system must determine the drop targets. This is done by modifying the
aria-dropeffect at that time.
----------------------------------------------------------------------
Comment 221: OS-independent modifiers
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0064.html
Relates to: WAI-ARIA 1.0 Authoring Practices - 8. States and Properties Modified by an External Assistive Technology <http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#aria-write>
Status: Proposal not accepted
-------------
Your comment:
-------------
The choice of Ctrl as the modifier key for Global recommendations is the
intuitive modifier on Windows and Linux, but it would not be intuitive on
the Mac. We think the modifier should be consistent with the OS conventions
--------------------------------
Response from the Working Group:
--------------------------------
The Mac "command" key is a special modifier that is typically reserved for
OS- or application-level integration. It is unlikely that JavaScript
authors will be able to consistently override the Command key for use in
JavaScript applications. Furthermore, documenting interface recommendations
that change depending on the run-time environment is likely to confuse both
users and application authors. These keyboard recommendations are a
stop-gap measure intended to suffice until a more appropriate
device-independent mechanism can be provided for ARIA 2.0.
Device and platform-independent interaction support is a complex issue
that ARIA 1.0 is unable to address, but we have created an issue to address
this in ARIA 2.0.
----------------------------------------------------------------------
Comment 222: Documenting key mappings
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0064.html
Relates to: WAI-ARIA 1.0 Authoring Practices - 9. Design Patterns <http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#aria_ex>
Status: Accepted proposal
-------------
Your comment:
-------------
"the author must provide documentation of those key mappings in the
contents of the web page." While we understand the motivation for this
clause, this is too restrictive. For a web application, it may make much
more sense to provide separate training and documentation than to include
documentation of keyboard commands directly in the page.
--------------------------------
Response from the Working Group:
--------------------------------
We agree with your comment and have reworded the paragraph to say the
following:
If the host language does not define key mappings, such as hot keys, and
the author defines key mappings other than those described here or in
Drag-and-Drop Support, then the author must provide documentation of those
key mappings. These mappings can be provided in the contents of the web
page, or in the case of a more complex application, within the help file
documentation and training materials.
We hope you feel this is an acceptable alternative.
----------------------------------------------------------------------
Comment 223: colspan and rowspan properties
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0064.html
Relates to: WAI-ARIA 1.0 Authoring Practices - Grid (Simple Data Tables) (widget) <http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#grid>
Status: Proposal not accepted
-------------
Your comment:
-------------
"Using col and rowspan should be reflected in the keyboard navigation." We
assume this is colspan and rowspan? Since there are no ARIA properties for
these attributes, they could only be used if the grid is based on HTML
table mark-up. Consider providing corresponding ARIA grid properties.
--------------------------------
Response from the Working Group:
--------------------------------
WAI-ARIA is not meant as a replacement for HTML tables. If the author
wishes to have headers that span multiple columns or rows this can be
achieved by overlaying ARIA on an HTML table or by using aria-labelledby to
have a cell reference its corresponding table. We have updated the grid
design pattern in the ARIA Best Practices Guide to reflect this.
For ARIA 2.0, we will reconsider the issue of spanning gridcells.
----------------------------------------------------------------------
Comment 224: Event bubbling
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0064.html
Relates to: WAI-ARIA 1.0 Authoring Practices - Grid (Simple Data Tables) (widget) <http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#grid>
Status: Alternate action taken
-------------
Your comment:
-------------
"If a widget is in the current grid cell that also uses and ESC key, then
the keys will bubble up to allow each ESC to be used." Does this mean that
it is not possible to execute the ESC action on the widget without also
leaving Actionable Mode? This needs additional clarification.
--------------------------------
Response from the Working Group:
--------------------------------
Following your comment we have rewritten the text for clarification
purposes. Just to respond also to your specific question, it is possible to
execute the ESC action on a widget without also leaving Actionable mode.
----------------------------------------------------------------------
Comment 225: unselecting radio button
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0064.html
Relates to: WAI-ARIA 1.0 Authoring Practices - Radio Button (widget) <http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#radiobutton>
Status: Accepted proposal
-------------
Your comment:
-------------
"Spacebar is a toggle selected/unselected." What does it mean to unselect a
radio button? Does this return the radio group to its initial state, with
nothing selected? Since this is non-standard behavior, it should be spelled
out more clearly.
--------------------------------
Response from the Working Group:
--------------------------------
This is an error and will be corrected. Spacebar selects the radio button
with focus and de-selects other radio buttons in the group.
----------------------------------------------------------------------
Comment 226: Don't reuse ctrl+pageup and ctrl_pagedown
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0064.html
Relates to: WAI-ARIA 1.0 Authoring Practices - Tab Panel (widget) <http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#tabpanel>
Status: Proposal not accepted
-------------
Your comment:
-------------
Regarding Ctrl+PageUp/Ctrl+PageDown. This is a serious usability issue. We
think we should not reuse those keystokes, even though they are standard.
--------------------------------
Response from the Working Group:
--------------------------------
To define keyboard styling best practices for WAI-ARIA a group of
accessibility and web application developers was formed. In that effort it
was deemed that the learnability of the keystoke took precedence over the
usability issue of the clash of keystrokes.
There are many other places where keystrokes at one level may clash with
parent widget or browser keystrokes. The simple rule that was applied was
that the level furthest down the hierarchy wins.
We are adding a note to the Best Practices Guide to make authors aware of
the device independence issues related to using modifier keys with ARIA. We
plan to address keyboard interaction in a more device-independence way in
ARIA 2.0.
----------------------------------------------------------------------
Comment 227: Arrow not a modifier
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0064.html
Relates to: WAI-ARIA 1.0 Authoring Practices - Tree View (widget) <http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#TreeView>
Status: Accepted proposal
-------------
Your comment:
-------------
Since Arrow is not a modifier key, Ctrl-Arrow-Space makes no sense. What
key combination was intended here?
--------------------------------
Response from the Working Group:
--------------------------------
The text does not indicate that the Arrow key is a modifier as it is
followed by a hyphen. However, there is a problem that this section does
not specify modifier keys by following them with a "+" vs a "-", hence the
confusion. We shall correct that.
----------------------------------------------------------------------
Comment 228: object with tooltip shouldn't have to retain focus
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0064.html
Relates to: WAI-ARIA 1.0 Authoring Practices - Tooltip Widget (widget) <http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#tooltip>
Status: Answered question
-------------
Your comment:
-------------
"The trigger element to which the tooltip is attached, e.g., a link, should
never actually lose input focus." This means that any trigger element with
a tooltip must implement the tooltip keyboard behavior. e.g. ESC, onblur
etc. This seems problematic. At the very least, it leads to extensive code
duplication.
--------------------------------
Response from the Working Group:
--------------------------------
The working group discussed this and this is normal keyboard handling for
widgets.
----------------------------------------------------------------------
Comment 229: Key stacking
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0064.html
Relates to: WAI-ARIA 1.0 Authoring Practices - Tooltip Widget (widget) <http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#tooltip>
Status: Accepted proposal
-------------
Your comment:
-------------
"If more then one widget uses the same keys, e.g., Esc, then they should be
handled in a Last In First Out (LIFO) manner." - Please clarify; this makes
it sound as if you cannot get the ESC behavior of any widget without
getting the ESC behavior of all.
--------------------------------
Response from the Working Group:
--------------------------------
We have added an example to clarify the meaning of LIFO in this context.
----------------------------------------------------------------------
Comment 230: Don't localize hot key
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0064.html
Relates to: WAI-ARIA 1.0 Authoring Practices - Wizard (widget) <http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#wizard>
Status: Alternate action taken
-------------
Your comment:
-------------
Localizing the hot key used seems like a bad idea. Localized names may not
start with unique letters, and predictability of keyboard access goes down
as each author decides how to localize the commands.
--------------------------------
Response from the Working Group:
--------------------------------
We have removed the note about hot key localization from the wizard
widget.
We did add a section under the Keyboard and Structural Navigation section
that discusses hot keys more explicitly. This section discusses the issues
of localization and warns authors of the issues you raise.
----------------------------------------------------------------------
Comment 231: Disassociate from orientation
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0064.html
Relates to: WAI-ARIA 1.0 Authoring Practices - Window Splitter (widget) <http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#windowsplitter>
Status: Accepted proposal
-------------
Your comment:
-------------
Arrow commands should not depend on the orientation of the splitter, since
blind users have no way to find out what that orientation is. Always make
Left Arrow and Up Arrow move splitter left or up, as appropriate.
--------------------------------
Response from the Working Group:
--------------------------------
We agree. The keystrokes have been modified so that up/left and down/right
will operate on both vertical and horizontal splitters.
----------------------------------------------------------------------
Comment 232: Function of F6
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0064.html
Relates to: WAI-ARIA 1.0 Authoring Practices - Window Splitter (widget) <http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#windowsplitter>
Status: Alternate action taken
-------------
Your comment:
-------------
Why is F6 is listed here, unless it is supposed to take focus from the
splitter to an adjacent pane? Once focus is on the pane, the splitter can't
control whether it rotates through other panes.
--------------------------------
Response from the Working Group:
--------------------------------
F6 is included here to provide guidance as to how to navigate between panes
separated by the splitter. Those who implement a splitter will need to
provide this navigation.
We have included aria state and property information for the window
splitter as well as an example in the WAI-ARIA Authoring Practices Guide.
Received on Tuesday, 15 December 2009 00:31:15 UTC