Touch and Pointer Guideline - WCAG WG Feedback

From Mobile Accessibility Task Force
Guideline 2.5: Touch & Pointer
Number Commenter Comment Type Status
1.1 Patrick Lauke the intent of guideline 2.5 section is slightly unfocused, as it organically grew out of initial exploration of the topic; before publication, it should be focused and tightened: the primary concern of 2.5 should be that: with the rise of mobile/tablet/touchscreen/hybrid devices, the types of inputs typically found include touch, pen/stylus, mouse, keyboard; while keyboard is already covered historically by WCAG 2.0, these additions focus specifically on touch and pointer inputs (with and without assistive technology enabled), and the specific considerations for these inputs Editorial  
1.2 Rachael Montgomery Consider adding a statement to the understanding that specifies the intent of the guideline. The current text states "This section also applies to pointer events on non-mobile platforms." but doesn't specifically state it applies to the earlier described events. Its implied but not necessarily explicit. Please consider something like "This section focuses on making it easier for users of assistive technology to use touch and pointers on mobile and non-mobile platforms." Editorial  
1.3 Makoto Ueki In "Intent of Guideline 2.5", it reads "Although the definition of "pointer" includes touch, we include touch and pointer for clarity. When we use the term touch, we just mean touch." I prefer not to include "touch" in "pointer". Even if there is the definition of "pointer", it might cause confusion. "touch", "pointer" or "touch and pointer" would be better. Definition  
1.4 Alastair Campbell The guideline explains the variety of pointers, it just feels like it should state the goal at the end. e.g. people using touch and pointer devices should be able to operate the interface easily. Editorial  
1.5 Michael Cooper Wording in "intent" makes it sounds like "pointer" does not include "touch" though it later says it does. Editorial work to clarify I think. Editorial  
1.6 Detlev Fischer Agree with Patrick that the text could be tightened. I find some sentences like "Although the definition of 'pointer' includes touch, we include touch and pointer for clarity." hard to parse.
A possible source of confusion is that on the level of Guideline 2.5, touch and mouse pointer are lumped together, while SCs 2.5.1 and 2.5.2 clearly do not apply to mouse pointer. It is just 2.5.3 and 2.5.4 where SCs apply to both mouse and touch pointer. Not sure how we can resolve this - split in two guidelines, one focused on just touch with AT turned on?		 Editorial  
2.5.1 Touch with Assistive Technology
Number Commenter Comment Type Status
2.1 Patrick Lauke 2.5.1 seems incorrect/omits details: "For example, on both iOS and Android platforms a a single swipe on the touch screen will activate the element that currently has focus. When the system screen reader is turned on, a single tap will move focus to that element and a double tap will activate the element."

this should more likely be: "For example, on both iOS and Android platforms, a single *tap* on the touch screen will activate *the tapped element*. When the system screen reader is turned on, a single tap will move focus to that element *("touch to explore"), the user can cycle through focusable elements using swipe left/right gestures,* and a double tap will activate the element."

"Don't use a common gesture for a purpose that is not common." this feels out of place, and it applies to all users, not specifically about touch with AT		 Change
2.2 Rachael Montgomery If the intent is that the functions are available in the same way, (ie that the double tap remains the method continues to activate an element after the AT is turned on) this may be worth calling out in the standard. Example: All functions available by touch remain available using the same touch gestures after platform assistive technology that remaps touch gestures is turned on. (Level A). I believe that as written, this could be read to mean that if a different touch gesture worked but the feature remained available, that would be sufficient. If that is the intent, then please disregard this. Editorial
2.3 Alastair Campbell I would note that common gestures on websites such as swipe for next photo become "illegal" with this SC. It seems like we need a list of acceptable gestures that don't clash with popular platform AT, a bit like the list of non-clashing accesskeys we used to need.... Change
2.4 Michael Cooper Might want stronger text in the proposed Understanding about letting the native OS do what it needs to do rather than attempt to make AT-compatible gestures yourself, avoiding other common gestures etc. Editorial
2.5 Detlev Fischer I suggest to change the text of 2.5.1 intent - below a draft:

"The intent of this Success Criterion is to ensure that content can still be operated using gestures on a touch screen when a built-in screen reader is turned on.
In touch interaction without screen reader, elements are usually operated through a single gesture like tapping or swiping. When a screen reader is turned on, interacting with an element involves two gestures. First, the element is focused (via touch exploration or horizontal swiping) which causes its name to be read out by the screen reader. Second, the focused element is activated via double tapping.

All functions available by touch when the screen reader is not turned on must be still available when the screen reader is turned on."

Rationale: I have avoided the term "platform assistive technology" in my draft - it has a wider scope, but this seems not helpful here because we are really just talking about screen reader interaction and not, for example, about the built-in zoom function (which has additional gestures for operating the AT but does not change the interaction mode to a two-step approach) or, say, switch control (which has different optional interaction modes).

Note that there are weird screen readers (Blackberry) that think it wise to keep default gestures working (such as swiping from sides) while also offering swipe to move focus - may be getting more irrelevant.		 Editorial / Change
2.6 James Nurthen iOS and Android both have a the concept of pass-through gestures. We need to either explicitly allow this or disallow it as a way of meeting these guidelines.

Unfortunately neither of the major vendors allows a way of a user doing a secondary or other gesture when using an HTML area other than using passthrough gestures. When using native apps you do have this ability.

Until HTML apps gain this ability there is really no way to meet this requirement in complex applications without using pass-through gestures.		 Change
2.7 Michael Elledge I found this difficult to understand. Maybe it would be clearer if it was stated as: Touch functionality remains intact if assistive technology remaps touch gestures. Editorial
2.5.2 No Touch Trap
Number Commenter Comment Type Status
3.1 Alastair Campbell Happy in isolation, but is it possible to combine this with the no-keyboard trap SC? It seems to be the same thing in principle. In fact, is it possible to pass keyboard trap and fail this? Question
3.2 Michael Cooper Yow this SC reads like a GV-written one. ;) I think it needs simplification though don't have a suggestion ATM.

I'm having a hard time understanding the "understanding" content. It's not immediately obvious how it relates to the (already complex) proposed sC. While I don't want to be dogmatic about starting all Understanding docs with "The intent of this SC is to...", I think doing so helps provide an orientation to writing the content in a way that clearly steers the reader from the SC into more in-depth understanding of the "understanding". I would say the "understanding" material right now is written more like a scratch-pad that isn't publication-ready.

Basically, because of this issue I find I can't effectively evaluate this SC. Therefore I vote against adoption, not because of opposition to the principle (as best as I sort of understand it), but because I think it isn't yet in a form that we can meaningfully adopt.		 Change
3.3 Detlev Fischer I still have trouble with this one. I agree the intent text is a bit difficult to read.

The examples seem a bit odd and need more work:

(1) the first one is no so much a trap but the inability to move focus to elements below the infinite scroll - does it belong here? Maybe a special case of trap?
(2) the second one seems odd since the swipe gesture to move to the next state of the carousel probably wouldn't work with screen reader on? The last sentence, "The user can touch outside...", may actually refer to operaton _without_ SR on?

(3) I would like to see an example implementation demonstrating the trap. Scripts may constrain focus to a pop-up by making the background inactive with aria-hidden, but the focus would then move to the browser chrome - would that still count as trap? (Compare the dialog produced when hitting the link "Display a dialog" in the following example <a rel="nofollow" href="http://www.3needs.org/en/testing/code/role-dialog-3.html">http://www.3needs.org/en/testing/code/role-dialog-3.html</a> -- if the controls here that close the dialog would be absent, would this be a trap?)		 Editorial / Change
3.4 Kim Dirks The guidance is good but the wording is a little complex. Writing these is definitely an art form, but I think we should consider making long sentences into 2+ that are shorter and more direct.

For example: This guideline applies when touch input behavior is modified by platform assistive technology and focus can be moved to a component. Users must be able to move focus away from the content via sequential navigation gestures of AT. In the alternative, the user is advised...

Something along those lines where each concept gets its own sentence.		 Editorial
3.5 Michael Elledge Again, this seems too wordy. How about: When touch input behavior is modified by assistive technology, moving focus sequentially will either be unaffected or users will be informed of an alternative. Editorial
2.5.3 Accidental Activation
Number Commenter Comment Type Status
4.1 Patrick Lauke 2.5.3 "opportunity to move a finger (or mouse/pointer)" should probably be "opportunity to move a finger/pointer" (to make touch and other pointers equally important, rather than just an afterthought for mouse/pointer that betrays the SC's origin as being purely for touch
" If touchdown activation is necessary" should be " If down-event activation is necessary" to generalise this for pointers other than touch		 Editorial / Change

4.2

 Michael Cooper Editorially, the definition of up event should be in the same doc. I want to do that sooner than later so we don't forget about it and publish something with an apparently normative reference to a wiki.

I think it needs to be clearer what the alternative case that this SC is trying to avoid is. Is it saying "don't activate on the down event"? If so, maybe just say that? With an advisory "use the up event instead" or something?

I also question if this needs to be a A level SC. It seems to go into usability-ish stuff that seems more AA to me.		 Editorial / Change
4.3 Kim Dirks Everything looks good, I just couldn't find the definition of "up-event" easily and I'm not sure everyone will know what that means. Definition
4.4 Michael Elledge Is "up-event" too jargon-y? Initially I confused with it with up-swiping. Could "when a finger or pointer is lifted" be substituted? Editorial
2.5.4 Target Size
Number Commenter Comment Type Status
5.1 Patrick Lauke "Is it appropriate to have two different sizes for touch vs. pointer?" yes, as touch is a "coarse" pointing device (due to the size of an average finger tip, and the fact that the finger generally obscures the actual touchscreen, resulting in greater difficulty in being accurate), while mouse/stylus/trackpad/trackball and other inputs of this nature are generally "fine" pointing devices that allow for greater precision. Touch Size Feedback
5.2 Alastair Campbell I don't think it is reasonable to apply different sizes for touch vs pointer, partly for people who struggle with mouse use, and partly because one interface could not reasonably have two sizes. You can't control whether people use touch or not, therefore it has to apply.

I think the minimum (44px) is reasonable, you would need good evidence to go beyond the platform recommended sizes, and I haven't seen any.

NB: I would link to the CSS3 definition of CSS Pixel, rather than defining it here.		 Touch Size Feedback
5.3 Michael Cooper Editorially I find "where px is a CSS pixel." even more awkward than the various other ways TFs have been using of cramming stuff into SC. Why not just link the "px" in the mainline part to the definition rather than add an extra clause that makes it harder to read?

I'm actually surprised this one is proposed for AA. It seems to me to be a big issue for a11y of touchscreen content, so this above all I would have thought would be A. Though maybe it's just a widespread usability issue.

On my device, content is routinely insultingly small. But if I attempt to touch a teeny tiny checkbox, the content grows to make the checkbox bigger so it can be sure I meant to touch the checkbox. It's unclear to me whether that would conform to this SC, yet I assume it's a widely used technique.

I question if there's value in having two different sizes. If we assume we can't know in advance whether people are using touch or non-touch aspects of pointer (do I have those distinctions correct? since the definition was not clear as I commented above), shouldn't we just accommodate the larger number?		 Editorial / Change
5.4 Kim Dirks I think it's good to have this standard. However, my initial reaction is that there should be one size requirement because the touch-ability of devices is growing. I'm not sure what this means for really small devices like the apple watch watches though. Question
5.5 James Nurthen Why the "at default viewport" requirement? This is way too restrictive. If I have pinch(or double tap) zoom enabled then I should be able to meet this at any zoom level.

Requiring a 44px line spacing (which this would require) for any text which might include links constrains the application design too much.

I have never seen a mobile site implement this (this includes the BBC for example where links typically have a clickable height of 16 or 17 px)

Another place where this requirement would place too much of a restriction on application design is where the smaller touch target is a secondary control. A common place where this is done is what we call an "indexer". The contacts app on the iPhone is an example. Here we have the letters A-Z on the right of the screen in a vertical layout. The touch targets for these are very small. However, in order to display all the letters this has to be so. It isn't a problem if you miss the target slightly as you can scroll up or down in the main list of contacts. It is intended to get you close to the correct location and then can correct in the main display.

If there is a minimum touch size there needs to be exemptions from it. Restricting it this much will result in less useful applications being produced.		 Change
5.6 Michael Elledge I think having two target sizes is fine and I agree that when both actions are present the default should be the larger of the two. You may want to consider input fields as a third example, in which case the touch area should include the entire field, and not a sub-section. Touch Size Feedback
5.7 Sarah J Swierenga I agree with Alastair's comments, especially the part about, "I don't think it is reasonable to apply different sizes for touch vs pointer, partly for people who struggle with mouse use, and partly because one interface could not reasonably have two sizes. You can't control whether people use touch or not, therefore it has to apply." Touch Size Feedback
Retrieved from "https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/index.php?title=Touch_and_Pointer_Guideline_-_WCAG_WG_Feedback&oldid=3287"