Clarifying new Technique: Providing touch access for custom controls

Hi,
Yesterday in the MATF telco I picked up the task of drafting a mobile Technique which currently has the working title

"Providing touch access for custom controls".

I would just like to get your opinion on what the focus of such a technique should be. 

As ab example, I will focus on sliders. The first question to the TF is whether other custom contols would be better as examples (more important / often used in the real world). Combobox?
Can the technique address *all sorts* of custom controls or do we have to be more specific?

Here are some options for focussing the technique:

1. Focus on custom controls for which HTML5 equivalents exist.
An example would be slider controls (range) where many authors will want more control over styling than they will get with native renderings in browsers.

The general advice for controls would be: use native controls where available - platforms will then deal with it in their own way. But for better control over the design developers will often built their own custom variant - the technique focuses on those.

Without wider testing, the current situation seems to be that sliders do work with touch (like with mouse pointer) as long as the screenreader is not turned on.
Turn on for example VoiceOver, and touch fails.
Compare for example 
http://files.paciellogroup.com/blogmisc/ARIA/slider/ 

(Side note:  On Android with TalkBack, looking at http://files.paciellogroup.com/blogmisc/samples/aria/slider/ , when the thumb is focused, double tapping may change the value (move the thumb) but there is no predictable / replicable outcome).

Option 1.A 
The focus of the technique is suggesting designs for making the slider touch operable for screen reader users by making discrete intermediate steps focussable / actionable.
E.g. http://files.paciellogroup.com/blogmisc/samples/aria/slider/

An alternative approach would be placing buttons left and right of the slider [-] <slider> [+] that will be focusable and increment/decrement the range.

Another option would be to proving alternative means of setting the value addessed in the custom control (e.g. via a text input with ameaningful label). I have sseen this in action on a production site aiming to be accessible - in this case, the slider did not receive keyboard focus.


Option 1.B
The focus of the technique is on implementing standard native screenreader gestures for  custom controls. 
E.g. with VO on, the value of a native slider (range) can be set via the iOS rotor. Not sure how well that is natively supported elsewhere. It *should* work the same way for custom controls properly marked up as range, but doesn't (at least doesn't on http://files.paciellogroup.com/blogmisc/samples/aria/slider/ ). 
So the Technique would describe something that ought to work and may work soon (given improvements of AT / UA).


Option 1.C
Implementing gestures (such as multi-finger swipe or drag) known from native apps for non-discrete settings of value.
There is the issue of potential gesture conflicts with AT so I am not sure whether this shold ever be recommendad in a Technique. Even if a three finger drag could be scripted and somehow communicated as the means to increase/decrese the value, it may already be taken by some other AT (e.g. moving the enlarged section wehen Zoom is activated in iOS) so it may not work.

Option 2
Focusing on controls that have no HTML5 equivalent (Combobox? Tri-state checkbox? Spinbutton? tablist / tab?

Any thoughts?

--
Detlev Fischer
testkreis c/o feld.wald.wiese
Thedestr. 2, 22767 Hamburg

Mobil +49 (0)157 57 57 57 45
Fax +49 (0)40 439 10 68-5

http://www.testkreis.de
Beratung, Tests und Schulungen für barrierefreie Websites

Received on Friday, 4 December 2015 15:03:43 UTC