- From: Janina Sajka <janina@rednote.net>
- Date: Tue, 15 Dec 2009 00:31:17 +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 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 233: Examples need improvement
Date: 2009-04-17
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0067.html
Relates to: WAI-ARIA 1.0 Authoring Practices <http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/>
Status: Alternate action taken
-------------
Your comment:
-------------
My overall concerns with the current state of the ARIA Best Practices
document is that it contains a lot of examples and recommended solutions
that
are actually not considered industry best practices for web development
and
web accessibility. Consider the toolbar example that is presented in the
section titled "General Steps for Building an Accessible Widget with
ARIA".
This example has the following problems:
1. Poor Use of Semantic Markup
Using the <img> element as the basis for a button control is not a good
use of semantic markup and contradicts the use case for ARIA outlined in
section 1.2 of the ARIA Specification itself: "ARIA is intended to be
used
as a supplement for native language semantics, not a replacement."
Why doesn't this example use <input> or <button> elements as the basis
for
the toolbar's buttons? If it did it would better illustrate how ARIA
can be used to supplement for native language semantics. It would also
make for a toolbar that is more accessible in older browsers
(e.g. IE 6 & 7) that don't support ARIA. This is especially important
considering right now the browsers that don't support ARIA outnumber
those that do.
2. Use of inline JavaScript event handlers
This has long been considered to be a bad practice, and I was surprised
to
see this technique appear so often in the ARIA Best Practices Document.
3. ARIA roles and tabIndex are applied inline rather than being managed
via JavaScript
Since ARIA-enabled widgets *require* JavaScript for keyboard support and
state management, I think that it only makes sense that ARIA roles,
states,
and properties for widgets should only be applied using script. The
same
goes for the tabIndex attribute. I'd like to see this mentioned in the
ARIA Best Practices document and applied to the examples.
I think that the examples in the ARIA Best Practices document should
represent us putting our best foot forward--showcasing a culmination of
best practices for accessibility made even better with the introduction of
ARIA.
Instead the document leads with example that represents a bunch of really
bad
practices. But I don't want to criticize and offer no solutions, so if
you are
looking for developers to volunteer examples the ARIA Best Practices
Document I
would be happy to volunteer.
--------------------------------
Response from the Working Group:
--------------------------------
The working group will continue to improve the examples and welcomes the
contributions of examples or comments on individual examples. The examples
should be considered best practices for use of ARIA markup and not best
practices for web development in general. It is understood that using
inline code is not preferred or common practice in industry, but the
purpose in these examples is to help people trying to understand aria to
easily identify which elements receive certain roles, states and
properties. If the examples use scripting to add the ARIA markup it would
require users to make an additional level of abstraction to understand what
elements ARIA markup is being applied too. For example, the use of inline
event handlers on some of the examples helps some web developers understand
that ARIA is more than just adding attributes, that keyboard support and
focus management are also important issues. We will try to add comments to
this effect to code that is being used to illustrate important concepts,
but are not considered best programming practices for DHTML.
----------------------------------------------------------------------
Comment 234: Clarify tabindex=-1
Date: 2009-04-17
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0067.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:
-------------
- Point 2: "From the role, get the list of supported states and
properties":
- There's a sentence in this section that is slightly misleading. It
reads: "By setting tabindex="-1" on the toolbar, we have specified that
the toolbar will receive focus in the document order" This could be
confusing to developers since setting the "tabIndex" attribute to -1
removes an element from the browser's default tab flow.
--------------------------------
Response from the Working Group:
--------------------------------
We agree, this is a good catch. We have changed tabindex="-1" to
tabindex="0" in the example and the corresponding text you refer to.
----------------------------------------------------------------------
Comment 235: Don't focus on workarounds
Date: 2009-04-17
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0067.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:
-------------
- Point 7: "Synchronize the visual UI with accessibility states and
properties
for supporting user agents"
- I like the mentioning of IE 6's lack of attribute selector support. I
don't like the time spent suggesting fixes to IE 7's broken attribute
selector support. I think that this section would be more useful if it
simply made it known that currently not all of the major browsers have
support for CSS attribute selectors, and provided an example of how to
engineer a solution for styling state that worked consistently well
across all browsers. In this case that means avoiding use of attribute
selectors for styling updates to a widget's state, and instead,
applying
class names that represent, and can be used to style state.
--------------------------------
Response from the Working Group:
--------------------------------
We agree. Consequently, we have modified the Authoring Practices Guide to
make use of CSS class names to address your concern and removed the
workarounds for specific browsers.
----------------------------------------------------------------------
Comment 236: em not a good replacement for px
Date: 2009-04-17
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0067.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:
-------------
- Point 11: "Review widget to ensure that you have not hard coded sizes"
- I like how this section tells the user to avoid "px" as the unit for
defining font sizes. I don't like the suggestion of using the "em"
unit
to replace "px" as we've (Yahoo!) found "em" doesn't scale as nicely in
IE 6 and 7. We've done a lot of research on fonts at Yahoo! and believe
that using percentages scales the most consistently cross browser. Our
best thinking on this can be found here:
http://developer.yahoo.com/yui/fonts/
--------------------------------
Response from the Working Group:
--------------------------------
We have changed the example to use percentages.
----------------------------------------------------------------------
Comment 237: Focus delegation
Date: 2009-04-17
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0067.html
Relates to: WAI-ARIA 1.0 Authoring Practices - 3.2.1. Using Tabindex to Manage Focus among Widgets <http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#focus_tabindex>
Status: Accepted proposal
-------------
Your comment:
-------------
+ Item 1: "Use onfocus to track the current focus"
- I think that when it comes to listening to focus in the browser, the
ARIA Best Practices document should reference PPK's focus delegation
technique:
http://www.quirksmode.org/blog/archives/2008/04/delegating_the.html
We've rolled this technique into YUI and it has been both incredibly
useful and helped us improve the performance of our widgets. Read the
following blog entry for more info:
http://yuiblog.com/blog/2008/10/07/onfocus-onblur/
--------------------------------
Response from the Working Group:
--------------------------------
The working group will make this information available to people developing
the test suite and test suites being developed as a part of ARIA should
include examples of this technique.
----------------------------------------------------------------------
Comment 238: Remove redundant focus info
Date: 2009-04-17
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0067.html
Relates to: WAI-ARIA 1.0 Authoring Practices - 3.2.1. Using Tabindex to Manage Focus among Widgets <http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#focus_tabindex>
Status: Accepted proposal
-------------
Your comment:
-------------
+ Item 2: "Refresh an elements style using onfocus()"
- I would consider removing this item since it is mostly repeating
points
that are mentioned in item 8 titled "Always draw the focus for
tabindex="-1" items and elements that receive focus programmatically"
--------------------------------
Response from the Working Group:
--------------------------------
We agree with your comment and will remove item #2
----------------------------------------------------------------------
Comment 239: Update tabindex value
Date: 2009-04-17
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0067.html
Relates to: WAI-ARIA 1.0 Authoring Practices - 3.2.1. Using Tabindex to Manage Focus among Widgets <http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#focus_tabindex>
Status: Accepted proposal
-------------
Your comment:
-------------
+ Item 5: "Dynamically change focusability using the tabIndex property"
- I would go so far as to recommend always updating the "tabIndex"
property to 0 (or greater) before focusing an element. This provides
two benefits:
1) You completely avoid the problem in IE where the default browser
focus outline isn't drawn when an element is focused
programmatically. This ensures the browser's default rendering of
focus, which is beneficial considering that it is already familiar
to the user.
2) If the currently focused descendant of a UI control has a tabIndex
of 0 it allows the user to press shift+tab to move back
to where they were if they exit a control and want to go back.
--------------------------------
Response from the Working Group:
--------------------------------
We will update item #5 to read:
Dynamically change focusability using the tabIndex property - You may want
to update tabindex values if a custom control becomes disabled or enabled.
Disabled controls should not be in the tab order. However, you can
typically arrow to them if they're part of grouped navigation widget.
Tabindex values may also need to change tabindex values from -1 to 0 to
make an element the default element of the widget if the user leaves the
widget and returns to the widget. Only one element of a widget should have
a tabindex value of 0.
----------------------------------------------------------------------
Comment 240: Timed focus
Date: 2009-04-17
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0067.html
Relates to: WAI-ARIA 1.0 Authoring Practices - 3.2.1. Using Tabindex to Manage Focus among Widgets <http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#focus_tabindex>
Status: Accepted proposal
-------------
Your comment:
-------------
+ Item 6: "Use setTimeout with element.focus() to set focus"
- Is use of "setTimeout" really necessary? If so, can you more
accurately
describe the problem? The current description of the problem seems
really vague: "The timeout is necessary in both IE and Firefox 1.5, to
prevent scripts from doing strange unexpected things as the user clicks
on buttons and other controls."
- I would avoid mentioning Firefox 1.5 since it doesn't have enough
market share at this point to be of enough significance. And it makes
the advice seemed dated.
- If use of "setTimeout" fixes larger usability problems in IE, then
call
those out as I think it will give this solution more credibility.
--------------------------------
Response from the Working Group:
--------------------------------
After consultation, and investigation of some JavaScript toolkits, we have
decided that the use of setTimeout() is not necessary. We have removed
references to setTimeout() from this section.
----------------------------------------------------------------------
Comment 241: Style focus with events
Date: 2009-04-17
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0067.html
Relates to: WAI-ARIA 1.0 Authoring Practices - 3.2.1. Using Tabindex to Manage Focus among Widgets <http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#focus_tabindex>
Status: Accepted proposal
-------------
Your comment:
-------------
+ Item 7: "Don't use :focus or attribute selectors to style the focus"
- This is an important piece of advice, considering IE's limited support
of the :focus pseudo class and lack of attributor selector support in
IE 6. That said, the suggested example solution of styling focus via
an inline style is a bad one. I'd like to see the recommended solution
be: Style focus by using a "focus" event handler to apply a class to
the
focused element. That way you can centrally manage how focus is
styled.
--------------------------------
Response from the Working Group:
--------------------------------
We will change the tip to:
The use of :focus pseudo-class selectors to style the keyboard focus is
not supported in many versions of Internet Explorer. Authors should use the
:active pseudo-class (which older versions of IE treat like :focus) in
conjunction with the :focus pseudo-class. Example: a:focus, a:active {
text-decoration: underline; }
If the related CSS pseudo-classes are not appropriate or not supported in
all browsers, authors can use JavaScript techniques to indicate an
appropriate focus alternative, such as using focus and blur events to
toggle a classname on an element.
----------------------------------------------------------------------
Comment 242: Improved focus handling
Date: 2009-04-17
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0067.html
Relates to: WAI-ARIA 1.0 Authoring Practices - 3.2.1. Using Tabindex to Manage Focus among Widgets <http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#focus_tabindex>
Status: Accepted proposal
-------------
Your comment:
-------------
+ For item 8: "Always draw the focus tabIndex='-1'"
- I would remove this item as it seems to suggest a solution to a
problem that, as I suggest above, can be avoided entirely if developers
simply update the tabIndex property to 0 before programatically
focusing an element.
- I would replace this item/section with a new one that focuses on the
importance of developers providing a clear, consistent rendering of
focus through:
1) Relying on the browser's default rendering of focus--something the
user is already familiar with.
2) If developers are going to customize how focus is rendered, it is
important that focus is rendered consistently across all focusable
elements within the scope of the site/application so that the user
only has to learn one focus model.
--------------------------------
Response from the Working Group:
--------------------------------
After consultation, and investigation of some JavaScript toolkits, we have
decided that the use of setTimeout() is not necessary. We have removed
references to setTimeout() from this section.
----------------------------------------------------------------------
Comment 243: Key overload
Date: 2009-04-17
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0067.html
Relates to: WAI-ARIA 1.0 Authoring Practices - 3.2.1. Using Tabindex to Manage Focus among Widgets <http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#focus_tabindex>
Status: Accepted proposal
-------------
Your comment:
-------------
+ Item 9: "Prevent used key events from performing browser functions"
- Update example so that it doesn't use an inline event handler
- For Opera 9 and Firefox 2: calling the "preventDefault" method in
response to the "keydown" won't prevent undesired scrolling. To fix
the
problem in Opera 9 and Firefox 2, you also need to call
"preventDefault" in response to the "keypress" event.
--------------------------------
Response from the Working Group:
--------------------------------
Update information in the WAI-ARIA Authoring Practices to include your
suggestion.
----------------------------------------------------------------------
Comment 244: Key event handlers
Date: 2009-04-17
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0067.html
Relates to: WAI-ARIA 1.0 Authoring Practices - 3.2.1. Using Tabindex to Manage Focus among Widgets <http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#focus_tabindex>
Status: Alternate action taken
-------------
Your comment:
-------------
+ Item 10: "Use key event handlers to enable activation of the element"
- If you are interested in providing more detail on this point, this
technique is necessary in IE, Firefox and Webkit when you use the
"tabIndex" attribute to make an element that is not natively
focusable, focusable.
- Opera is the only browser that fires the "click" event when the user
presses enter while focused on an element that was made focusable via
the use of the "tabIndex" property.
--------------------------------
Response from the Working Group:
--------------------------------
We are keeping product specific references out of the document in order to
maintain W3C vendor neutrality. However, we recognize that this is
important information. We will add a reference to external resource(s) that
contain this information, and put your suggestions there.
----------------------------------------------------------------------
Comment 245: Clarify skip navigation
Date: 2009-04-17
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0067.html
Relates to: WAI-ARIA 1.0 Authoring Practices - 3.2.6.1. Steps for Defining a Logical Navigational Structure <http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#kbd_layout_landmarks>
Status: Accepted proposal
-------------
Your comment:
-------------
Point 4: "Assign landmark roles to each region"
- I think that the following needs a better explanation: "Skip to main
content links impact the layout of applications and only address one
main content area." How does a skip navigation link negatively
impact the layout of a page, especially if it is hidden offscreen
using CSS?
--------------------------------
Response from the Working Group:
--------------------------------
We are adding an explanation of the issue with skip navigation links.
----------------------------------------------------------------------
Comment 246: Region in example
Date: 2009-04-17
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0067.html
Relates to: WAI-ARIA 1.0 Authoring Practices - 3.2.6.1. Steps for Defining a Logical Navigational Structure <http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#kbd_layout_landmarks>
Status: Accepted proposal
-------------
Your comment:
-------------
Point 6: "For landmarks unsuited to specialized region ARIA roles"
- Why doesn't the example show use of the generic "region" role, as
mentioned in the preceding paragraph?
--------------------------------
Response from the Working Group:
--------------------------------
This is an oversight, the code example has been changed to role="region".
----------------------------------------------------------------------
Comment 247: No hard distinction between applications and documents
Date: 2009-04-17
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0067.html
Relates to: WAI-ARIA 1.0 Authoring Practices - 3.2.6.1. Steps for Defining a Logical Navigational Structure <http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#kbd_layout_landmarks>
Status: Accepted proposal
-------------
Your comment:
-------------
Point 1: "After you have divided your Web page into regions through the
use
of role landmarks and custom regions, you must make a decision: Is your
Web
page an application or not?"
- This seems like an unnecessary designation to force developers to make
as the web is full of examples of pages that are hybrids between
documents and applications. The Yahoo! homepage and Facebook are
two good examples of pages that don't fit perfectly into the
designation
of application or document.
--------------------------------
Response from the Working Group:
--------------------------------
Your are correct, for many instances it may not make sense to make a hard
distinction as the interaction and content models of the pages may well be
hybrids of documents and applications. However it does make sense to review
the page and make a decision whether the majority of the content is
application like and as such the default interaction mode should be set to
application, with document regions embedded within the application if
applicable. Otherwise the default interaction mode is document like and
therefore should not be overridden by the use of a global role of
application. In this case the application role can be placed on discrete
regions within the document if applicable. The specification will be
updated to better reflect this advice.
----------------------------------------------------------------------
Comment 248: Widgets should behave like alerts
Date: 2009-04-17
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0067.html
Relates to: WAI-ARIA 1.0 Authoring Practices - 3.2.6.1. Steps for Defining a Logical Navigational Structure <http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#kbd_layout_landmarks>
Status: Proposal not accepted
-------------
Your comment:
-------------
Point 2: "Dialogs and alert dialogs - special case application roles
WAI-ARIA provides dialog and alertdialog roles that are to be treated as
special case application roles. Like application, screen readers will
leave
the main job of keyboard navigation up the application"
- I think all ARIA-enabled widgets should work like this. The screen
reader should be able to keep the virtual buffer on by default, and
should toggle it off on the fly if the user focuses into a widget.
--------------------------------
Response from the Working Group:
--------------------------------
Currently, the JAWS 11 beta keeps the virtual buffer on until a widget is
landed on by providing focus to it and then it releases the keyboard keys.
However, many screen readers do not maintain a virtual buffer for dialog
boxes. Some older screen readers had this feature but it does not exist in
today's screen readers for dialog boxes. This would require the screen
reader to maintain a virtual buffer for a dialog box which comes at a cost.
So, to be consistent with how screen readers work for GUI dialog boxes we
have stated this in our Authoring Practices Guide.
----------------------------------------------------------------------
Comment 249: Deprecate redundant roles
Date: 2009-04-17
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0067.html
Relates to: WAI-ARIA 1.0 Authoring Practices - 3.2.6.3.1. Header Levels Versus Nesting Levels <http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#kbd_layout_nesting_vs_level>
Status: Proposal not accepted
-------------
Your comment:
-------------
- Can we just omit or deprecate any ARIA roles (such as heading) that
directly duplicate elements already available in HTML?
--------------------------------
Response from the Working Group:
--------------------------------
ARIA is intended to be applicable to more languages than HTML, so it does
not work to deprecate ARIA semantics based on their availability in one
host language. It is expected that, over time, host languages will evolve
to provide semantics for objects that previously could only be declared
with ARIA. When native semantics for a given feature become available, it
is appropriate for authors to use the native feature and stop using ARIA
for that feature. Legacy content may continue to use ARIA, however, so the
need for user agents to support ARIA remains.
We are adding this explanation to the spec.
----------------------------------------------------------------------
Comment 250: Eliminate separator
Date: 2009-04-17
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0067.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: Proposal not accepted
-------------
Your comment:
-------------
- I love the idea of groups, and I think that the concept should be
applicable
as a means of semantically organizing any of a widget's descendants. If
this were the case, it would eliminate the need for the "separator" role
and help simplify the spec.
--------------------------------
Response from the Working Group:
--------------------------------
At this point we have two uses cases where we
need separators. In menus (Take the Firefox File menu) you have
separators.
These separators if used in a DHTML menu have an expected mapping to the
platform accessibility API. Assistive technologies are not accustomed to
finding explicit groupings in menus in operating systems. They are
accustomed to encountering separators.
The second use case is a resizable split pane where a separator is used to
change the size of the panes. The separator is capable of receiving focus
and allowing the user to adjust the separator with the keyboard.
So, while we also prefer the use of groups, assistive technologies in
these cases are used to processing separators in menus (not groups) and the
grouping role will not address the second use case. For these
reasons we shall be keeping the separator role.
----------------------------------------------------------------------
Comment 251: Use alt text
Date: 2009-04-17
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0067.html
Relates to: WAI-ARIA 1.0 Authoring Practices - 3.2.6.5.2. Marking Descriptive Sections <http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#kbd_layout_remaining_description>
Status: Accepted proposal
-------------
Your comment:
-------------
- I don't understand the use case for the example. Why wouldn't you just
use alt text?
--------------------------------
Response from the Working Group:
--------------------------------
Alternative text is not suitable for long descriptions. The intent of this
section is to show how aria-describedby can be used to have an image
reference its lengthy prose description. That does not mean that alt text
should not be provided to allow a user to access the short name of the
drawing object. We shall correct the step to convey the intent to reference
a lengthy description and provide a short name for the object.
----------------------------------------------------------------------
Comment 252: Improve button example
Date: 2009-04-17
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0067.html
Relates to: WAI-ARIA 1.0 Authoring Practices - 4.1.2. Describing <http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#DescribedBy>
Status: Alternate action taken
-------------
Your comment:
-------------
- This section contains a really horrible example:
<a role="button" aria-describedby="winClose" href="#"
onclick="fakewin.close()">X</a>
Why would anyone ever code a button like this? I would be up for helping
to provide better examples of using aria-describedby.
--------------------------------
Response from the Working Group:
--------------------------------
Close buttons are coded this way to provide backward-compatibility to
browsers and AT that do not support ARIA. By using an element that has
built-in action semantics, the "x" closes the fake window in a way that
works with AT in any browser/AT combination that supports JavaScript.
Changing to a <span> breaks this, and is not a best practice.
We've changed the example to a <button> and added aria-label="Close" to
the example, as it needs both a label and a description.
Received on Tuesday, 15 December 2009 00:31:28 UTC