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

spreadsheet line 5 Gestures

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

Jake: took a look at three existing techniques, there's more here.
... swipe, no instructions, hidden features, swipe and it's gone and you don't know what happened
... so when there's functionality available via gestures or hidden users need to be informed and need to be able to turn them off

Detlev: sliding view or scrolling view if you don't turn on a screen reader swiping to bring in content from right to left – would you require for that to have some permanently visible message or could it be some icon saying you can swipe to move in – where do you draw the line
... would you require the author to do different device one screen readers on – it might be different gesture then – how to do that

Jake: I've seen sites where you can swipe from the left and then you have options like edit or delete but those options are not in another place – only available when you swipe to the left. I only discovered a year after I visited many many times. If you cannot swipe you don't ever reach those options.
... other examples swipe and activate

Detlev: website or native app behavior?

Jake: mostly for native apps, but it shouldn't matter if it's technology agnostic success criteria

Detlev: it's related to the severity of the type of consequences of the gesture is the difference whether you have a scroll view which you can swipe into view – you may not know that you can swipe somewhere so you do it and see that it moves over, I can also move it back. And if you were just using a keyboard you can just tap and it might reposition the visible part within the viewport. So there's nothing that cannot be undone, there's no harm done.
... I would agree that if you have functions hidden that this is another kind of gain at that point it certainly important to not accidentally do something which you find difficult to undo or to have some kind of clear indication of the functions available to you. I think this needs to be carefully taken apart depending on the type of situation you are dealing with.
... whether it is a no harm done function or easy to undo

Jake: my own experience it only happens on mobile – swipe on a row whether by accident and there are functions that you did not know were there, can't get explanation and can't turn off
... multiple angles that I'm trying to cover. If we look at motion actuation it's a thing which can be triggered by motion and needs to be an alternative. In this case swiping doesn't fit on motion. But if you swipe and there's no fallback as a user interface component. Motion actuation today is pretty close in combination with help.

Kathy: I just read through the help 3.3.5. I think we could have a technique under that. This is an area where people might want to consider that. 3.3.5 says context-sensitive help is available. Really what were doing is saying we want to provide context-sensitive help. We may want to just have a technique in there rather than a new SC. I don't know how we would differentiate this. If it's just mobile specific it seems like it would be better as a technique.
... I read through the understanding – not sure if there's something in the intent that is making it seem like it doesn't fit

Jake: option to turn off. Something available just in a static environment, but not dynamic environment when you're using touch
... need to read through to see if it fits as a technique or if there's another angle we might want to achieve. Help is pretty close

Detlev: concern because it's several things in one proposal – whether it's technique or sc. Help available and then turn off or operate in alternative ways.
... alternative ways might be covered by pointer gestures. Concerned that it's too many things in one spot

Jake: think about this and talk about next time

Detlev: what's enough – see half an image or need an additional button, help text or indication or not – that's where things get difficult if you put several things in one spot the combinations and interrelationship between these things can be difficult to handle both and failure and sufficient techniques
... may be delineate in a way where you focus on actions which either have permanent consequences or difficult to undo
... not so much things that just change the view without affecting anything

Kim: just want to point out that for some users changing view is a very big deal – you can get very mixed up

Detlev: if you don't realize something can be swiped into view you might not see it – opportunity lost. That's also usability issue. Looking at that mobile app and looking at content if they don't realize there are things that can be controlled they might miss and everybody might miss. If this is peculiar to disabilities.
... what kind of requirements can you really impose on all this to communicate any type of interactive behavior brought about by gestures. I think it's quite hard one to pin down. And then not to be overly restrictive

Jake: if this only appear in the swipe – if it's only available by swiping to the left or to the right it might already be available in some other way – it should be
... I've seen them more than once without alternatives. Will look for examples where actions are only available by swiping and not in another way that's a pretty good case
... and then it's really close to motion actuation

Detlev: it's like pointer gestures
... motion actuation only shake to delete and then one website where you swivel around to change the view
... but we should be looking out for that there will be more stuff popping up

Spreadsheet line 20 technique grouping of content

Jake: it's not a technique for keyboard – you have to swipe more when things are not properly grouped
... we do not have a best practice or success criteria where we advised to group content to make it easier to use

Detlev: sounds like a good one. All these teaser blocks, maybe six or seven focus points for each and might be hundreds of teaser blocks. Worse for mobile. People disabilities are much more reliant on swiping, tapping I think you can make the case that it accessibility

<JakeAbma> https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_group_role

Kathy: needs to be SC. If links were adjacent need to be combined. Or you could set parameters – if link with the same destination and they were within whatever, some parameter than that would be considered a failure versus if we have two links that go to the same place and are separated by more than that then it wouldn't be a failure. I think there are some ways you can put parameter around that
... may be directly adjacent and can be combined is simplest

Detlev: improve focus by grouping content would be fairly straightforward wouldn't have to find the exact conditions
... maybe you just draft and we take a look

Jake: I looked and didn't find SC where it fits

Detlev: may be easier to have as a guideline in silver. The moment I think 2.3.4 focus order but obviously order is not the only aspect of this

Jake: will draft and move it to 2.2 consideration
... my investigation says no so let's see if we can make it a little more concrete

spreadsheet line 21 techniques: instructions for custom components and carousel

Jake: put these two techniques into one. Added accordions to carousels
... we have this on our website in the Netherlands, carousel and you don't know when you enter the carousel, it just starts mentioning headings, another headings suddenly there's a button previous or a button next
... I looked at accordion – you know when something is expanded and collapsed but you don't know the relationship, don't know it's an accordion
... 4.1.2 is more about atomic elements, atomic user interface components like a button or link but not like a widget form of a carousel
... if you make a carousel you cannot fail that entering the carousel is not read to you by the role. I think it doesn't fit under 412. Previous or next button fits under 4.12 but not the carousel itself. Probably accordion will pass 4.1.2 but you don't know you're on an accordion. I also looked into labels and instructions but that's not for these kind of components. That specifically about inputs.
... so we really do not have a success criteria which requires you to have people know if they have entered a widget

Detlev: I see more the problem of the carousel, we have that frequently – all sorts of weird carousels, sometimes lists, range of gifs and people do different things with arrows, sometimes you can focus arrows sometimes not. It would be good if you could define roles for that. I think these are two different cases.

Jake: the carousel – you are reading the content and you don't know it's part of the carousel and suddenly there's a previous or next button and you don't know where you are. Maybe solution some accessible name for the container elements like this which contain all the carousel stuff

Detlev: you could name it carousel or slider but people don't refer to it with these terms and would still be baffled sometimes
... carousel is a nasty widget in some ways not exactly popular in the accessibility field, but still it would be good to know what it is. I'm not sure at what level would you want to – which are exact proposal if we just focus on carousels. To get the aria spec people to define the role carousel for example

Jake: you see something on the screen and it's pretty clear what it is and then you don't see the screen and start using a screen reader and you're totally lost
... do you fail previous or previous slide – does that automatically make clear that you landed in the accordion and the content before as part of that accordion.
... the best way is the global standard and require that role – that would be nice.
... we started out with new success criteria but if this fits under 4.1.2 – but reading under 4.1.2 that was not really about some composed widgets with options like the carousel. I'm having trouble, and we have it as well on native apps on the web. Swiping right and left where you see the amounts of your different accounts before logging in – and you also don't know where you are at that moment. I can't place that within a success criteria now. It's a[CUT]

Detlev: they are not really good for blind people . And you have all the issues around providing contacts and index buttons to jump to different places it's a nasty complex thing. It would be difficult to define a definitive semantic structure for the carousel simply because there are so many different ways of doing it.
... maybe a good technique would be a good thing if you're going to do a carousel do it this way

Jake: two kinds of grouping. I'm not saying it's a region carousel by default but they are related – grouping without name, grouping with an accessible name.
... the area people themselves already thought that a more important grouping rule – region with an accessible name. So you can also go with voiceover group by group.
... we have grouping roles in voiceover really does something with the grouping. And it's the same for the region. But it's not part of our recommendation

Kathy: I think this is more of a usability thing it also seems like – looking at the aria spec and what we've done there. A lot of why we have the design patterns for accordions and other things that are complex like that was driven from this need. It may be that we have something there that's more on the aria level
... then a SC, technique level

Detlev: it could go under focus order, 4.1.2, 2.2.2

Kathy: I'm not saying we shouldn't look at them in some way I just don't think at the SC level
... I don't want to lose the information – Jake do you want to talk to the aria task force to see if they have any plans for anything within carousels and see if there's any planning

Jake: aria widgets aren't required – I'm not sure if we are still satisfied. Think about it for a bit longer
... it's not an easy one. My question is why do we have an authoring practice accordion but we do not have a role accordion
... carousels and accordions together because Carousel is not an existing widget, no role accordion no role. Same problems with native apps
... this is not mentioned to you – you can do it description but not a standard global convention

Detlev: we need to agree on what a carousel is – that's not easy
... do you need the forward and backward arrows, some kind of auto animate thing – there are so many permutations that are possible

Kathy: were out of time – we need to get through these – maybe we can continue on the list
... the ones we haven't talked about are state discernible, biometrics and spacing

Kathy will take that up on the list so we can get those finalized

No meeting for the next two weeks, next meeting on January 10.

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: Detlev, kim, Kathy, Jake, Shadi
Present: Detlev kim Kathy Jake Shadi
No ScribeNick specified.  Guessing ScribeNick: kim
Inferring Scribes: kim

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 20 Dec 2018
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.)