Re: [Events] UI Triggers for IndieUI Events 1.0

+ Mike Smith for his insight into the validation discussion.

For context Mike, we're discussing the new "UI Triggers" section in this document:
https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-events.html#triggers

On May 15, 2014, at 3:24 AM, Jason White <jason@jasonjgw.net> wrote:

> James Craig <jcraig@apple.com> wrote:
>> Substantial edits made today/tonight covering the @uittrigger idea we've been discussing over the past few months. 
>> 
>> In addition to the rest of the edits, I'd appreciate a critical, technical review of this new section, entitled "UI Triggers."
> 
> Thank you, James, for your excellent work in specifying the new feature.
> Consider the following comments "post-heartbeat" material - that is, they
> needn't be addressed before publishing the heartbeat draft.

Thanks for the quick response.

> 1. The text states explicitly that UIManipulationRequestEvent types are not
> included in the set of tokens available as values of uitrigger, because
> additional parameters not expressible as simple tokens are needed in these
> cases.
> 
> It follows that the motivating example for the uitrigger feature, the slider
> (operated by move events targeting the slider thumb) isn't covered. It needs
> to be addressed, however, then reinstated as an example in the spec. As I
> remember, the trigger element responds to move requests by dispatching value
> change requests, and we need to define the relationship between deltas in the
> move request and the the corresponding value change.

@uittrigger is only the first half of ACTION-79. The term trigger usually refers to things that you can "trigger" with a single discrete action like a click, not continuous control like a slider thumb. I've been referring to the second piece as a "UI controller" (@uicontroller), but we need a better term. "Controller" means something entirely different in common programming vernacular, so it should be named something else. "UI Thumb" is obvious but probably too specific to sliders and scrollbars. I'm calling the attribute "control for" (@uicontrolfor) at the moment. We might also consider using "trigger for" (@uitriggerfor) as well, but I'm not set on the terminology since this would mean "for an action" not "for an element" like ARIA. Also considering "controls action" and "triggers action". Please suggest a better name if you think of one.

I can't get this part fully specified the heartbeat, but I'm working on a stubbed placeholder section with some editorial notes outlining the ideas. I can get the stub in for the heartbeat at least.

> 2. The text, as drafted, states that the trigger element need not be focusable
> if, for example, there is an access key assigned to the operation. This makes
> sense if focus means "keyboard focus", but I'm wondering whether there are any
> other input methods that rely on focus (e.g., sequential navigation in a touch
> interface) rather than merely on point-of-regard. On the systems that I have
> used, sequentially navigating UI controls in a touch interface simply changes
> point-of-regard, not focus, so the text as it stands may be fine - we're only
> concerned about focus in relation to keyboard input, but I would still suggest
> checking for possible counter-examples where this could be a problem. I don't
> think speech input relies on focus either, for instance, thus perhaps all
> non-keyboard inputs are covered without the element's having to be focusable.

I expected a comment on this one. Like you, I'm not 100% sure we should keep this requirement, and I'd agree to modify or remove it if we can predict a serious failure case. There are normative requirements for role and label on triggers, so as you suspected, assistive technologies such as switch interfaces and screen readers should still be able to navigate to the trigger even if it's not keyboard-focusable, or otherwise send the appropriate action directly via the event receiver.

Let me explain some of the logic behind the related normative statements, paraphrased here:

1. ~"Authors SHOULD make triggers focusable." This allows validators to throw warnings. 
2. ~"Authors MAY forego focusable triggers *if* the triggered functionality is otherwise keyboard accessible." This limits the ability of validators to throw warnings, but not entirely. It's the escape clause for legitimately redundant scenarios, but is phrased to allow validators the ability to conditionally throw errors if it can detect that the trigger is not focusable and there is no keyboard support for the action on the current platform. I don't know if this will be determinable in all situations, but conditional warnings should be possible in many scenarios. 

Perhaps we should add a third normative requirement to that set:

3. Something like ~"Validation software SHOULD throw a warning if native keyboard support is not provided for the associated action of a non-focusable trigger element." The hard part about this is that the validator would either have to be aware of all independent platform interfaces and levels of support (impossible) or the validation software may have to be specific to and running on the user's system. The former is likely unachievable. The latter is achievable but may provide a false sense of security. An error may still exist, even if it's not reliably detectable. This is just a reality of software, particularly related to accessibility. 

I'm trying to leave the normative requirements open enough allow flexibility, while constrained enough to allow some programmatic detection of problem scenarios.

> 3. There are minor errors worthy of cleaning up before publishing the new
> section. This point probably should be addressed before the heartbeat draft.

I assume you mean typographical and grammatical errors. I'm cleaning these up as I find them. Feel free to email me off-list with any editorial errors I've missed. If you mean minor but normative errors, please let me know any you find. Please always refer to the latest ED.

> 4. I think informative text should be added that explains the differences
> between uitrigger and uiactions, and gives the rationale for each. I expect
> these attributes to be a source of confusion unless their respective purposes
> are clearly delineated.

Good suggestion. 

Thank,
James

Received on Friday, 16 May 2014 08:30:58 UTC