REQUIREMENT EV1: a user must have the ability to obtain the list of input device event handlers explicitly associated with an element in a device independent manner.
* Explanatory note EV1.1: Users interacting with a web browser may
be doing so by voice, keyboard, mouse or another input technology
or a combination of any of these. No matter how the user is
controlling the user agent, he or she needs to know all the input
methods assigned to a particular piece of content.
REQUIREMENT EV2: a user must be able to activate any input device event handlers explicitly associated with an element in a device independent manner.
* Explanatory note EV2.1: Although it should not be so designed,
some Web content is designed to work only with certain input
devices, such as a mouse, thereby limiting the availability of
those event handlers to specific devices. Some users interacting
with a web browser may be doing so by voice, keyboard, mouse or
another input technology or a combination of any of these. No
matter how the user is controlling the user agent, he or she must
be able to activate any of the event handlers regardless of the
interaction technology being used.
* Explanatory note EV2.2: A user who cannot use a mouse needs to
activate a flyout menu that normally appears OnMouseOver. The user
should be able to navigate to a link and activate it using
REQUIREMENT EV3: a user must be able to simultaneously activate all input device event handlers explicitly associated with an element in a device-independent manner.
* Explanatory note EV3.1: One input method should not hold back
another. People who don't use a mouse shouldn't necessarily have
to map their input methods to the same steps a mouse user would
+ Speech input users may combine moving the mouse up,
left and clicking in a single command phrase.
+ A link has an onmousedown and an onmouseup event
link. The keyboard user should be able to use 1 key
click to activate both events.
REQUIREMENT EV4: HTML5 must provide a standard way to enumerate the events on a DOM node and a parallel method to use addEventListener and removeEventListener to obtain a collection of "events" or an enumeration function.
* Explanatory Note 1: This is extremely important for analyzing
web applications for identifying keyboard support for widgets.
Isn't this an issue for DOM Level 3 Events, not HTML5? HTML5 does not define the concept of event handlers, it just uses it.
Reassigning to DOM Events, since this doesn't seem to be HTML-specific.
Doug: Feel free to reassign back to me if you think this should be dealt with at the HTML level.
Assigning to myself to take action on these open bugs.
--DOM3 Events--Last Call Bugs Review--
I'm concerned with adding these Accessiblity APIs (how I understand requirements EV1-4) alongside the other APIs described in this document [DOM3 Events], primarily becuase the conformance criteria for the existing APIs in this spec relate to browsers and script engine interop in particular, and the accessibility APIs for event inspection and dispatch would belong to a whole different conformance criteria.
In short, I wouldn't expect to see the accessibility APIs (if defined herein) available to a browser's scripting engine, nor would I expect them to be testable using the same techniques employed for the APIs already described in this spec.
If accessibility APIs were added to this spec, how would they be tested and verified?
To me these requirements seem so distinct as to merit a document all their own.
Would love to hear feedback. Have there been new developments since this bug was filed? (This bug was filed just under a year and a half ago.)
Assigning to me. I've got a mail thread with a representative of a11y WG... who are looking into this again...
Closing this issue per common consent as recorded here:
and copied below for those w/out member access:
From: Michael Cooper [mailto:email@example.com]
Sent: Wednesday, August 8, 2012 1:02 PM
To: Travis Leithead
Cc: 'Doug Schepers'; Adrian Bateman; Janina Sajka; WAI PFWG; WAI Liaison
Subject: Re: WebApps Bug 10896 - enable device independent access to event handlers
Hi Travis - I'm sorry, you didn't miss an official announcement. We sent a Call for Objections to the PF list on 27 June 2012:
No objections were sent, e.g., see
We didn't record a formal resolution in a meeting, but we worked up a formal response in the 27 June 2012 PF meeting (which had low quorum so we didn't record a resolution):
"In the years since this bug was filed, our view of how to provide accessibility to Web Applications has evolved. The new IndieUI work is expected to meet the user requirements albeit in a different manner than originally proposed in this bug. Requirements that IndieUI would not meet are ones that we no longer believe need to be met. Therefore we now believe there is nothing needed in DOM Level 3 Events. We appreciated your thoroughness in checking this with us and it has helped to clarify our position on accessibility events. You can close this bug without further action."
Based on all the above, you can consider this issue closed from our perspective. I'm copying the PF list and the wai-liaison list to archive this.