<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: 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
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].
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
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: Kimpatch, JakeAbma, Detlev, Kathy, Jennifer, MarcJohlic, Chris Present: Kimpatch JakeAbma Detlev Kathy Jennifer MarcJohlic Chris No ScribeNick specified. Guessing ScribeNick: Kimpatch Inferring Scribes: Kimpatch Found Date: 04 Apr 2019 People with action items: detlev 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]