- From: Jonathan Avila <jon.avila@ssbbartgroup.com>
- Date: Mon, 29 Feb 2016 20:54:10 +0000
- To: Chris McMeeking <chris.mcmeeking@deque.com>
- CC: ALAN SMITH <alands289@gmail.com>, Detlev Fischer <detlev.fischer@testkreis.de>, "public-mobile-a11y-tf@w3.org" <public-mobile-a11y-tf@w3.org>
- Message-ID: <1271E21C-D7C2-402D-9C51-957AC557B5A6@ssbbartgroup.com>
In my opinion 2.5.3 is different from 3.2.1. The intention of 2.5.3 is to assist users that do not have AT active but may touch the wrong element and then slide their finger to the correct element. On iOS Safari I tested and touchstart is fired followed by touchend and then mousemove for controls like buttons and links. Jon Sent from my iPhone On Feb 26, 2016, at 9:07 AM, Chris McMeeking <chris.mcmeeking@deque.com<mailto: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<mailto: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<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10 From: Detlev Fischer<mailto:detlev.fischer@testkreis.de> Sent: Thursday, February 25, 2016 12:42 PM To: public-mobile-a11y-tf@w3.org<mailto: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<tel:%2B49%20%280%29157%2057%2057%2057%2045> Fax +49 (0)40 439 10 68-5 http://www.testkreis.de Beratung, Tests und Schulungen für barrierefreie Websites
Received on Monday, 29 February 2016 20:54:44 UTC