View source for Touch and Pointer Guideline - WCAG WG Feedback

<table border="1">
  <caption>
    Guideline 2.5: Touch & Pointer
  </caption>
  <tr>
    <th scope="col">Number</th>
    <th scope="col">Commenter</th>
    <th scope="col">Comment</th>
    <th scope="col">Type</th>
    <th scope="col">Status</th>
  </tr>
  <tr>
    <th scope="row">1.1</th>
    <td>Patrick Lauke</td>
    <td>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</td>
    <td>Editorial</td>
    <td>&nbsp;</td>
  </tr>
  <tr>
    <th scope="row">1.2</th>
    <td>Rachael Montgomery</td>
    <td>Consider adding a statement to the understanding that specifies the   intent of the guideline. The current text states &quot;This section also   applies to pointer events on non-mobile platforms.&quot; but doesn't   specifically state it applies to the earlier described events. Its   implied but not necessarily explicit. Please consider something like   &quot;This section focuses on making it easier for users of assistive   technology to use touch and pointers on mobile and non-mobile   platforms.&quot; </td>
    <td>Editorial</td>
    <td>&nbsp;</td>
  </tr>
  <tr>
    <th scope="row">1.3</th>
    <td>Makoto Ueki</td>
    <td>In &quot;Intent of Guideline 2.5&quot;, it reads &quot;Although the definition of   &quot;pointer&quot; includes touch, we include touch and pointer for clarity. When   we use the term touch, we just mean touch.&quot; I prefer not to include   &quot;touch&quot; in &quot;pointer&quot;. Even if there is the definition of &quot;pointer&quot;, it   might cause confusion. &quot;touch&quot;, &quot;pointer&quot; or &quot;touch and pointer&quot; would   be better.</td>
    <td>Definition</td>
    <td>&nbsp;</td>
  </tr>
  <tr>
    <th scope="row">1.4</th>
    <td>Alastair Campbell</td>
    <td>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.</td>
    <td>Editorial</td>
    <td>&nbsp;</td>
  </tr>
  <tr>
    <th scope="row">1.5</th>
    <td>Michael Cooper</td>
    <td>Wording in &quot;intent&quot; makes it sounds like &quot;pointer&quot; does not include   &quot;touch&quot; though it later says it does. Editorial work to clarify I think.</td>
    <td>Editorial</td>
    <td>&nbsp;</td>
  </tr>
  <tr>
    <th scope="row">1.6</th>
    <td>Detlev Fischer</td>
    <td>Agree with Patrick that the text could be tightened. I find some   sentences like &quot;Although the definition of 'pointer' includes touch, we   include touch and pointer for clarity.&quot; hard to parse.<br />
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?</td>
    <td>Editorial</td>
    <td>&nbsp;</td>
  </tr>
</table>

<table border="1">
  <caption>
    2.5.1 Touch with Assistive Technology
  </caption>
  <tr>
    <th scope="col">Number</th>
    <th scope="col">Commenter</th>
    <th scope="col">Comment</th>
    <th scope="col">Type</th>
    <th scope="col">Status</th>
  </tr>
  <tr>
    <th scope="row">2.1</th>
    <td>Patrick Lauke</td>
    <td>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</td>
    <td>Change</td>
    <td></td>
  </tr>
  <tr>
    <th scope="row">2.2</th>
    <td>Rachael Montgomery</td>
    <td>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.</td>
    <td>Editorial</td>
    <td></td>
  </tr>
  <tr>
    <th scope="row">2.3</th>
    <td>Alastair Campbell</td>
    <td>I would note that common gestures on websites such as swipe for next   photo become &quot;illegal&quot; 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....</td>
    <td>Change</td>
    <td></td>
  </tr>
  <tr>
    <th scope="row">2.4</th>
    <td>Michael Cooper</td>
    <td>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.</td>
    <td>Editorial</td>
    <td></td>
  </tr>
  <tr>
    <th scope="row">2.5</th>
    <td>Detlev Fischer</td>
    <td>I suggest to change the text of 2.5.1 intent - below a draft:<br />
      <br />
&quot;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. <br />
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.<br />
<br />
All functions available by touch when the screen reader is not turned on   must be still available when the screen reader is turned on.&quot;<br />
<br />
Rationale: I have avoided the term &quot;platform assistive technology&quot; 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).<br />
<br />
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.</td>
    <td>Editorial / Change</td>
    <td></td>
  </tr>
  <tr>
    <th scope="row">2.6</th>
    <td>James Nurthen</td>
    <td>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.<br />
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.<br />
Until HTML apps gain this ability there is really no way to meet this   requirement in complex applications without using pass-through gestures.</td>
    <td>Change</td>
    <td></td>
  </tr>
  <tr>
    <th scope="row">2.7</th>
    <td>Michael Elledge</td>
    <td>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.</td>
    <td>Editorial</td>
    <td></td>
  </tr>
</table>
        
 <table border="1">
  <caption>
    2.5.2 No Touch Trap
  </caption>
  <tr>
    <th scope="col">Number</th>
    <th scope="col">Commenter</th>
    <th scope="col">Comment</th>
    <th scope="col">Type</th>
    <th scope="col">Status</th>
  </tr>       
        
       <tr>
    <th scope="row">3.1</th>
    <td>Alastair Campbell</td>
    <td>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?</td>
    <td>Question</td>
    <td></td>
  </tr>
       <tr>
         <th scope="row">3.2</th>
         <td>Michael Cooper</td>
         <td>Yow this SC reads like a GV-written one. ;) I think it needs simplification though don't have a suggestion ATM.<br />
           <br />
I'm having a hard time understanding the &quot;understanding&quot; 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 &quot;The intent of this SC is to...&quot;, 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   &quot;understanding&quot;. I would say the &quot;understanding&quot; material right now is   written more like a scratch-pad that isn't publication-ready.<br />
<br />
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.</td>
         <td>Change</td>
         <td></td>
       </tr>
       <tr>
         <th scope="row">3.3</th>
         <td>Detlev Fischer</td>
         <td>I still have trouble with this one. I agree the intent text is a bit difficult to read. <br />
The examples seem a bit odd and need more work:<br />
<br />
(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?<br />
(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, &quot;The user can touch outside...&quot;, may actually refer to   operaton _without_ SR on? <br />
(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 &quot;Display a dialog&quot; 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?)</td>
         <td>Editorial / Change</td>
         <td></td>
       </tr>
       <tr>
         <th scope="row">3.4</th>
         <td>Kim Dirks</td>
         <td>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. <br />
           <br />
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... <br />
<br />
Something along those lines where each concept gets its own sentence.</td>
         <td>Editorial</td>
         <td></td>
       </tr>
       <tr>
         <th scope="row">3.5</th>
         <td>Michael Elledge</td>
         <td>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.</td>
         <td>Editorial</td>
         <td></td>
       </tr>
</table>
<table border="1">
  <caption>
    2.5.3 Accidental Activation
  </caption>
  <tr>
    <th scope="col">Number</th>
    <th scope="col">Commenter</th>
    <th scope="col">Comment</th>
    <th scope="col">Type</th>
    <th scope="col">Status</th>
  </tr>       
        
       <tr>
    <th scope="row">4.1</th>
    <td>Patrick Lauke</td>
    <td>2.5.3 &quot;opportunity to move a finger (or mouse/pointer)&quot; should probably   be &quot;opportunity to move a finger/pointer&quot; (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<br />
&quot; If touchdown activation is necessary&quot; should be &quot; If down-event   activation is necessary&quot; to generalise this for pointers other than   touch</td>
    <td>Editorial / Change</td>
    <td></td>
  </tr>
       <tr>
         <th scope="row"><p>4.2</p></th>
         <td>Michael Cooper</td>
         <td>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.<br />
           <br />
I think it needs to be clearer what the alternative case that this SC is   trying to avoid is. Is it saying &quot;don't activate on the down event&quot;? If   so, maybe just say that? With an advisory &quot;use the up event instead&quot; or   something?<br />
<br />
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.</td>
         <td>Editorial / Change</td>
         <td></td>
       </tr>
       <tr>
         <th scope="row">4.3</th>
         <td>Kim Dirks</td>
         <td>Everything looks good, I just couldn't find the definition of &quot;up-event&quot;   easily and I'm not sure everyone will know what that means. </td>
         <td>Definition</td>
         <td></td>
       </tr>
       <tr>
         <th scope="row">4.4</th>
         <td>Michael Elledge</td>
         <td>Is &quot;up-event&quot; too jargon-y? Initially I confused with it with   up-swiping. Could &quot;when a finger or pointer is lifted&quot; be substituted?</td>
         <td>Editorial</td>
         <td></td>
       </tr>
</table>
   <table border="1">
  <caption>
    2.5.4 Target Size
  </caption>
  <tr>
    <th scope="col">Number</th>
    <th scope="col">Commenter</th>
    <th scope="col">Comment</th>
    <th scope="col">Type</th>
    <th scope="col">Status</th>
  </tr>       
        
       <tr>
    <th scope="row">5.1</th>
    <td>Patrick Lauke</td>
    <td>&quot;Is it appropriate to have two different sizes for touch vs. pointer?&quot;   yes, as touch is a &quot;coarse&quot; 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 &quot;fine&quot; pointing devices that allow for greater precision.</td>
    <td>Touch Size Feedback</td>
    <td></td>
  </tr>
       <tr>
         <th scope="row">5.2</th>
         <td>Alastair Campbell</td>
         <td>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.<br />
           <br />
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.<br />
<br />
NB: I would link to the CSS3 definition of CSS Pixel, rather than defining it here.</td>
         <td>Touch Size Feedback</td>
         <td></td>
       </tr>
       <tr>
         <th scope="row">5.3</th>
         <td>Michael Cooper</td>
         <td>Editorially I find &quot;where px is a CSS pixel.&quot; even more awkward than the   various other ways TFs have been using of cramming stuff into SC. Why   not just link the &quot;px&quot; in the mainline part to the definition rather   than add an extra clause that makes it harder to read?<br />
           <br />
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.<br />
<br />
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.<br />
<br />
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?</td>
         <td>Editorial / Change</td>
         <td></td>
       </tr>
       <tr>
         <th scope="row">5.4</th>
         <td>Kim Dirks</td>
         <td>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. </td>
         <td>Question</td>
         <td></td>
       </tr>
       <tr>
         <th scope="row">5.5</th>
         <td>James Nurthen</td>
         <td>Why the &quot;at default viewport&quot; 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.<br />
Requiring a 44px line spacing (which this would require) for any text   which might include links constrains the application design too much. <br />
<br />
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)<br />
<br />
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   &quot;indexer&quot;. 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.<br />
<br />
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.</td>
         <td>Change</td>
         <td></td>
       </tr>
       <tr>
         <th scope="row">5.6</th>
         <td>Michael Elledge</td>
         <td>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.</td>
         <td>Touch Size Feedback</td>
         <td></td>
       </tr>
       <tr>
         <th scope="row">5.7</th>
         <td>Sarah J Swierenga</td>
         <td>I agree with Alastair's comments, especially the part about, &quot;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.&quot;</td>
         <td>Touch Size Feedback</td>
         <td></td>
       </tr>
</table>