Mobile Accessibility Task Force Teleconference -- 24 Jan 2019

https://docs.google.com/spreadsheets/d/1wRAViPfAJ4Ytqc71tGZp6gU07HNd2QQaNgtJsog-D90/edit?usp=sharing

spacing between touch targets

Kathy: the thinking was a minimum touch target size would help people have trouble with keyboards and also low-vision. A lot of the guidelines two pixels away from target size. I haven't seen any new research about minimum spacing between touch targets
... has anybody seen research about minimum spacing between touch targets

Jake: I've seen some best practices of not putting the targets to close together but specifically when the targets are not large
... this should be something like when it's less than 44 x 44 then you need to have that spacing between

<Kathy> https://www.lukew.com/ff/entry.asp?1085

Jake: I know I've read also from android specification – they mention it but just like the 44 it's a best practice
... if you see their own applications for websites they don't always do it themselves. According to my recollection it's between one and eight pixels

Kathy: I misspoke earlier – I meant to milliliters which is about eight pixels
... 1 mm is good for an index finger and 2 mm for some users. But it's fairly old research
... trying to see if it's feasible to have a minimum spacing between touch targets rather than touch target size
... that might be easier than minimum size. Get something in at AA
... we don't have any real data untouched target size other than what was published a long time ago.
... draft proposal – use the 8 mm number that is out there android, Nokia and then the MIT study also found the same kind of guidance as far as touch target. Any thoughts or concerns – is this implementable if we went that route?

Chris: I'm trying to think of the views that I've seen that would require changing because of the success criteria. I can't think of any apps that I've used from day-to-day that would require modification because of this.
... maybe one is the old-style Google play had a play button that was really small and would've had to have reasonable separation to the field next to it.
... what I'm ultimately questioning is the prevalence, not the relevance

Kathy: you see this a lot in menus, cancel, continue – those are the areas this would be helpful. I haven't seen this where you would need it in paragraphs of text, which is where they had a lot of challenges the last time with getting the minimum touch size.

Jake: this would be exactly the same problem as touch targets – in-line in one paragraph and you have a responsive website you end up with the same extension here. That's the negative side, the plus side is if you say 44 x 44 if they do want to have their interactive elements next to each other you get the 44 x 44 size for free

Chris: we encourage adherence to the AAA requirements so that they don't have to adhere to the AA requirement

Jake: yes, they have to have space if they want to build at the right size they get that for free. But if just in-line links – we have to check it out. Maybe most of the time it isn't a problem if you have enough line height

Kathy: what is the typical paragraphing between paragraphs? All of the style guides I've reviewed – most of them have pixels between the different sentences, line height. if you survey different sites how many of them fall into that already

Chris: spacing is a percentage of font size

Jake: if I look at just regular links without specific adjustments for the links – padding or border. I don't see even one pixel between.

Kathy: there are pixels between text otherwise you'd be butting up against the next character

Jake: it's not more than four I think

Chris: 12 point font I think it's 25% of font size so 12 point font would be three or four. I think that's what Jake is seeing. I don't know if it defines its own spacing that I would have to look up.

Kathy: so we would still have to have exclusions for paragraphs, but I don't think as many exclusions as we have for the AAA

Chris: eight pixels – is that CSS pixels still. Are we going for 1 mm?

Jake: I think CSS pixels

<Kathy> https://www.bbc.co.uk/guidelines/futuremedia/accessibility/mobile/design/touch-target-size

Kathy: I'm looking at the BBC mobile accessibility guideline. They have provide padding .5 EM and one EM
... .5 EM is approximately eight pixels
... their example is in the main navigation
... do we have any success criteria that has a condition – if this, then you have to do that

Chris: maybe controls that do not

Jake: 1.4.5 if audio
... if keyboard trap, if keyboard shortcuts

Kathy"If the target for pointer inputs is less than 44 by 44 CSS pixels then there is a minmum of 8 CSS pixels between targets except when Inline The target is in a sentence or block of text; Essential A particular presentation of the target is essential to the information being conveyed."

<scribe> ACTION: send proposal for spacing between touch targets to low-vision task force for feedback

<trackbot> Error finding 'send'. You can review and register nicknames at <https://www.w3.org/WAI/GL/mobile-a11y-tf/track/users>.

<scribe> ACTION: Kim send proposal for spacing between touch targets to low-vision task force for feedback

<trackbot> Created ACTION-68 - Send proposal for spacing between touch targets to low-vision task force for feedback [on Kimberly Patch - due 2019-01-31].

Custom Gestures (line 7)

Chris: both platforms are going to allow you to break this in different ways – gestures and breaking the ability to interact with the screen reader.
... VoiceOver and iOS: invoice over there's a tree that says to the assistive technology passed gestures through to me
... signature, if you need to go in and sign those gestures need to be passed through – voiceover capturing a signature is meaningless
... times when I can picture this being a bad thing this hypothetical signature area took up a significant portion of the screen such that there wasfor a talkback user to swipe to right or left to move focus forward anymore – this would be a very bad scenario
... from a blind users perspective talkback is trapped, they are stuck
... in android we can't pass through but we can implement complex gesture. draw a curly cue gesture to implement blank
... if you wanted to do this, what you would have is a thing within that application that you are not able to accomplish within assistive technology. Those are the two issues
... one is going to be more prevalent in iOS the other in android just because of the ease of setting up custom gestures and android
... the custom gestures are going to be a native specific problem just because the web is very very far from having people do custom gesture type of thing. Signature pad has the potential to be a web issue. I don't know a website off the top of my head that does that but some of the apps that implement signature pads are HTML 5 hybrid application.
... if a hybrid can do it a web app can do it it's just a matter of time before someone decides to make that a reality.

Jake: if you force a specific movement or touch with JavaScript will this always go well when you turn on your voiceover – or is it possible you will end up in a conflict?

Chris: if you are forcing a gesture in JavaScript on an HTML page it just says pretend like this event occured. So the AT is not even going to be aware of that

Kathy: so maybe this one is more of a native app issue and we should look at it more for silver instead of 2.2

Chris: I'd roughly agree with that but I'd like to look to see if anyone has started implementing signatures in webpages yet
... I know I've seen web components that have the capability of doing that. The part that would be the disconnect would be how does a mobile browser and assistive technology deal with the fact that there is a drawing space in a webpage and does that actually bubble through to the point where the assistive technology is ignored? Or is this just something that will only work in a web environment because of the way it's implemented.
... I can do that research very quickly
... in iOS potentially breaking voiceover from functioning, in android opposite – I will research

<scribe> ACTION: Chris to research custom gestures breaking webpage AT

<trackbot> Created ACTION-69 - Research custom gestures breaking webpage at [on Chris McMeeking - due 2019-01-31].

biometrics (line 8)

Shadi: need alternative to biometrics

Kathy: are there examples on the web today where biometrics are being used on mobile sites

Shadi: so far usually built in the operating system, example face recognition. It's theoretically conceivable that it could be part of the website itself
... maybe a banking transaction, but I don't know an actual real example

Jake: you mean a website that uses fingerprint ID?

Shadi: Apple pay you can use fingerprints but that's on the operating system

<Detlev> sorry to be so late...

Shadi: fingerprints aren't captured directly by the third party or the website

Kathy: voice recognition matching to verify that you are who you say you are – some banking sites. That might be an example. Fingerprinting and voice recognition are two things where I've seen some talk about putting it into a website and a web app. I haven't actually seen examples.

Shadi: recently asked to hold the passport – it was a human on the other side but you see it's possible

Kathy: anything else on the biometrics – should we put something there right now if we don't have any examples
... or should we move this to silver

Shadi: we need implementation to demonstrate, so need examples

Kathy: I'll touch base with – voice recognition is being looked at right now. If they are actually going to be doing it than that may be an example we can use
... other than that I don't know of anybody who's actually doing it

Detlev: on the iPhone you get suggestions to put in your password automatically when it detects your face but that something that is always in addition to normal input

Kathy: that's OS based
... I put a note in here that we should put in implementation examples. If we can't find any I think we should move it to silver

Shadi: I do think it's coming. Voice recognition face recognition just to make it easier – authentication is an issue, and people are trying to find ways around that. But maybe not for quite a while because of the security – so maybe it is better for silver

Kathy: I think it's worth keeping on the list though. It's deftly something we're going to need down the road.

Detlev: even if it's iOS driven is there something the author can do to preclude – offer on the alternative

Kim: agree, but need to know more about how close it is before deciding whether it's better for silver

Shadi: it's a matter of time until probably a big player pushes forward to provide something

Kathy: I've been involved in some of the conversations about voice recognition – so if that is going to become reality we may have an implementation where we could at least call that out. Let's figure out how far along they actually are and being able to do that.

<scribe> ACTION: Kathy to see where voice recognition authentication applications are

<trackbot> Created ACTION-70 - See where voice recognition authentication applications are [on Kathleen Wahlbin - due 2019-01-31].

<scribe> ACTION: Shadi to also reach out about where voice recognition authentication applications are

<trackbot> Created ACTION-71 - Also reach out about where voice recognition authentication applications are [on Shadi Abou-Zahra - due 2019-01-31].

Kathy: for next time will try to get low vision feedback, and also action items from today

- DRAFT -

Mobile Accessibility Task Force Teleconference

24 Jan 2019

Attendees

Contents

spacing between touch targets

Custom Gestures (line 7)

biometrics (line 8)

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output