- From: Cynthia Shelly <cyns@microsoft.com>
- Date: Thu, 23 Jun 2016 21:39:44 +0000
- To: "www-dom@w3.org" <www-dom@w3.org>, "public-apa@w3.org" <public-apa@w3.org>
- Message-ID: <CY1PR03MB2348A5A216BF2D9AFDB525B1C62D0@CY1PR03MB2348.namprd03.prod.outlook.com>
I was asked to review the UI Events spec for the Accessible Platform Architecture (APA) working group. TL;DR * The spec in general looks good. Some minor suggestions below. * An Events-AAM document describing how UI Events map to platform accessibility api events would be useful (we'll help create one) * There are features here that would make good WCAG techniques Details 3.2 typo Default actions<https://w3c.github.io/uievents/#default-action> are usually be performed 3.4 and 3.5 have some duplication with HTML5 spec, and aren't terribly clear. It might be better to refer to HTML5 spec instead. 4.1 and 9 Keypress is deprecated. This is because there wasn't implementation. Even though this feels most parallel to click, keydown is more widely supported. I think this is ok, given the implementation issues. 5.1.2 Event types Some of these are closely related to ARIA and AAPI events. It would be good to explore and document how these event sets relate, possibly by creating an Events Accessibility API Mapping document. Error Select (load, unload, and resize are not as close) 5.2 focus events Model is pretty rich. Further exploration needed about how these relate to ARIA and AAPI events. User shifts focus 1 focusin: Sent before first target element receives focus 2 focus : Sent after first target element receives focus User shifts focus 3 focusout: Sent before first target element loses focus 4 focusin: Sent before second target element receives focus 5 blur: Sent after first target element loses focus 6 focus" Sent after second target element receives focus We are somewhat concerned about interactions between the two models. Have possible conflicts been discussed? This specification does not define the behavior of focus events when interacting with methods such as focus() or blur(). See the relevant specifications where those methods are defined for such behavior. 5.2.4 focusin and focusout bubble, focus and blur don't. Interesting... What's the use case here? We need to make sure that the device-independent click event stays that way. Activation from 3.5 above is the same as click in the real world. Suggest adding a sentence or paragraph about how hitting enter on an activatable element fires click on that element. This would tie in nicely with the (quite good) accessibility note in this section. 5.5 Input Events "Input events are sent as notifications whenever the DOM is being updated" These used to only apply to form elements. Text should make it more clear that these apply to any element that is in an editable state. 5.7 composition events Suggest adding some text or a use case describing how these can be used for Speech Input, in addition to IMEs. 9.4 mutation events are deprecated, refers to DOM4 Mutation Observer as replacement. Custom elements is also a way to do this, or use @is on existing element. This lets you watch a particular element. Suggest adding something to the spec about this, or creating some WCAG techniques. Here are the relevant APA meeting minutes http://www.w3.org/2016/06/22-apa-minutes.html#item07
Received on Thursday, 23 June 2016 21:40:15 UTC