https://docs.google.com/spreadsheets/d/1wRAViPfAJ4Ytqc71tGZp6gU07HNd2QQaNgtJsog-D90/edit?usp=sharing
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].
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].
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
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Default Present: Kathy, JakeAbma, kim, Detlev, Shadi Present: Kathy JakeAbma kim Detlev Shadi Regrets: Marc No ScribeNick specified. Guessing ScribeNick: kim Inferring Scribes: kim Found Date: 24 Jan 2019 People with action items: between chris for kathy kim proposal send shadi spacing targets touch WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]