https://docs.google.com/spreadsheets/d/1wRAViPfAJ4Ytqc71tGZp6gU07HNd2QQaNgtJsog-D90/edit#gid=0

TOPIC touch target

Kathy: two things – target size and pixels between targets
... Looking just at the second one, pixels between targets – maybe do that first, also helps with design

Kim: clashing user needs – have a lot on the screen versus less scrolling versus how it looks

Jake: if there's space in between can break design. Also irritating when you move your mouse over a menu when there are gaps between elements it will trigger things – it looks like it's blinking instead of just being one thing and staying there – it will be a pointer than a hand than a pointer. Those were in the past two reasons why I always wanted my menu items without any space between them even a pixel
... so just take into account when we try to solve this one it may affect design decisions – just from another angle some pushback may happen

Mark: I was thinking we could do spacing of we exempted text. But you are right Jake if there are menus there may be issues. Maybe background the same color but these are all issues to deal with

Kathy: I don't think clashing requirements is something we can solve in 2.2
... we have to say is there any items for 2.2, is it worth doing in 2.2 altogether. Then looking at that for whether or not we would put more effort into silver at this point rather than trying to do another point release. This exercise is to gather insight – is there anything for 2.2.
... this is one of them, spacing that might be in 2.2. Were just determining whether it's worth spending more time discussing

TOPIC provide clear indication that elements are actionable

Kathy: this is about making sure that buttons and links look like they are actionable – Affordances between different controls – do we need and2.2 or silver

TOPIC landscape and locking

Jake: when you're in portrait mode example progress of stocks, in landscape it's just a totally different view. It's not like you are losing part of the content, it's two completely different views and that's not covered by the success criteria. Some options only available in landscape, stock example.

Mark: what's the alternative

Kathy: the problem is there's no way in portrait mode to get to that functionality. So this success criteria would say it must be possible to do the same functions in portrait and landscape
... if you have filters in landscape mode when you get a portrait mode may be that collapses just to a button to push to get that information – the functionality should be there you just have to get it in a different way – you do have to take action to reduce screen size but make sure you don't lose functionality

Jake: maybe all functionality will be available in landscape as well as portrait, something in that direction

Kathy: is it 2.2 or silver

Jake: 2.2

Mark: 2.2

Kim: 2.2 – use cases mobile and also cognitive

TOPIC gestures

Jake: instructions but not for a form but for gestures

Kathy: the challenge here is I don't know what the success criteria would be. It's a good best practice and a good thing to think about I just don't know what the success criteria would be

Jake: we can look at labels and instructions
... find something then can't get it back

Kathy: I've made a note to look at labels and instructions for 2.2

TOPIC focus indicator

Jake: go to the top or bottom you don't have a focus indicator anymore – we say it must be visible. If it always happens with sticky headers and sticky footers they are not allowed anymore

Kathy: ways to track to make sure item becomes focusable or visible – technique on existing for 2.2?

TOPIC Instructions for components that are not native

Jake: example multiple bank accounts and you can swipe through them – works a bit like a carousel but also doesn't. Not global convention are not always clear. It's an area where when people are just inventing new stuff but not sticking to ways people normally interact with these types of components. Often they end up not really accessible. Also little bit of a blurry thing – just look at can we do something there

TOPIC focus management when zooming

Jake: if you focus on a menu item when you zoom in that menu item will be hidden hamburger menu – what do you do with focus management when you rotate or reflow. For instance landscape three table rows last row element that has focus, what happens with the focus when the last row or column disappears
... so what happens when element in focus disappears?
... zoom in, element disappears, where is focus

Kathy: we should touch base with low vision task force on this

TOPIC custom gestures and information about them

Jake: if you can only use one finger because you turn on your screen reader into fingers don't work anymore. Information communicated – use two fingers to scroll up and down when screenreader is taking up others
... also don't talk about click here if you don't use a mouse because you can also talk about touch or eye tracking
... but most important one is not to break gestures when you turn on your screen reader

Kathy: past discussions?
... I don't know why we took this out, and I don't know why we ended up not even looking at it for 2.1 – I put a note to go back to our conversations in minutes to see past conversations I

TOPIC carousel

Jake you don't know or hear when you enter that specific widget – for example, there is a container, previous/next, headings – when or how do you know when you enter the carousel because it's not an official element with a role. But we all know what a carousel is and people Seeing the screen know to push the buttons

Jake: as we invent more conventions, always be behind but at least we can provide a role description

Kathy: I think we should look at what we can do in 2.2 – and further discussions on this
... 4.2.1, aria is a technique, but not the only way to accomplish it. May be worth looking at if this does or doesn't fit under 4.1.2

TOPIC modal URL

Jake: this makes you lose the context of the page itself
... it's not clear at this moment

<JakeAbma> https://github.com/w3c/wcag/issues/170#issuecomment-437109868

Kathy: I'll put more discussions needed on this one. I think we have enough to have good discussions next week on what we've identified for 2.2. And maybe for the ones that I haven't marked up to look and see effectively a technique under an existing criteria

<Kathy> I guess Webex decided we were done!

<JakeAbma> ?me

<Kathy> thank you for all your inpute

<Kathy> we will continue discussions next week

WebEx hung us up automatically

<MarcJohlic> Similar to this issue, I've seen a lot of chatter lately around where the focus should land on a modal (close button, title, content etc) - so could be a part of that discussion

<shadi> oh darn, that was me leaving!

<MarcJohlic> Oops

<shadi> really sorry about that!

Talk to everyone next week

<shadi> should i re-open the bridge?

No need to do that – we were just ending anyway

<shadi> sorry!

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: kim, shadi, Kathy, JakeAbma, MarcJohlic
Present: kim shadi Kathy JakeAbma MarcJohlic
No ScribeNick specified.  Guessing ScribeNick: kim
Inferring Scribes: kim

WARNING: No "Topic:" lines found.

Found Date: 29 Nov 2018
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


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