W3C

Site Navigation

Nearby

Results of Questionnaire Touch & Pointer Guideline Feedback

The results of this questionnaire are available to anybody. In addition, answers are sent to the following email address: kathy@interactiveaccessibility.com

This questionnaire was open from 2016-05-09 to 2016-06-25.

14 answers have been received.

Jump to results for question:

  1. Guideline 2.5: Touch and Pointer
  2. 2.5.1 Touch with Assistive Technology
  3. 2.5.2 No Touch Trap
  4. 2.5.3 Accidental Activation
  5. 2.5.4 Target Size

1. Guideline 2.5: Touch and Pointer

Guideline 2.5: Touch and Pointer: Make it easier for users to operate touch and pointer functionality.

Summary

ChoiceAll responders
Results
I am happy with this guideline. 7
I recommend the following changes. 7
I don't think this should be a WCAG guideline for the following reasons.
I don't have any comments.

Details

Responder Guideline 2.5: Touch and PointerComments
Patrick Lauke I recommend the following changes. - 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






Rachael Bradley Montgomery I recommend the following changes. 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."
David MacDonald I am happy with this guideline.
Makoto Ueki I recommend the following changes. 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.
Alastair Campbell I recommend the following changes. 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.
Michael Cooper I recommend the following changes. Wording in "intent" makes it sounds like "pointer" does not include "touch" though it later says it does. Editorial work to clarify I think.
Marc Johlic I am happy with this guideline.
Detlev Fischer I recommend the following changes. 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?
Kim Dirks I am happy with this guideline.
James Nurthen I am happy with this guideline.
Michael Elledge I am happy with this guideline.
Laura Carlson I am happy with this guideline.
Sarah J Swierenga I am happy with this guideline.
Joshue O'Connor I recommend the following changes. #In the first line should "Platforms today can be operated through a number of different devices including touch, stylus, pen, in addition to mouse and keyboard." be:

"Web content today can be operated through a number of different devices including touch, stylus, pen, in addition to mouse [..]

Just so the author can see the focus is on content, and the use of platform etc is only to show the wider context/applicability of the SC. Actually this opening sentence seems like a dupe of the third sentence..

#I don't understand why this sentence is so verbose:
"Mobile device design has evolved away from built-in physical keyboards (e.g. fixed, slide-out) towards devices that maximize touchscreen area and display an on-screen keyboard only when the user has selected a user interface control that accepts text input (e.g. a textbox). "

It could just say "Mobile device design has evolved away from built-in physical keyboards (e.g. fixed, slide-out) towards devices that maximize touchscreen area and display an on-screen keyboard." The reference to the mouse seems redundant.

# Change to: Although the definition of "pointer" by default includes touch, we explicitly include the terms 'touch and pointer' here for clarity. If 'touch' is used it relates to 'touch' devices/events only.

#Its not clear to me when it says "2.5.1 Touch with Assistive Technology: All functions available by touch[...] - are we talking about touch events? I think this should be clarified somewhere (if it ins't already and I just missed it).

#2.5.1 I think this needs a rewrite/simplification: Touch with Assistive Technology: All functions available by touch are still available after assistive technology touch gesture remapping.

Would this be clearer?

# I suggest putting this second sentence first: So:

Some assistive technology such as a screen reader will change the gestures that are used to interact with content when it is turned on. The intent of this Success Criterion is to ensure that content can be operated using gestures on a touch screen with platform assistive technology.

and then the example.

#+1 to Patricks comment about"on both iOS and Android platforms a a single swipe on the touch screen will activate the element that currently has focus. " as swiping will only give focus most of the time, right?

#I also suggest moving this sentence closer to the top of the paragraph, maybe even make it the second sentence. "All functions available by touch when the platform assistive technology is not turned on must be still available when the platform assistive technology is turned on." - as this is a clear problem/solution type statement.

As an aside reading the techniques don't they don't really seem to clearly explain how to satisfy this SC? http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/M027 I wasn't really any the wiser about what to do if I was a mobile dev tbh.

2. 2.5.1 Touch with Assistive Technology

All functions available by touch are still available by touch after platform assistive technology that remaps touch gestures is turned on. (Level A)

Summary

ChoiceAll responders
Results
I am happy with this success criterion. 7
I recommend the following changes. 6
I don't think this should be a WCAG success criterion for the following reasons.
I don't have any comments.

(1 response didn't contain an answer to this question)

Details

Responder 2.5.1 Touch with Assistive TechnologyComments
Patrick Lauke I recommend the following changes. - 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
Rachael Bradley Montgomery I recommend the following changes. 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.
David MacDonald I am happy with this success criterion.
Makoto Ueki I am happy with this success criterion.
Alastair Campbell I am happy with this success criterion. 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....
Michael Cooper I recommend the following changes. 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.
Marc Johlic I am happy with this success criterion.
Detlev Fischer I recommend the following changes. 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.
Kim Dirks I am happy with this success criterion.
James Nurthen I recommend the following changes. 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.
Michael Elledge I recommend the following changes. 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.
Laura Carlson I am happy with this success criterion.
Sarah J Swierenga I am happy with this success criterion.
Joshue O'Connor

3. 2.5.2 No Touch Trap

When touch input behavior is modified by platform assistive technology and focus can be moved to a component, then focus can be moved away from the component using sequential navigation gestures of assistive technology or the user is advised of the method for moving focus away in the sequential focus order. (Level A)

Summary

ChoiceAll responders
Results
I am happy with this success criterion. 6
I recommend the following changes. 4
I don't think this should be a WCAG success criterion for the following reasons. 1
I don't have any comments. 2

(1 response didn't contain an answer to this question)

Details

Responder 2.5.2 No Touch TrapComments
Patrick Lauke I don't have any comments.
Rachael Bradley Montgomery I don't have any comments.
David MacDonald I am happy with this success criterion.
Makoto Ueki I am happy with this success criterion.
Alastair Campbell I am happy with this success criterion. 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?
Michael Cooper I don't think this should be a WCAG success criterion for the following reasons. 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.
Marc Johlic I am happy with this success criterion.
Detlev Fischer I recommend the following changes. 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 http://www.3needs.org/en/testing/code/role-dialog-3.html -- if the controls here that close the dialog would be absent, would this be a trap?)
Kim Dirks I recommend the following changes. 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.
James Nurthen I am happy with this success criterion.
Michael Elledge I recommend the following changes. 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.
Laura Carlson
Sarah J Swierenga I am happy with this success criterion.
Joshue O'Connor I recommend the following changes. #The SC text is convoluted and too long. "No Touch Trap: When touch input behavior is modified then focus can be moved away from the component using sequential navigation gestures of assistive technology or the user is advised of the method for moving focus away in the sequential focus order. (Level A) "

I don't think the sentence "by platform assistive technology and focus can be moved to a component," adds anything and is implicit?

#I think the first sentence is redundant. "Swipe gestures are useful for displaying dynamic content.

#How about removing "via a swipe gesture also" again, it's implicit. So with an edit it would be "Giving focus to dynamic content needs a gesture or method to move focus back to prior content~ I also think this last sentence can be removed "— either by swiping to return or by informing the user of the method needed to return."

#This should be in a call-out box, as it's an important point."Explore-by-touch is not a valid solution, because the user can then miss content without knowing it was missed." there could also be links to examples/deeper text explanations.

#This success criterion covers all sequential navigation methods and compensates for touch-specific failure criteria (unlike WCAG 2.1.2 No Keyboard Trap). Relying on touch [alone] to explore features of mobile ATs to escape such a trap is still a failure under this criteria.

Josh comment: I'm not sure what 'to explore features of mobile ATs' means?
I think these following points should be bullets:

This is because:
1)The next sequential item may be offscreen and explore-by-touch gesture may cause users to get lost on the page.
2) The user may be relying on other means of sequential navigation such as a keyboard or switch control.

Finally, for the 'Examples' it is hard to know if these are examples that pass/fail this SC?

4. 2.5.3 Accidental Activation

For single touch and pointer activation, at least one of the following is true: (Level A)

  1. Activation is on the up-event, either explicitly or implicitly as a platform's generic activation/click event;
  2. A mechanism is available that allows the user to choose the up-event as an option;
  3. Confirmation is provided, which can dismiss activation;
  4. Activation is reversible; or
  5. Timing of activation is essential and waiting for the up-event would invalidate the activity.

Summary

ChoiceAll responders
Results
I am happy with this success criterion. 5
I recommend the following changes. 5
I don't think this should be a WCAG success criterion for the following reasons.
I don't have any comments. 2

(2 responses didn't contain an answer to this question)

Details

Responder 2.5.3 Accidental ActivationComments
Patrick Lauke I recommend the following changes.
- 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
Rachael Bradley Montgomery I don't have any comments.
David MacDonald I am happy with this success criterion.
Makoto Ueki I don't have any comments.
Alastair Campbell I am happy with this success criterion.
Michael Cooper I recommend the following changes. 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.
Marc Johlic I am happy with this success criterion.
Detlev Fischer
Kim Dirks I recommend the following changes. 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.
James Nurthen I am happy with this success criterion.
Michael Elledge I recommend the following changes. Is "up-event" too jargon-y? Initially I confused with it with up-swiping. Could "when a finger or pointer is lifted" be substituted?
Laura Carlson
Sarah J Swierenga I am happy with this success criterion.
Joshue O'Connor I recommend the following changes. # Activation is on the up-event, either explicitly or implicitly as a platform's generic activation/click event;
A mechanism is available that allows the user to choose the up-event <del>as an option;</del>

# I'd add these two sentences together for clarity.

Note: This success criteria applies when platform assistive technology (e.g. screen reader) that remaps touch gestures is not turned on. Up-event activation refers to the activation of a component when the trigger stimulus is released.

Then continue with the text.

#There is [therefore] a distinction between a finger initially touching a place on the screen and a finger being lifted from that place on the screen.

#Authors can reduce inadvertent triggering of an action by restricting the activation on the up-event.

# Remove, unnecessary/implied : "This gives the user the opportunity to move a finger (or mouse/pointer), away from a wrong target that's been hit."

#Generic platform activation/click events <del>generally</del> trigger on up and when they do, are also allowed.

5. 2.5.4 Target Size

The size of the target in relation to the visible display at the default viewport size is at least: (Level AA)

  • 44px by 44px for touch inputs
  • 20px by 20px for mouse/pointer inputs

where px is a CSS pixel.

Note: In situations where both touch and pointer/mouse input mechanisms are present, without manual or automatic input detection, controls must follow the larger minimum dimensions for touch input.

Note: This success criteria applies when platform assistive technology (e.g. magnification) is not turned on.

We are researching the 20px value for mouse/pointer and 44px for touch. We are seeking research on this and outside input. We also have to define the difference between a touch event and a mouse event, particularly in html and responsive environments. View our research and the taskforce discussions on touch and pointer.

Please let us know your thoughts on the following questions

  • Is it appropriate to have two different sizes for touch vs. pointer?
  • Are the minimum sizes being proposed sufficient for people with dexterity or fine motor coordination disabilities?

Summary

ChoiceAll responders
Results
I am happy with this success criterion. 4
I recommend the following changes. 5
I don't think this should be a WCAG success criterion for the following reasons. 1
I don't have any comments. 1

(3 responses didn't contain an answer to this question)

Details

Responder 2.5.4 Target SizeComments
Patrick Lauke I am happy with this success criterion. "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.

Rachael Bradley Montgomery I don't have any comments.
David MacDonald I am happy with this success criterion.
Makoto Ueki
Alastair Campbell I recommend the following changes. 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.
Michael Cooper I recommend the following changes. 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?
Marc Johlic I am happy with this success criterion.
Detlev Fischer I am happy with this success criterion.
Kim Dirks I don't think this should be a WCAG success criterion for the following reasons. 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.
James Nurthen I recommend the following changes. 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.
Michael Elledge I recommend the following changes. 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.
Laura Carlson
Sarah J Swierenga I recommend the following changes. 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."
Joshue O'Connor

More details on responses

  • Patrick Lauke: last responded on 23, May 2016 at 20:31 (UTC)
  • Rachael Bradley Montgomery: last responded on 23, May 2016 at 23:03 (UTC)
  • David MacDonald: last responded on 24, May 2016 at 03:31 (UTC)
  • Makoto Ueki: last responded on 24, May 2016 at 09:28 (UTC)
  • Alastair Campbell: last responded on 24, May 2016 at 12:20 (UTC)
  • Michael Cooper: last responded on 24, May 2016 at 13:55 (UTC)
  • Marc Johlic: last responded on 24, May 2016 at 14:55 (UTC)
  • Detlev Fischer: last responded on 24, May 2016 at 17:04 (UTC)
  • Kim Dirks: last responded on 25, May 2016 at 13:51 (UTC)
  • James Nurthen: last responded on 8, June 2016 at 21:28 (UTC)
  • Michael Elledge: last responded on 13, June 2016 at 19:56 (UTC)
  • Laura Carlson: last responded on 14, June 2016 at 15:09 (UTC)
  • Sarah J Swierenga: last responded on 14, June 2016 at 15:32 (UTC)
  • Joshue O'Connor: last responded on 23, June 2016 at 19:53 (UTC)

Non-responders

The following persons have not answered the questionnaire:

  1. Kimberly Patch
  2. Mike Pluke
  3. Jonathan Avila
  4. Jatin Vaishnav
  5. Kevin White
  6. Victoria Clark
  7. Melanie Philipp
  8. Ruoxi Ran
  9. Charles Adams
  10. Jamie Herrera
  11. Audrey Maniez
  12. Joe Humbert
  13. Alain Vagner
  14. Perrin Anto
  15. Rachele DiTullio
  16. Jan Jaap de Groot
  17. Michael Keane
  18. Devanshu Chandra
  19. Julia Kim
  20. Quintin Balsdon
  21. Carolina Crespo
  22. Bram Janssens
  23. Jeroen Hulscher
  24. Jeanne Erickson Cooley
  25. Gert-Jan Vercauteren
  26. Karla Rubiano
  27. Aashutosh K
  28. Hidde de Vries
  29. Julian Kittelson-Aldred
  30. Mike Pedersen

Send an email to all the non-responders.

Compact view of the results / list of email addresses of the responders

WBS home / Questionnaires / WG questionnaires / Answer this questionnaire

Report issues on GitHub project w3c/wbs-design or by mail to sysreq.