https://docs.google.com/spreadsheets/d/1wRAViPfAJ4Ytqc71tGZp6gU07HNd2QQaNgtJsog-D90/edit#gid=0
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
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
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.)[End of scribe.perl diagnostic output]