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.)[End of scribe.perl diagnostic output]