Re: [Events] UI Triggers for IndieUI Events 1.0

On May 16, 2014, at 2:14 AM, Jason White <jason@jasonjgw.net> wrote:

> 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.

@uimanipulator works. Good suggestion.

> 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.

I've made ACTION-86 to incorporate validation requirements, starting with this list.

ACTION-86: Validator requirements in spec
https://www.w3.org/WAI/IndieUI/track/actions/86

> 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.

I like it, though we'll have to word this carefully to avoid dictating what the specific key bindings are. We need to leave this open for locale-, platform-, and device-independence as the charter . We might be able to phrase it something like this:

User agents that support keyboard-based navigation MUST provide key mappings that initiate the following user interface action requests. User agents MAY use different key mappings depending on locale, platform, and device-specific interaction patterns. Any key mapping will be considered a conforming implementation.

Then we could list the actions with informative suggested key mapping defaults. delete->delete, dismiss->esc, etc. Since this is informative, it should be a living document outside the spec. And should be flexible enough to account for the cross-platform complexities of markrequest. For example, 

Nice-to-have: Consider a way to query the DOM interface to determine what the key mapping is for a specific action, so that help text could be generated to include user-unique instructions. Filed as ACTION-87 against Future Release (post 1.0).

James

Received on Friday, 16 May 2014 12:29:10 UTC