MATF Minutes 4 April 2019

*MATF Minutes 4 April 2019 link: *
*https://www.w3.org/2019/04/04-mobile-a11y-minutes.html
*


  Mobile Accessibility Task Force Teleconference


    04 Apr 2019


    Attendees

Present
    Kimpatch, JakeAbma, Detlev, Kathy, Jennifer, MarcJohlic, Chris
Regrets

Chair
    Kathleen_Wahlbin
Scribe
    Kimpatch


    Contents

  * Topics <https://www.w3.org/2019/04/04-mobile-a11y-minutes.html#agenda>
     1. touch targets draft
        <https://www.w3.org/2019/04/04-mobile-a11y-minutes.html#item01>
  * Summary of Action Items
    <https://www.w3.org/2019/04/04-mobile-a11y-minutes.html#ActionSummary>
  * Summary of Resolutions
    <https://www.w3.org/2019/04/04-mobile-a11y-minutes.html#ResolutionSummary>


------------------------------------------------------------------------

<Detlev> Sorry I am on another machine - my work computer is being 
maintained right now - have not yet worked out the Weber thing

<Detlev> presnt+

Kathy: new person joining today – Jennifer, so will start with brief 
introductions
... I'll start – I'm one of the facilitators, with Kim. I've been doing 
this for the last four or five years. The work were doing in the 
taskforces to look at the new success criteria for mobile – what we 
need, feeding a lot of the information to the WCAG working group, what 
we feel is needed
... happy to answer questions about it. I'm in the US, Boston area. I 
lead the Paciello Group

Jake: bank accessibility

Kim: cofacilitator, Boston area, speech input

Chris: mobile accessibility lead at Deque
... work with Jennifer, especially on iOS
... looks like Jennifer and Detlev have audio issues

<jennifer> working on it

<Detlev> just trying to download the desktop app

<Detlev> other computer

<Detlev> my usual computer is not available!

<jennifer> I' musing the desktop client, but let me try again

<jennifer> might leave and come back

Kathy: big welcome, happy to have you join us, eager to have your feedback

<Kathy> 
https://docs.google.com/spreadsheets/d/1wRAViPfAJ4Ytqc71tGZp6gU07HNd2QQaNgtJsog-D90/edit#gid=124994642

Kathy: what we been doing the last few weeks is trying to get success 
criteria identified that we want for 2.2
... this is the Google spreadsheet we been working off of

<Kathy> 
https://docs.google.com/document/d/1sszSUKB8t3VuRzxHtOjLfQZjNYCw-xr_EbuMwW7WiGc/edit#

Kathy: draft of what the working group wants to see – we need to review 
that and then if others have updates on what they are working on
... where we are at is we have a few success criteria for 2.2
... pixels between targets is in draft now
... portrait landscape
... indication of gestures
... and then a couple of techniques undercurrent success criteria for 
sticky headers and zooming rotating refreshing
... sheet and the last one we are trying to determine if we need is 
states discernible – figuring out next steps for that
... so there are three we are working on drafting right now. Touch 
targets is drafted and there has been some feedback into that document.

<JakeAbma> finished https://github.com/w3c/wcag/pull/531

Kathy: Jake, any updates I know you were busy last week trying to finish 
other things but are there any updates you want to give on any of your items

Jake: Yesterday I went through your touch target. Starting with another 
success criteria is from tomorrow on

<JakeAbma> 
https://htmlpreview.github.io/?https://github.com/w3c/wcag/blob/tech-icon-font-img-role-v2/techniques/aria/icon-font-img-role.html

<JakeAbma> 
https://htmlpreview.github.io/?https://github.com/w3c/wcag/blob/example-icon-font-img-role/working-examples/aria-icon-font-img-role/index.html

Jake: here are links for technique

<Kathy> 
https://docs.google.com/document/d/1sszSUKB8t3VuRzxHtOjLfQZjNYCw-xr_EbuMwW7WiGc/edit#

Marc: states discernible – IBM carbon framework design language site, 
which is where I would expect them to talk about the patterns they 
didn't have anything collected. They do discuss different things like 
the plus or minus symbol for this or different states of a button, but 
it spread throughout. Will look more. Just so you know I put the link 
for IBM carbon in the comments.

Kathy: what's your general feeling on this. Do you see anything we 
should have for the success criteria or is this something that's not 
defined well

Marc: not consistent. ^ Up versus ^ down versus plus or minus symbol. We 
might get in trouble when someone is saying I am showing, but it's my 
own system – not something others will understand.

Kathy: maybe something similar to color contrast low-vision 2.1 
standard. The states need to be discernible rather than color contrast. 
We had a hard time trying to narrow it down and really look at that. The 
definition of maybe what's in the carbon network we can look at that.

Marc: simple example – accordion + indicates open, - indicates closed. 
Would it be okay for somebody to just put a circle there and when the 
circle is filled and it means it's open and when the circle is not 
filled in it means it's closed. It wouldn't make sense to the average 
person, but it would to the designer. How can we control that behavior?

Kathy: cultural norms – you can do that in North America but it may not 
translate to other countries. I think you might have a hard time there.

Marc: so this would stop at you just have something there that indicates 
– some visual indicator?

Kathy: yes

Jake: if there are two different states enough

Marc: if you had those would you also want aria

Kathy: sounds like 4.2.2

Detlev: if it doesn't update

Kathy: going backwards from being programmatic looking at the actual visuals

Detlev: I agree with Marc that once you start mandating different types 
or how big the visual state change has to be, just say it has to be 
different if you add one pixel somewhere it would be different 
technically but it would not be visiblydifferent so would be tricky to 
cover all design scenarios without being too restrictive

Kathy: can you put something together so we can bring it to the working 
group to at least get their appetite for having this as a 2.2 we need 
something drafted at least on a high-level. This might be worth that 
conversation, just to see where were at before we spend more time on it

<scribe> *ACTION:* Detlev will put something together about states

<trackbot> Created ACTION-75 - Will put something together about states 
[on Detlev Fischer - due 2019-04-11].


      touch targets draft

Kathy: out of these three I was worried about the equivalent one. One of 
the challenges that users have when we have small touch targets – we 
don't want users to accidentally touch something and we want to avoid 
the activation of controls that we didn't mean to. By adding the space 
we are decreasing the likelihood of hitting targets that are 
side-by-side. If we still have controls that are adjacent without the 
spacing we still have the issue.
... what if we remove that and just leave in line
... regardless of whether we have an equivalent still have a problem. If 
there are smaller targets we're still going to have the problem 
regardless of whether there is an equivalent or not

Jake: problem – the same rule applies to both success criteria. I don't 
even like equivalents for the success criteria that we haven't AAA 
because we can't expect people to just go look on the page for another 
component
... that does have enough height or pixels in between
... it's exactly the same for here, so if we remove it here, it should 
not have been there in the other one

Kathy: I see the difference is – what were trying to do is ensure users 
can activate controls. we are trying to get something in at AA. We 
couldn't get in even with all the exceptions the minimum size of 
controls to be AA or A, put space between touch targets. The other 
success criteria deals with one touch targeted time. This deals with 
adjacent targets
... if one of them has an equivalent in the other one doesn't read still 
have the same problem. Here we would have to say that both adjacent 
touch targets have an equivalent control or we take it out altogether 
and say well if we are at AA really this doesn't apply because all we 
are talking about is the space between controls

Jake: I totally agree with you but the reason we put it in there for the 
AAA is still exactly the same reason we have it here, and that is you 
don't have to click on those links or buttons without the eight pixels 
because we have an equivalent and they will find it

Kathy: I can have an equivalent on one of the targets but not the other 
target. So I might not have a way to click the other one
... if we want to leave it in we have to deal with both the targets – 
both need to have an equivalent

Jake: I don't see the difference

Detlev: I think it would be cleaner and easier to take it out in both 
cases, but now we have the situation that it's finalized

Jake: I prefer that we also take it out in the AAA in the future.
... I think we get some questions if one has it and the other doesn't

Kathy: in my mind it is different because in one we have one target and 
the other adjacent targets
... if we leave it in complex exception language where I don't think 
it's necessary. The point is you're trying to avoid the accidental 
clicking of a target that you're not meaning to click on. The touch 
target size is to make it easier to click on a target.

Detlev: let's take it out of this one and then raise the question about 
whether we can take it out of the touch target one at the appropriate time

Kathy: I took it out
... and added note
... and now I've got the plain language version of that
... suggested priority level AA, would fall under operable, similar 
benefits to touch target
... primary purpose is avoid accidental activation
... suggest techniques
... check Amazon, eight pixels on one side, nine on another
... looked on other sites to see if this works on a lot of the menus out 
there, between form fields and forms. There were some cases of seven CSS 
pixels and below, but the majority were at eight and above. I put the 
Amazon example in, so we can say we have an example that passes
... that's the general outline. If someone has other examples of sites 
that pass feel free to add them in here as well

Detlev: if your target is tiny need eight pixels, but if your target is 
large you would also need eight pixels around it

Kathy: yes

Detlev: I'm saying that because you could argue that it's more important 
for the small ones to be eight pixels
... the tiniest possible target is one pixel, you would have 17. But for 
the larger one you would have a much much bigger touch target

Kathy: we took exactly the touch target size because it's already under 
2.1. If we go by some other measure we would have to do something else. 
Then were getting into the 7 mm kind of size and actually trying to use 
a ruler on a device – I couldn't figure out a way to get around that.

Detlev: keeping it simple is good

Kathy: this SC doesn't solve the challenge of small dots – touch target 
so small that users are still going to accidentally touch on something 
else. Often you have another way of doing that on a small screen
... overall I don't think were solving everything with this SC either. 
There's definitely challenges with a small touch target. But I think it 
makes it better – helps, but doesn't solve the issue.
... open to other suggestions, I don't know how to structure it any 
differently

Jake: it would get very messy if you start comparing different sizes
... this is a baseline

Kathy: I think the area where I had started to struggle and it would be 
good to get other people's opinions is a description of how the SC can 
be implemented
... you can look at padding sizes and controls, but two people see other 
ways that this could be tested or a way that this could be easily tested 
other than looking at the combined padding and margin and control touch 
targets

Detlev: something else – inference between label and control. Wonder if 
it can be tested by just taking those elements, label and compute the 
difference between the two – the gap between the two. Not easy because 
you don't know what has actually been made interactive or responding to 
the touch – the text element itself or some div around that or the 
padding, so it's getting quite complex. Visual distance is something 
else. Distance between th[CUT]

Kathy: I think you might get false positives – just like Wilco said. 
Introducing a lot of complexity into anything that you're trying to do 
automatically. I think you could do that in a scenario of manual testing 
were you as the human are making the determination, then looking at the 
padding around that.
... I don't disagree with Wilco, but I think you can do it using a 
combination of manual and automated

Detlev: semiautomatically flagging places where you have gaps that are 
too large. Keep the gap no longer than twice the width of the height of 
the element label whichever is smaller. That might Need to be changed 
anyway. His advice identify exceed the gap and then verify manually

Kathy: if you can identify where exceeded you can get to the point where 
it doesn't matter if it's exceeded for all its parts. Narrowing down 
situations where you would be flagging it for that scenario
... if we can determine what is the actual touch target and what makes 
up that if you look at each of the individual elements on the page and 
if each of those individual elements has at least eight CSS pixels of 
space in between them, that it doesn't matter what ends up being the 
clickable area because no matter what I choose I would have eight CSS 
pixels between them. So the scenario that you're talking about are going 
to be the ones where we h[CUT]

a page where less than eight pixels where we have to make the 
determination manually

Jake: flex box and distance calculated with flex box properties, 
elements implicitly already have some kind of spacing. It's not possible 
to just go in source codes and see whether is eight pixels or not. We 
have an issue where those appear. Flex box depends on how you scale your 
browser.
... it's easy if it's a margin of eight pixels but is difficult if it's 
other elements within, different sizes

Kathy: we would need to have computed sizes based on what you're saying

Jake: for sure. Say 28 flex box containers within a system and will be 
automatically distributed according to a certain percentage within that 
width, there are no hard CSS pixels to base your calculation on

Detlev: could run into complexity if it changes dynamically you would 
want to check it at breakpoints, different things applying a different 
break points, could get very complex

Kathy: might want to check with flex box designers – are there 
techniques outside of accessibility that people use to determine padding

Jake: the problem with flex boxes you can use percentages for flex 
items, flex growth, flex shrink and where they are within your flex box, 
and that has nothing to do with design CSS pixels. It feels like it's 
hard or impossible

Kathy: can we instead of using CSS pixels can we in that case use 
percentage and look at that is having a minimal amount
... we don't have to say with CSS pixels if there's a model that works. 
Just a way to make sure the controls don't go on top of each other and 
that there is a certain minimal distance between them regardless of what 
you're using
... I find it hard to believe that there's any structure out there that 
you can't set something to make sure the controls don't go on top of 
each other – otherwise there's a usability nightmare

Detlev: draw a line around interactive elements, take screenshots, 
process screenshots? Would that work

Kathy: if you can think a little about this and see if there is a way to 
test this – if we can't come up with a way we can have this SC. There 
needs to be a way to test this. I think it's worthwhile seeing if 
there's a way to do this. Otherwise this one's going to fall off.

Detlev: we can send another question to Wilco

<Kathy> I need to leave

<Kathy> Kim can you wrap up?

Jake: I've done a lot of work where you see the end results are partial 
pixels. It will automatically be calculated not on an even pixel


    Summary of Action Items

*[NEW]* *ACTION:* Detlev will put something together about states


    Summary of Resolutions

[End of minutes]
------------------------------------------------------------------------
Minutes manually created (not a transcript), formatted by David Booth's 
scribe.perl 
<http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm> version 
1.154 (CVS log <http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2019/04/04 16:04:10 $

*
*___________________________________________________

Kimberly Patch

www.redstartsystems.com <http://www.redstartsystems.com>
- making speech fly

PatchonTech.com <http://www.linkedin.com/in/kimpatch>
@PatchonTech
www.linkedin.com/in/kimpatch <http://www.linkedin.com/in/kimpatch>
___________________________________________________