Re: Indicating swipe actions on an element

Moving to Indie UI list. cc/ Eitan.

On May 21, 2014, at 10:28 PM, Marco Zehe <marco.zehe@googlemail.com> wrote:

> Hi all!
> 
> While making the UI for Firefox OS accessible, we're running into the situation where we need to indicate that an item can not only be activated in the normal way, but that certain swipe actions can also be performed. An analogous example can be found in iOS in the status bar, when VoiceOver is active:
> 
> 1. In many cases, double-tapping any status bar icon scrolls the main view all the way to the top.

This is just a default action, effectively click. (How a custom web scroll view registers for the resulting scroll is a related, but separate conversation.)

> 2. At the same time, swiping down with 3 fingers while any of the status bar items has accessiblity focus will bring up the notification center.
> 3. And 3 finger swipe upwards will bring up the control center (in iOS 7 and above).

These are just semantic scroll gestures on iOS, because the interfaces that they bring up (NC and CC) scroll in from the bottom or top. Therefore, the equivalent semantic event in web UI is already covered by IndieUI "scrollrequest" with an enum ScrollRequestScrollType value of "up"/"pageUp" or "down"/"pageDown". 

The same can be accomplished using the "scroll" keyboard commands (Opt+Up or Opt+Down) with VO Quick Nav. The semantic scroll events are not limited to or specific to gestures, and IndieUI makes a point to be agnostic of the specific physical interface used to trigger one of these events.

> We'd like to see a semantic means be added to WAI-ARIA to specify that a user can execute the accessible form of a swipe to perform additional actions.
> 
> Initial thinking goes along the lines of a new attribute called aria-swipedirection with an atomic list of valid attribute values of "up", "down", "left" and "right".

A directional swipe is not a semantic event. It may mean a particular semantic event in certain circumstances though. Please outline what these are, and if they are missing from IndieUI, we may have a course of action. 

Even if IndieUI doesn't cover these cases, declarative DOM attribute doesn't provide enough information. You'd need to register for a new event type anyway, and you'd probably end up with something like IndieUI, or additional physical DOM events.

> When specified, assistive technologies can assume that, when a particular swipe action is being requested by them, the element would be behaving accordingly.

This seems like another hole in the proposal. IndieUI covers this by stating that AT should only assume the action is handled when the appropriate related event has be canceled by the web app using preventDefault().

> In addition, this would allow assistive technologies to provide tutor messages similar to what can be heard spoken by VoiceOver in iOS when a status bar icon is touched.

I'm positive that IndieUI already covers the interaction portion of this.

What may not be covered is the ability for a web app to provide a hint that is unique to a specific request type or value. E.g. an element can listen for "click" and "scrollrequest" but there is no way for a screen reader to tell the user what the result of clicking or scrolling will be. That could potentially be part of ARIA, or it could be an extension to UIEvent (DOM) or UIRequestEvent (IndieUI).


> The attribute would be applicable to any element that the author intends to react to swiping gestures (for example swipe left to delete an item, swipe down open the notifications etc.).

If the author registered for a "deleterequest" and FirefoxOS determined that a "leftward swipe" means delete, then it could initiate the delete request.

> Points I'm not sure about:
> 1. How this would map to platform APIs other than an object attribute (like in IA2 and ATK). Probably something that can be covered by an IndieUI supported action set.

IMO, specific physical events should never map to platform APIs that don't support that specific physical interface. Abstracted events seem like a better fit for what you are requesting.

> 2. It's very specific to touch interfaces.

I don't agree that this is specific to touch interfaces. Outline what the semantic events are, and if they are missing from IndieUI, we may have a course of action. 

Since you used the VoiceOver example earlier, another example is an upward or downward swipe on a slider or stepper. The semantic event is to change the value of the slider. It has nothing to do with the specific physical touch event, which could also be accomplished by pressing the up or down arrow keys on a keyboard. Note: This is an IndieUI "valuechangerequest" with an enum ValueChangeRequestChangeType of "increment" or "decrement".


> But then, so is role "key" that we also proposed. :-)

What is the subject line of your role="key" proposal? I must've missed it.

Fair warning, I'll probably take issue with any proposal that is specific to a single physical interface. To put it in perspective, having a role specific to touch seems as bad an idea to me as having a role specific to sight. That said, I'm confident we can find a solution the UI problems you're attempting to overcome.

James


> This is not a formal proposal yet.
> 
> Thoughts?
> 
> Marco
> 
>

Received on Thursday, 22 May 2014 07:45:09 UTC