See also: IRC log
https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Proposed_revision_of_2.5.3
Kathy: No meeting next week.
Questions on assignments or things you now have ready –
assuming people are wrapping things up and picking things up
after CSUN
... if you have something most of the way there just mark as
for review and we can work on those in these meetings
<Kathy> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Proposed_revision_of_2.5.3#Proposed_2.5.3
David: separate gesture, or be reversible – I like it
Kathy: should we add anything more to the specific benefits – if you have anything, you can always go and add to the wiki
Detlev: are there cases where
selecting by, say swiping left or right would already call some
action – aware of one select and doubled have doesn't do
anything but when you have user gestures like sliding a finger
to move the slider and so on which are not acceptable and don't
get through because the assistive technology are taking those
gestures for something else – that's not exactly...
... what's meant here. Have we discussed cases where the mere
selection would already trigger the action
David: email from Patrick about that
<David_> As a general rule, once AT is running, no touch events (touchstart/touchmove/touchend) are fired directly (when the user is actually moving their finger over the touchscreen) - unless a user explicitly executed a passthrough gesture (if I recall, on iOS, double-tap and keep finger on screen, then execute the gesture). Most recent browsers/OSs with AT running will, however, fire "fake" touch...
<David_> ...events on activation (double-tap) - see http://patrickhlauke.github.io/touch/tests/results/#mobile-tablet-touchscreen-assistive-technology-eventsIn short, if the custom scripting is reliant on handling touchstart/touchmove/touchend, it's usually not going to work (or not going to work as expected).
Detlev: specific pass-through gestures and if the screen reader is turned on those gestures wouldn't just work, would not be passed on to the user agent – that's my understanding
David: he says no events are fired unless it's a pass-through gesture, and you almost never see that done because it doesn't work very well
Detlev: so then does this text makes sense – could there be a situation where you have a selection gesture like horizontal scraping that triggers – I haven't seen that unless you turn on that single touch feature in android, but apart from that I can't think of any situation where that happens. Have we collected cases where that's actually happening?
Kathy: if you touch something it
would get focus and then double tap actually activate there are
scenarios whereby simply focusing on an element activates the
element. I think that's what were trying to get at
... when the screen reader is on – doesn't happen when the
screen reader is off because double tapping is the
activation
Detlev: do we have actual cases
Kathy: that's the only one that I've come across where you single tap on it and it activates it I was wondering if there were other scenarios that people were seeing. This originally came out of the BBC mobile stuff
David: we may not need this
Detlev: could it be that this only happens when this feature in android is turned on
Kathy: no, I've had it happen iOS with voiceover. I know what you're talking about with a single tap with that setting and that is there. I've also seen the scenario where single tap activates there's no way to focus
David: how do you program that
Kathy: I don't know the backend I want to see if we have other examples. I couldn't come up with a scenario – within applications, yeah, but not within web content other than that one instance where I had that happening
David: could that situation have been a glitch or need a reboot?
<Kathy> http://www.bbc.co.uk/guidelines/futuremedia/accessibility/mobile/focus/touch-events
Kathy: definitely not
Detlev: still inside the button release mouse outside the button so you prevent the event from happening so the same thing obviously can be without the screen reader on you just click, move the finger away and it won't happen. So I think that's a scenario that has nothing to do with assistive technology use
Kathy: we can remove one device assistive technology is being used, just when selection gesture is different from activation gesture easily reversible
Detlev: if you use your iPhone without voiceover just lift the finger and that separation between selecting and activating , but screen reader is select something first and you hurt spoken than double tap to select
Marc: default is touch up allows you to slide off, native apps. I kind of like wording having assistive technology turned on
Kathy: if somebody does something on touchstart – look at the failure, on touchstart rather than touchend
David: maybe we're better off just removing assistive technology for now and say later we will keep it in the back of our minds. We should have a boneyard – stick ideas that we might need again but we're not sure
Detlev: we have a single example that demonstrates that, screenreader, focus on something be it touch or swiping – if that exists then I think it's a good thing
<marcjohlic> the selection gesture must be separate from the activation gesture, have confirmation, or be easily reversible. (Level A)
<marcjohlic> ugh - bad pasted
<marcjohlic> Interface elements that require a single tap or a long press as input will only trigger the corresponding event when the finger is lifted inside that element. The selection gesture must be separate from the activation gesture, have confirmation, or be easily reversible. (Level A)
<marcjohlic> ^ But it needs to be shorter
Jeanne: having to keep finger inside focus circle causes problems for people with mobility issues
<marcjohlic> Propose: For interface elements that require a single tap or a long press as input the selection gesture must be separate from the activation gesture, have confirmation, or be easily reversible. (Level A)
Detlev: swipe somewhere else or tap somewhere else is different, but if people can't do that maybe we should just throw it out
<marcjohlic> (but agreed, that may not work w/ what Jeanne is saying about mobility issues)
Detlev: separation of selection and activation this is one place where that can happen. This is nothing to do with the previous version because it's not really about where the finger is it's just desktop thing where you say leave a form element and then submit the form
Jeanne: web client dialer where if you tap the number it executed – didn't wait for you to lift your finger to execute the number dialing. I thought it was with the screen reader turned on
Detlev: and it wasn't the virtual keyboard he used?
Jeanne: custom dialing keyboard
Kathy: editing wiki
<marcjohlic> Propose: The selection gesture for single tap or long press input must be separate from the activation gesture, have confirmation, or be easily reversible. (Level A)
Detlev: are we mixing up BBC use of assistive technology and selection gesture separate from activation gesture – it doesn't really map easily on a use case where you don't have a screen reader turned on because here you don't separate
David: iPhone keypad – press on the to and move away from the 2 you already dialed it – it activates on touch. I haven't seen any complaints about it
Detlev: the dialing itself is a separate thing after you've put in the number
David: let's look at some other
flagship activity on the iPhone
... airplane mode wouldn't activate until I let go of my
finger
... so all these buttons and the settings work that way on the
iPhone
Marc: I tried a few things and it looks like they're all using touchup events
David: I have my Google mail
open, my taskbar in Safari and if you want to refresh – that
little circle for refresh if you tap it quickly it will
refresh, if you hold it down it's going to say do you want to
go to the desktop view
... two choices request desktop site or cancel
... so there's a means to undo it
... do we really want to create something that's going to fail
the iPhone dialer. No, but we have revocable, so it's not
failing it
... photo button burst mode interesting behavior
Kathy: I don't think these are behaviors we want to see. If you have someone with a mobility impairment, problem
Detlev: presumably you can customize it's up to you to customize so it doesn't do unintended things
Kathy: we have reversible or confirmation so we can have that as part of it
David: add can be disabled
Detlev: burst mode – can delete all at once I don't know if that's revocable
David: deleting them all at once – not saving the one I want
Kathy: if we go down that route is there something we need to change.
Detlev: focus on either assistive technology or without
David: takes burst with voiceover
on
... if we can boneyard assistive technology for now
Detlev: keep it is something that needs backing by some examples, ask Chris to come forward with the dial path example
Kathy: let's move away from assistive technology and focus on the latter part of it
Detlev: I think that is valid and is just good practices to mobile and whether that can stay in or people would consider that general usability I'm not sure. BBC has different scope maybe
Kathy: is this very similar to
oninput or onfocus?
... very rare, but example yesterday behind a firewall. Loss of
focus
... how often this is actually gonna happen – it may not be. I
think there is a challenge within single tabs and long presses.
I think in the settings on the iPhone, and I haven't played
around with this. I think you can actually change the time for
long press in the settings
Generally looking for this
David: what about force touch
<marcjohlic> "Touch Accommodations" under General > Accessibility
Detlev: 3-D touch same thing, may not be available to everybody with 3-D touch phone but you can get to everything by going into the application
Kathy: 3-D touch images, actions and actual menus
Detlev: presumably someone could
write an app where people have things for 3-D touch that appear
nowhere else, so that would be a failure
... failure: content elements or whatever where you provide
through just 3-D touch or just long presses where you can have
in any other way where it's not just a shortcut but something
unique that other people can't get to who can't exert the force
touch because the device doesn't support it or because their
motor disability doesn't allow them to touch for that long a
time
Kathy adding this to wiki
Detlev: also keyboard users wouldn't have a way of doing al ong touch
Kathy: is there a keyboard equivalent?
Marc: general accessibility,
touch accommodation, tap assistance
... location of touch
David: but they don't say anything about force touch
<Kathy> 2.5.3 Single Taps and Long Presses Revocable: The selection gesture must be separate from the activation gesture, have confirmation, or be easily reversible. (Level A)
Kathy: here's what we have right now
Kim: still doesn't say anything about settings
David: giving them a lot of options
Jeanne: I think we really confuse things when we get into the user agent side of it. On this particular example we need to stick with just what the author can write
David: mechanism is available – that can be author or operating system doesn't matter. If there's nothing in the settings and they need to be able to. Maybe we can actually leverage that – or a mechanism is available
Kathy: a mechanism is available to change the touch settings?
David: we don't want it to activate it on touch, so an activation is available to disable activation untouched – on down. We're not worried about up, just ondown
Kathy: you could have user settings and application that allows you to change the way it's doing that – that would be an okay alternative to this
<Kathy> 2.5.3 Single Taps and Long Presses Revocable: The selection gesture must be separate from the activation gesture, have confirmation, be easily reversible or there is a mechanism is available to change the way touch settings.
David: or a mechanism must be
available to separate them – that's really what we want to
say
... it's really the down action that's causing the trouble so
maybe we need to say that in the success criteria
Jeanne: or in the understanding
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) No ScribeNick specified. Guessing ScribeNick: Kim Inferring Scribes: Kim Present: Kim Kathy Mark Detlev David Jeanne Regrets: Jonathan Alan Alistair Henny Chris Found Date: 17 Mar 2016 Guessing minutes URL: http://www.w3.org/2016/03/17-mobile-a11y-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]