Proposed answer to public comment issue 157 (Touch with Assistive Technology)

Proposed answer:
Hi Scott Hollier,
The discussions around this proposed SC have shown that due to the differences between browsers and AT there may be no conclusive way to test if content meets this criterion. 

Also, the requirement seemed mostly covered by 2.1.1 Keyboard in the sense that if a control can be focused and activated with a keyboard, presumably it would also be possible to swipe to it and activate it via double tap it in a mobile screenreader scenario.

Another point is that the issue is also not exclusively related to touch, other input methods may be used concurrenty while AT is turned on. This is the topic in the new [SC 2.5.2 Concurrent Input Mechanisms](

Another new success criterion, [2.5.1 Pointer Gestures]( is meant to close the gap that exists in situations where touch is the input mode and no physical or virtual keyboard alternative is present (a virtual keyboard may not be shown on iOS unless the focus is on some text input). It requires that operation should be possible via single untimed pointer gestures  - i.e. author-defined gestures (swiping to scroll or load content in infinite scroll scenarios, etc) that may not work when AT is turned on would need a fallback way of operation.

A [new note under Conformance requirement 1 Full pages]( explains that a full page includes each variation of the page that is automatically generated by the page for various screen sizes. This would, for example, cover situations where controls in responsive views on narrow viewports cannot be focused / activated with the keyboard (possibly also causing issues when using AT).

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
Beratung, Tests und Schulungen für barrierefreie Websites

Received on Wednesday, 20 September 2017 14:59:43 UTC