Re: [Events] UI Triggers for IndieUI Events 1.0

James Craig <jcraig@apple.com> wrote:
> + Mike Smith for his insight into the validation discussion.
> 

Excellent - thank you.
 
> @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.
> 

"trigger" seems reasonable for the default action; perhaps "manipulator" would
serve for sliders, scrolling and an open-ended class of other controls to be
added as needed.

This is only a suggestion. I'm not strongly opinionated about the terminology.
 
 [Triggers and focus]
> 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 agree this is problematic. Let's try to distinguish the cases.

1. Some, but not all,  user agents bind a key to the action associated with
the non-focusable trigger. A warning should still be issued, as there is at
least one known implementation that won't provide keyboard access to the
control. Of course, "known" is determined at the time of writing the
validator.

2. All known user agents bind a key to the action associated with the
non-focusable trigger. Unless we want to allow for future implementations
which fail to do this, no warning is required.

3. Some, or all, assistive technologies enable the action associated with the
trigger to be performed without requiring the trigger element to receive
keyboard focus. I would still argue that a warning should be issued unless
case 2 also holds, for the benefit of keyboard-only users who don't run
assistive technologies.

Maybe we should specify that keyboard bindings must be created in the common
cases (dismiss, delete, etc.), perhaps with a clause that allows for UAs that
don't support keyboard input, if there are any. The alternative is to
strengthen the authoring requirement, of course.

Are there other cases I've missed?

Received on Friday, 16 May 2014 09:15:16 UTC