MATF Minutes 20 December 2018

*MATF Minutes 20 December 2018 link:
https://docs.google.com/spreadsheets/d/1wRAViPfAJ4Ytqc71tGZp6gU07HNd2QQaNgtJsog-D90/edit#gid=124994642**

Text of the minutes:
*


  Mobile Accessibility Task Force Teleconference


    20 Dec 2018


    Attendees

Present
    Detlev, kim, Kathy, Jake, Shadi
Regrets

Chair
    SV_MEETING_CHAIR
Scribe
    kim


    Contents

  * Topics <https://www.w3.org/2018/12/20-mobile-a11y-minutes.html#agenda>
     1. spreadsheet line 5 Gestures
        <https://www.w3.org/2018/12/20-mobile-a11y-minutes.html#item01>
     2. Spreadsheet line 20 technique grouping of content
        <https://www.w3.org/2018/12/20-mobile-a11y-minutes.html#item02>
     3. spreadsheet line 21 techniques: instructions for custom
        components and carousel
        <https://www.w3.org/2018/12/20-mobile-a11y-minutes.html#item03>
  * Summary of Action Items
    <https://www.w3.org/2018/12/20-mobile-a11y-minutes.html#ActionSummary>
  * Summary of Resolutions
    <https://www.w3.org/2018/12/20-mobile-a11y-minutes.html#ResolutionSummary>


------------------------------------------------------------------------

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.


    Summary of Action Items


    Summary of Resolutions

[End of minutes]
------------------------------------------------------------------------
Minutes manually created (not a transcript), formatted by David Booth's 
scribe.perl 
<http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm> version 
1.154 (CVS log <http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2018/12/20 17:06:44 $

------------------------------------------------------------------------