Re: AW: Rough draft of some success criteria for a extension guideline "Touch accessible"

On 28/07/2015 16:04, Detlev Fischer wrote:
> Thanks for pointing again to this great resource! Looking at the
> tables, I wasn't quite sure what 1st activation vs. 2nd activation
> stands for - as for using screen readers on mobile, I assume that 1st
> activation = swiping left/right, 2nd activation = making a double-tap
> to activate? And on the first table, I wasn't sure how 1st tap and
> 2nd tap would be spaced - would that be a quick double tap (below 300
> ms) to trigger browser zoom?  This may be obvious for others, but I
> am not sure.

Leaving AT aside for a moment, there are subtle differences (mainly 
around whether or not a focus event is fired) between, say, tapping a 
button once on a touchscreen, and then tapping it again (not a 
double-tap, but just a second "click" if you will). This is a bit more 
obvious when there's no AT in play, see the difference of events between 
1st and 2nd tap just for touchscreen (no AT) 
http://patrickhlauke.github.io/touch/tests/results/#mobile-tablet-touchscreen-events

In the case of touch+AT, I also include a first "Move to button" column. 
This is the "swipe left/right to set focus to the button" scenario, 
where I test whether or not the browser even fires a focus event when 
the user swipes TO the button. So:

- swipe left/right to set VoiceOver/TalkBack/Narrator/etc focus to the 
control = move to button (this column isn't there for the basic 
"touchscreen on mobile/tablet or desktop, but no assistive tech" 
scenario, as you obviously don't "move" to the button as such, you just 
tap it if you want to activate it)
- double-tap (with AT) once to activate = 1st activation
- wait a second, then double-tap again = 2nd activation
- swipe left/right to move away from the control = leave button

> That's a good point. Thinking of the perspective of an AT user
> carrying out an accessibility test, or even any non-programmer
> carrying out a heuristic accessibility evaluation using browser
> toolbars and things like Firebug, I wonder what is implied in making
> that distinction, and how it might be reflected in documented test
> procedures. Are we getting to the point where it becomes impossible
> to carry out accessibility tests without investigating in detail the
> chain of events fired?

I think conceptually we get into the same grey area as JAWS etc on 
desktop, which "swallow" key presses unless they're in application/forms 
mode. A developer/tester needs to understand that once AT is running, 
swipes/gestures on a touchscreen and key presses (be it on desktop, 
tablet with a paired keyboard, etc) may well be intercepted by the AT, 
so can't rely on them.

> One important difference being that swiping on mobile also gets to
> non-focusable elements. While a script may keep keyboard focus safely
> inside a pop-up window, a SR user may swipe beyond that pop-up
> unawares (unless the page background has been given the aria-hidden
> treatment, and that may not work everywhere as intended).

Good point. Still wonder if this can be "genericised" somehow to cover 
different ways (not just different input modalities) in which users can 
navigate/interact with content (think for instance a "Jump to a landmark 
/ link / heading" type dialog provided by AT, which will foil any 
attempt at naive focus management in a popup just the same way).

> Assuming a non-expert perspective (say, product manager, company
> stategist), when looking at Principle 2 Operable it would be quite
> intelligible to talk about 2.1 Keyboard Accessible 2.5 Touch
> Accessible 2.6 Pointer Accessible (It's not just Windows and Android
> with KB, Blackberry has a pointer too) 2.7 Voice Accessible

My concern here is that this won't scale in the long run. Kinect 
accessible? Gamepad accessible? Voice command accessible? Instead, 
wondering if at least a rough generalisation/categorisation of input 
modalities would be a bit more future proof. Something like

Principle 2 Operable
2.1 Operable with a pointer interface [which would include generic 
advice for mouse, touch, stylus, etc]
2.2 Operable with a non-pointer interface [including keyboard, switch 
access, voice?, gestural interfaces like Kinect?]

Just want to avoid a ballooning of core sections and a danger of the 
whole list out-of-touch (pardon the pun) once a new input modality comes 
around.

> While the input modes touch and pointer share many aspects and (as
> you show) touch events are actually mapped onto mouse events, there
> might be enough differences to warrant different Guidelines. For
> example, you are right that there is no reason why target size and
> clearance should not also be defined for pointer input, but the
> actual values would probably be slightly lower in a "Pointer
> accessible" Guideline.

Sure, the values might be different, but the principle and SC are the 
same in my view: can the user operate this comfortably or not? In the 
actual text for the SC, we can then give different values for different 
scenarios. "For touch interfaces, the touch target size must be at least 
8mm (though let's be clear what we actually mean here by "mm" ... a CSS 
"mm"? or a physical "mm", which is impossible to detect/enforce via CSS? 
maybe better to use dips/device independent pixels as a measure). For 
mouse and stylus, it must be at least 5mm".

This is not dissimilar to, say, 1.4.3 where different values are given 
for regular and "large" text (though it's not written very gracefully, 
as the latter is written as an exception - I'd tend to favor generic 
language in the main SC wording, a la "controls have a sufficiently 
large activation target size in order to be comfortably operated with a 
pointer", and then give specific measurements in bullet points for each 
pointer type).

> A SC for touch might
> address multi-touch gestures, mouse has no swipe gesture.

Again here we need to be careful. Whose gestures are we talking about? 
Implemented by the page/content developer? In that case, there are 
examples of mouse swipe interfaces around. Implemented at user agent 
level? Those are outside the control of page authors (same as, say, AT 
gestures) (and some browsers do have mouse gestures like that, e.g. old 
Opera).

Also, there are multi/mixed input scenarios that allow for combined 
interactions (say, on my laptop, I can use touch AND mouse AND 
keyboard). Where would these fall within a hard categorisation by input 
mode? I'd prefer a more generalised way of covering those too.

> SCs under
> Touch accessible may also cover two input modes: default (direct
> interaction) and the two-phase indirect interaction of focusing, then
> activating, when the screenreader is turned on.

Hmm, good point, had not considered separating those interaction models. 
Wondering if direct/two-phase would also apply to other 
non-keyboard/pointer-like interfaces, like Voice or Kinect...

> Of course it might be more elegant to just make Guideline 2.1 input
> mode agnostic, but I wonder whether the resulting abstraction would
> be intelligible to designers and testers. I think it would be
> worthwhile to take a stab at *just drafting* an input-agnostic
> Guideline 2.1 "Operable in any mode" and draft SC below, to get a
> feel what tweaking core WCAG might look like, and how Success
> criteria and techniques down the line may play out.

Once I have some headspace, I'm happy to try and draft something out.

> I'd really be curious how that 'smoothing out' of input-specific
> adivce would actually look like in a standard that is phrased in a
> generally understandable and technology-agnostic manner.
>
> Having modular extensions might be handy when testers make
> conformance checks along particular defined accessibility baselines.
> For example, some old-fashioned company has an intranet app used only
> on Windows 7 (8,10) with IE/Edge and JAWS. It picks core WCAG for its
> conformance check. Another company has field reps using an intranet
> app also on tablets. Here, WCAG conformance may be checked for core
> WCAG 2.0 plus the Touch and Voice extensions.

Danger, of course, is that companies will choose the least amount of 
checks needed for them to get a gold star at the end, and see touch, 
voice, etc as an "extra". But that's a different discussion :)

> In my view, your intervention is most welcome and doesn't at all come
> across as confrontational!

Good stuff. I'll try harder next time ;)

P
-- 
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

Received on Tuesday, 28 July 2015 16:11:10 UTC