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

touch target thoughts

Kathy: David saying using touch inside
... if the targets are potentially together you're still going to potentially get inside one of them or not but it does change to a certain extent – it could be a technique that we use in conjunction. It might mean that we could have less pixels potentially in between the targets if you're just looking inside. So you wouldn't have the pixels that are right around the target. I haven't thought it through completely. It's an interesting thing I hadn't hea[CUT]

Marc: even if you're doing such inside if the two targets are beside each other it still poses the problem of the finger accurately hitting them. If I go toward the edge of button a I still might be touching inside of button b at the same time
... touch inside is probably the way to go anyway

Kathy: Jim said small icon spacing shouldn't be more than half, larger quarter to 1/2 is recommended. We're definitely less than that – If we look at half icon at 16 x 16 pixels – I haven't seen things smaller than that generally in a site. Have you seen lesst?n
... I was looking at things like small next and previous button.
... I found that even those – the ones that I saw were 34 x 34. It didn't get smaller than that, and that was a little tiny icon. I didn't do an extensive search overall
... I'm using Emulator in Chrome – also looking
... if we take what Jim has said, for usability space should be half of the icon size I'm trying to get small icons and get an idea across the web. Even the search icon was 25 x 25 pixels and that was really really tiny overall
... since we are saying eight pixels in between this would fail if we had an icon less than 16 x 16 Pixels, but I haven't found an icon where an icon was the only thing used and it was smaller than that. With text sometimes smaller than that. Even next and previous on a slider control. I also looked at hamburger menus, three bar type things. Even those the smallest I saw was 20 x 20.

Marc: 20 x 50, 20 x 60 for hamburger. Social media. Even the little dot icons were typically 15 pixels. That would be a scenario where we might actually have an icon that if we had eight pixels in between it would be breaking that but it was so minor. Most of those where you have dots for each of the slider controls, that little dot
... kebab menus might be the smallest thing
... I go off on these native tangents in this working group all the time. So when we were just talking about touch Inside his native only. Kebab menus – I don't know if I've ever seen that on a website. You see it all the time in the settings so it applies to native stuff.
... so it may not come into play
... tiny little lock icon on the Wells Fargo site is still 20 x 20. That might be the smallest that exists in the real world. Just randomly saying right now it seems like people are sticking in the 40 range

Kathy: it seems like 24 x 24 is the minimum that people are doing for active icons
... I guess the bottom line is I don't think the pixels criteria needs to be changed based on what Jim had put out there – he wasn't saying it needed to be, he was just putting it in some bounds.
... ambiguous wording – I'd be worried from a usability standpoint if we started saying that people needed to have a huge amount between the different icons. Decreasing usability. There's a fine balance

combining focus element and the one below it

Kathy: similar issue – all about managing focus and having the focus go back to where it should be or where it's logical. And on mobile this tends to be an issue because you lose your spot and then If you're swiping you got it all over the place
... in one instance I saw this week the focus didn't go into the menu, so you can't find it
... question is does this fit anywhere under WCAG right now or should we have another SC to talk about focus management
... we've got all functionality available through keyboard interface. But it doesn't say anything about a logical place. We've got on focused order and on input.
... focus order is closest. Focus order preserves meaning and operability
... whole focus management could fit under that, and then technique
... Focus when zooming – could have a technique
... inserting content into a document object model – that's one where if you have a mobile dialog you can tap into a controller if you have a drop-down menu inserting it putting it in a correct place so you don't need to maintain the tab order
... in my mind both of these could fit underneath that

Marc: they're all under the bullet of changing a page dynamically using those techniques – this would fall under dynamic Changing of the page. So just having a technique under here could make that work
... I'm hesitant because you can say that's not what the SC is saying. But the technique is there guiding you to do it this way so that works

Kathy: the SC says that if it can Be navigated sequentially – focus preserves meaning and operability
... if something gets removed from the screen or hidden it can't lose focus
... you could argue that hidden or lose focus does not preserve the meaning and operability, because you'd have to start again at the top of the page
... looking at examples
... example that's adding content.
... I think these could both be different scenarios underneath what is currently there. It does talk about maintaining contacts for things that are being added to the screen. It doesn't necessarily talk about things being removed from the screen. But that fits directly under there

Marc: I think you're right

1

I agree – always good to think about similar things in one chunk

Kathy: so put of these will be techniques under 2.4.3

states discernible

Kathy: wondering how much this overlaps with what low vision is doing
... contrast and affordanc andmy read iss if there isn't visual information present this doesn't apply.
... when we have an active control there is an affordance – the state of that is known.
... the second part is the on off different states we have through the different controls
... 1.4.1.11 boundaries and sufficient contrast

Marc: other than that what would you do

Kathy: I've Seen designers not have any affordance

Marc: that design where there's no indication if there's a button or not stinks for everyone

Kathy: directly impacts low-vision and cognitive users more
... difficult to make an exhaustive list – with design everything changes year to year
... they be the next step is to go to the low vision task force or maybe everybody coga, low vision mobile together to discuss this one in general
... every actionable control needs to have some sort of visual indicator that says it's accessible
... that's the gist of it, but that so broad

Marc: do I now keep my text button and put dash in front of it

Kathy: that's so broad. I don't think we could list out what would make it actionable

Marc: hard enough to get people to underline links – color contrast versus that
... we just need to come up with the guidelines for an actionable control

Kathy: outstanding question is this accessibility versus usability

Marc: wall of text without underlines or color usability

ACTION Kim to send question to low-vision and Coga

<trackbot> Created ACTION-72 - Send question to low-vision and coga [on Kimberly Patch - due 2019-02-07].

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: MarcJohlic, kim, Kathy, Shadi
Present: MarcJohlic kim Kathy Shadi
No ScribeNick specified.  Guessing ScribeNick: kim
Inferring Scribes: kim
Found Date: 31 Jan 2019
People with action items: 

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.)