- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Thu, 7 Apr 2011 10:49:45 -0500
- To: lweiss@microsoft.com, cyns@exchange.microsoft.com, Andi Snow-Weaver <andisnow@us.ibm.com>, david.bolter@gmail.com, jcraig@apple.com
- Cc: wai-xtech@w3.org
- Message-ID: <OF5317F007.B23E38B5-ON8625786B.00503D5C-8625786B.0056F3A7@us.ibm.com>
After discussion with the Mozilla accessibility developer for Linux and
discussions with Larry Weiss (Microsoft) I have made extensive
modifications to sections 4.2 and 4.3 (
http://www.w3.org/WAI/PF/aria-implementation/#keyboard-focus_aria-activedescendant
). The general issues addressed by this change are:
- Removing the editorial note and state how aria-activedescendant is
supposed to work
- Make a clear distinction about what "focus" we are dealing with. I have
delineated DOM and desktop focus.
- Added a statement regarding the authors responsibility to not show focus
on the container element for elements that support aria-activedescendant.
(We should probably state this in the authoring practices too)
- Correct the statement that the container with aria-activedescendant does
not disappear from the accessibility tree
- Modified the text so that we don't state "tab navigation order" to be
more in line with HTML 5 to ensure device independence for mobile.
Andi, we should include glossary entries for DOM and desktop focus. Note:
we may consider calling desktop focus platform focus.
Please review the changes and comment. I put this on xtech so Larry does
not get bounced.
<change>
4.2. Controlling focus with aria-activedescendant
Editorial note: In current implementations as described below, user agents
keep the desktop focus on the container but communicate focus events and
states to the assistive technology as if the active descendant has focus.
Alternatively, the actual desktop focus could move to the active
descendant. This would be a less complex scenario for user agents to
implement and would be a better scenario for users who have customized the
appearance of their desktop keyboard focus. There is some concern that if
the desktop focus is placed on the active descendant, some keyboard events
might get dropped.
The WAI-ARIA User Agent Implementation task force seeks feedback from
reviewers on this issue.
The aria-activedescendant property may also be used to enable keyboard
accessibility on WAI-ARIA elements that support this attribute. It is often
a more convenient way of creating container widget keyboard navigation
(where the entire widget is in the tab order just once, but the user can
use other keys, typically arrow keys, to navigate to descendant items of
the container).
Typically, the author will use host language semantics to put the container
element in the sequential tab order (tabindex="0" in HTML) and
aria-activedescendant to point to the ID of the currently active
descendant. The author, not the user agent, is responsible for styling the
currently active descendant to show it has keyboard focus. The author
cannot use :focus to style the currently active descendant since actual
focus is on the container.
The user agent MUST do the following to implement aria-activedescendant:
1. Implement the host language method for keyboard navigation so that
the container widget may be included in the tab order. For HTML
implementations, see Controlling focus with tabindex.
2. Do not expose any element in the accessibility API the when it has
DOM focus and also has aria-activedescendant which points to a valid
ID.
3. When the aria-activedescendant attribute changes on an element that
currently has DOM focus, fire an accessibility API FOCUS event on the
new active descendant. If aria-activedescendant is cleared or does
not point to an element in the current document, fire a FOCUS event
for the container object that had the attribute change.
4. For any element with an ID attribute, where the element is a
descendant of an element with the aria-activedescendant attribute,
apply the following states to the target to ensure the object is
accessible:
1. FOCUSABLE, if the element also has a WAI-ARIA role — because
the aria-activedescendant of the container can potentially
point to it. It is not absolutely necessary to check this when
there is no role, because real HTML elements that would be
focusable would already have the FOCUSABLE state.
2. ACTIVE, whenever the container element sets
aria-activedescendant to match the ID of this descendant
3. FOCUSED, if ACTIVE and the container widget with
aria-activedescendant has true DOM focus
5. If the assistive technology sets focus to a descendant of a container
with aria-activedescendant, change the value of aria-activedescendant
to point to that item.
4.3. Handling focus changes from the Assistive Technology
Alternative input software needs to be able to set focus to items that are
focusable. Screen readers, voice input software and on-screen keyboards may
set focus based on user commands implemented in that software. User agents
MUST allow AT to set focus using accessibility APIs as defined in the
following table:
MSAA Microsoft UIA ATK/AT-SPI Mac OS X Accessibility
accSelect(SELFLAG_TAKEFOCUS) RaiseAutomationEvent AtkComponent::grab_focus Notification:
AXFocusedUIElementChanged
If the would-be-focused element can take real DOM focus, the user
agent MUST set the DOM focus to it.
Otherwise, if the current element has an ID and an ancestor with the
aria-activedescendant attribute present, the user agent MUST set DOM
focus to that ancestor. If successful, then set aria-activedescendant
on the ancestor to the ID of the current element. When it is not
possible for the user agent to set DOM focus to the containing
element with aria-activedescendant, the user agent MAY attempt to set
focus to the child element itself. Note: the inability to set focus
to the containing element indicates an author error.
</change>
<to>
4.2. Controlling focus with aria-activedescendant
When implementing, as as described below, user agents keep the DOM focus on
the container but communicates desktop focus events and states to the
assistive technology as if the active descendant has focus. It is the
responsibility of the user agent to ensure that keyboard events are
processed at the element that has DOM focus. Since keyboard events are to
be processed at the container any keyboard events directed at the active
descendant would bubble up to the DOM element with focus for processing.
The aria-activedescendant property may be used to enable keyboard
accessibility on WAI-ARIA elements that support this attribute. It is often
a more convenient way of creating container widget keyboard navigation
(where the entire widget is in the tab order just once, but the user can
use other keys, typically arrow keys, to navigate to descendant items of
the container).
Typically, the author will use host language semantics to put the container
element in the focus navigation order (tabindex="0" in HTML) and
aria-activedescendant to point to the ID of the currently active
descendant. The author, not the user agent, is responsible for styling the
currently active descendant to show it has keyboard focus and for styling
the DOM focused container such that it does not appear to be focused. The
author cannot use :focus to style the currently active descendant since
actual focus is on the container.
The user agent MUST do the following to implement aria-activedescendant:
1. Implement the host language method for keyboard navigation so that
the container widget may be included in the focus navigation order.
For HTML implementations, see Controlling focus with tabindex.
2. Do not expose the focused state for any element in the accessibility
API when it has DOM focus and also has aria-activedescendant which
points to a valid ID.
3. When the aria-activedescendant attribute changes on an element that
currently has DOM focus, fire an accessibility API desktop FOCUS
event on the new active descendant. If aria-activedescendant is
cleared or does not point to an element in the current document, fire
a desktop FOCUS event for the container object that had the attribute
change.
4. For any element with an ID attribute, where the element is a
descendant of an element with the aria-activedescendant attribute,
apply the following states to the target to ensure the object is
accessible:
1. FOCUSABLE, if the element also has a WAI-ARIA role — because
the aria-activedescendant of the container can potentially
point to it. It is not absolutely necessary to check this when
there is no role, because real HTML elements that would be
focusable would already have the FOCUSABLE state.
2. ACTIVE, whenever the container element sets
aria-activedescendant to match the ID of this descendant
3. FOCUSED, if ACTIVE and the container widget with
aria-activedescendant has true DOM focus
5. If the assistive technology sets focus to a descendant of a container
with aria-activedescendant, change the value of aria-activedescendant
to point to that item.
4.3. Handling focus changes from the Assistive Technology
Alternative input software needs to be able to set destkop focus to items
that are focusable. Screen readers, voice input software and on-screen
keyboards may set desktop focus based on user commands implemented in that
software. User agents MUST allow AT to set desktop focus using
accessibility APIs as defined in the following table:
MSAA Microsoft UIA ATK/AT-SPI Mac OS X Accessibility
accSelect(SELFLAG_TAKEFOCUS) RaiseAutomationEvent AtkComponent::grab_focus Notification:
AXFocusedUIElementChanged
If the would-be-focused element can take real DOM focus, the user
agent MUST set the DOM focus to it.
Otherwise, if the current element has an ID and an ancestor with the
aria-activedescendant attribute present, the user agent MUST set DOM
focus to that ancestor. If successful, then set aria-activedescendant
on the ancestor to the ID of the current element. When it is not
possible for the user agent to set DOM focus to the containing
element with aria-activedescendant, the user agent MAY attempt to set
focus to the child element itself. Note: the inability to set focus
to the containing element indicates an author error.
</to>
Rich Schwerdtfeger
CTO Accessibility Software Group
Received on Thursday, 7 April 2011 15:50:37 UTC