Re: Issue of the new Success Criterion 2.5.3 vs. WCAG 3.2.1

This 2.5.3 SC (activation on touchend) originated in the BBC Mobile Accessibility Guidelines. One could argue that at least the non-IT case s more a usability failure as it affects everyone.

I wonder whether elements that fire on touch start in non-AT mode would actually behave differently when AT is active. My guess is they won"t and both need a double tap to fire, but that could be tested.

Detlev

On 25 Feb 2016, at 19:28, Chris McMeeking <chris.mcmeeking@deque.com> wrote:

> Also, an important distinction between 3.2.1 and 2.5.3, is that 3.2.1 uses the phrase "onFocus".  This means something very specific in web development, that is not necessarily implied the scenario 2.5.3 is addressing.  The proposed 2.5.3 events are not specifically referring to onFocus events, but rather hover, touch, and other gestures that only really apply to Touch ATs.  So 2.5.3 can be viewed as covering a superset of the failures that 3.2.1 covers.  I would propose that we relate the two, and keep 2.5.3 separate, focusing only on the issues not covered in 3.2.1.  Which would be those issues that are either Touch AT specific or that do not refer direction to the onFocus event.
> 
> Also @Detlev:  In response to your 3-B comment.  The issue is not canceling a double tap.  We are assuming that if a user initiates a double tap, that they wish to activate the control.  Let me outline a prototypical failure:
> 
> 1. Touch AT is on.
> 2. User uses a touch gesture to have a control announced.  
> 3. User lifts off this control and the control is activated.
> 
> The proper user interaction should be:
> 
> 1. Touch AT is on.
> 2. User uses a touch gesture to have a control announced.
> 3. Users lifts off this control. (Nothing)
> 4. User double taps screen to activate the control.
> 
> This is what the proposed 2.5.3 is targeted at now.  I believe expanding it to your ideas you commented in your 3-A point are also relevant.  Though I don't believe would be covered by the current verbage.  We'd also want an additional technique and failure focusing on that scenario for clarification.
> 
> Chris
> 
> On Thu, Feb 25, 2016 at 1:11 PM, ALAN SMITH <alands289@gmail.com> wrote:
> All,
> 
>  
> 
> (3)
> 
> C. For iOS, also has the way many blind users use the double tap and that is to touch and locate with one finger then keeping that finger on the screen, tap with another finger, pointer finger and thumb for example. You locate with your pointer finger and tap with your thumb and release to select. To cancel, you single tap but don’t release your thumb, rather you slide your thumb up/down or either side ways to cancel this single tap.
> 
>  
> 
> D. For Android, in similar fashion, locate with one finger then double tap and release with the other. To cancel you double tap and slide your finger on the second tap and not release in the same location. It will start to announce other buttons/items if under that slide to position and not fire the unwanted double tap.
> 
>  
> 
> Hope that helps.
> 
>  
> 
> Sent from Mail for Windows 10
> 
>  
> 
> From: Detlev Fischer
> Sent: Thursday, February 25, 2016 12:42 PM
> To: public-mobile-a11y-tf@w3.org
> Subject: Issue of the new Success Criterion 2.5.3 vs. WCAG 3.2.1
> 
>  
> 
> Just following the discussion on today's telco about the benefits and disadvantages of having a new Success Criterion 2.5.3 vs. rolling it into WCAG 3.2.1, I see some differences which might be sufficient to justify the sdeparation (but I am not sure ansd just want to discuss this in more detail):
> 
>  
> 
> (1) SC 3.2.1 covers operation with or without AT turned on
> 
>     SC 2.5.3 presumably focuses on use with touch AT turned on
> 
>     (a completely different input paradigm compared to touch
> 
>     without AT)
> 
>  
> 
> (2) 3.2.1: When tabbing through content, things violating 3.2.1
> 
>     just happen on focus - there is no option to revoke the action
> 
>     SC 2.5.3 (as I understood it) focuses on enabling users to
> 
>     revoke an action if they discover that they made a mistake
> 
>  
> 
> (3) So there are two variants in the way 2.5.3 can apply:
> 
>     A.  AT is off. Here it would cover being able to move the
> 
>         finger out of a control to revoke the action.
> 
>         We know from Patrick that this might not work (sticky
> 
>         behaviour), but it _can_ work natively (iOS) and also
> 
>         on web pages (iOS, Safari) - maybe only if you move the
> 
>         finger far enough outside the control.
> 
>     B.  AT is on. Here, the typical moment to revoke might be
> 
>         that you realise in the middle of a double tap that you
> 
>         actually don't want to activate after all, so you don't
> 
>         lift your finger in order to prevent the event from being
> 
>         fired. We would need to validate with AT users whether
> 
>         they actually do that. iOS cancels the double tap when
> 
>         you move your finger sideways (which of course can be
> 
>         anywhere). If you just leave it resting on screen you get
> 
>         a context menu that includes 'Cancel' (but this may be
> 
>         3D touch specific)
> 
>  
> 
> Not sure whether this is helpful.
> 
> Detlev
> 
>  
> 
> --
> 
> 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
> 
>  
> 
> http://www.testkreis.de
> 
> Beratung, Tests und Schulungen für barrierefreie Websites
> 
>  
> 
>  
> 
>  
> 
> 

-- 
Detlev Fischer
testkreis - das Accessibility-Team von feld.wald.wiese
c/o feld.wald.wiese
Thedestraße 2
22767 Hamburg

Mobil +49 (0)157 57 57 57 45
Fax   +49 (0)40 439 10 68-5

http://www.testkreis.de
Beratung, Tests und Schulungen für barrierefreie Websites

Received on Thursday, 25 February 2016 20:38:58 UTC