See also: IRC log
<Kathy> trackbot, start meeting
<trackbot> Meeting: Mobile Accessibility Task Force Teleconference
<trackbot> Date: 21 July 2016
Kathy: on the agenda today talk about touch and pointer, we've gone around on this, also a lot on the list
<Kathy> https://www.w3.org/WAI/GL/wiki/WCAG_2.1_SC_Numbering
Kathy: Numbering: will go with
model two. All of success criteria are going to stand on their
own. If working group feels that they should be combined will
look at all of the success criteria coming from different
taskforces and then do that within the working group.
... so task force proposed success criteria that will be on its
own. The work that we did – Patrick's work and combining and
the discussion will be archived and looked at for 3. but for
2.1 success criteria will be separate.
<Kathy> https://w3c.github.io/Mobile-A11y-Extension/
Kathy: Patrick note this week on
other input methods that we may want to consider adding based
on that, but today I wanted to talk about where we are with
such an pointer and then go and look at where we should be
going and draft some other thoughts around the success criteria
that we may want to add based on having everything
standalone
... were not even worrying about the numbering. All we're doing
is proposing success criteria. Any questions, directions?
Marc: on the task force do you want to still collect that for future conversations or don't even look at existing success criteria
<patrick_h_lauke> i think to actually get work done by december, we should focus on doing the new SCs (and keep a quiet note if we come up with what we feel is overlap with existing ones, like the whole fundamental 2.1/inputs in general stuff)
Kathy: for 2.1 were not going to
be changing any of the success criteria at all. So we can
suggest changes to that – and if you look at the proposal that
John foliot put together about numbering there's a model at the
bottom additional thoughts that has numbering scheme 2.1.1 a.
One of the things I mentioned on the call on Tuesday is some of
those success criteria that were writing and...
... other things may be things that we would want to have as a
2.1.1 a – meaning that it's related to this but it's not the
same. Different ways that legislation has included new
criteria. I'm not sure that it will change our thought process
at all a versus standalone. Working group wanted us not to
worry about it unless there's some kind of impact. Let them
worry about how everything is...
... going to get incorporated.
... were looking at things from the mobile perspective, there's
low vision, cognitive. Although things need to be merged
together. They're going to take a look at it as a whole and
figure out how to put things together. 2.1.1 A, B, C is what
they are considering right now.
... we can start a wiki page collecting things for 3.0 so we
don't lose those things. We've already done a lot of work and I
wouldn't want to see that get lost. Idea is we will create a
repository were all that information will go. So things that
you feel strongly about and that you feel should be included in
3.0 – easier to do it now as we are thinking about things. We
should note.
<davidmacdonald> i'm talking
<davidmacdonald> go to next
Detlev: 2.1 is not going to change any success criteria – my understanding is the ones that are in there right now will remain unchanged but there will be additional success criteria for 2.1. Is that correct?
Kathy: success criteria won't be
changed – they will have the same numbering. All new will be
added into 2.1. Unfortunate thing is the lettering will get
mixed up – for example if we wanted to have something under 2.1
it would go at the next numbering that's available. The actual
numbering of that it's going to be the working group that
decides that
... we will suggest success criteria like touch and pointer.
Were going to suggest, working group will figure out how to fit
it in
David: not sure the Patrick's work wouldn't end up in 2.1. They'll try to merge everything – could even merge into existing success criteria. We'd certainly have the ability to change success criteria after every things in
Kathy: at the task force level we
are not providing any of that – that's at the working group
level and everybody in the task force can participate in those
conversations but right now the model and the guidance for the
task forces is write our own success criteria that doesn't
change in any way any existing success criteria. Add entirely
new success criteria for the topic. We are writing...
... completely separate success criteria.
... where this leaves us is looking at touch and pointer
... if we go back to the existing separate success criteria
that we had, so guideline 2.5.
Patrick: depending on how you
slice it there are a lot of different ways of
categorizing
... leaving keyboards aside, since that's the decision for now,
one of the ideas David floated on the mailing list was pointer
accessible – pointer without AT. Also expanding the idea –
touch with assistive technology which re-maps things. One of
the gaps I think that we also have in WCAG is other types of
inputs such as speech – in one way can behave like a keyboard.
That...
... particular mode of operation is covered by the keyboard.
But in other ways it acts similarly to the touch with AT model.
Doesn't emulate keyboard but moves the focus and lets you
activate things.
... trying to list some of these things. Some very general
category of assistive technology access under which we would
then have things like SC's for touch AT, possibly speech input.
Keyboards with AT
... have a list of these. Work that's already been done touch
target, 44 pixel – that would fit in nicely in that kind of
categorization. As well as having a more generic guideline and
related SC for the more abstract stuff that we talked about
like special sensors – rotation, vibration on mobile device or
laptop. And then the additional, fancy input stuff with tilt
and twist and...
... pressure on other touchscreens or stylus type inputs
... Taken the keyboard needs to say as it is at a given for now
we've already started Detlev and I and others looking in that
light and I think we can come up with something solid enough to
discuss for next week's call
Kathy: also camera
Patrick: probably need to discuss
way in which an input is actually handled by the user versus
how it's handled in the user agent. In the end most of them
boil down to three things either look like there a keyboard,
and so the driver in Windows that actually looks like it's a
keyboard and sends keyboard events. They could look like a
mouse so they simulate a mouse. Connect on the Xbox or...
... Windows. you gesture to the camera but in essence
interprets that and moves the mouse on the screen. To the
webpage it will look essentially like the user move the mouse.
And then speech recognition or touch with AT hook into –
programmatically activate.
... looks like a keyboard, looks like a pointer or accesses AT.
Looking at it that way we can fill the gaps – keyboard is
already in 2.0 - for the other two modalities
... plan for the wildcards as well
Kathy: anything to add Chris?
Chris: to summarize what I said
last week – when you're working on software development in
particular and the stuff we're talking about when you try and
solve something in the wrong place you can feel like you're
beating around the bush, trying to come up with all these
complicated ways of saying things and you can't quite figure
out the right way to say it because you're solving the...
... problem in the wrong place. Not for all of the issues we've
been talking about but especially the keyboard, touch ATs. If
we were to solve this at a deeper level rather than sending it
to the application developers I think you'd find solution much
much cleaner. The way we've been trying to solve some of these
things has been the wrong approach.
David: thoughts as a group for 2.5.1 are we looking at trying to replace that with something more generic at a different level or working with that?
Patrick: I think it's pretty solid. Potentially say the same thing for different AT modalities.
<patrick_h_lauke> speaking of that: please review https://github.com/w3c/Mobile-A11y-Extension/pull/9 which closes ACTION-55
Kathy: one of the things we had
talked about with the comments – what triggered all the
separation was the whole definition, touch versus pointer in
the language we had in there. When we were looking at changing
this several weeks back we were looking at how touch and
pointer and whether or not we should just say pointer. That's
what sparked this whole conversation. We do need to look
at...
... comments from WcAG working group as well.
Patrick: Link above – 2.5 pixels 20 pixels stuff pull request
<patrick_h_lauke> https://github.com/w3c/Mobile-A11y-Extension/pull/9/files
Patrick: look at the changes
tab
... or take down this pull request locally and then look at it
locally and then if it's okay you accept the pull request, but
that is complex in some cases
... also way to see the live version on Github
<marcjohlic> https://rawgit.com/
<marcjohlic> https://cdn.rawgit.com/patrickhlauke/Mobile-A11y-Extension/943bc8ca13dd005e893c0e793f393561d86250b5/index.html
<patrick_h_lauke> https://github.com/w3c/Mobile-A11y-Extension/pull/9/files
Patrick: main points of what I've
changed: definition from pointer to pointer input in first
paragraph. Changed the glossary definition to talk about
pointer inputs rather than pointers.
... the use of course and fine to define the accuracy –
borrowed from media, cross-reference as editor's note
... SC first meant for touch then grafted mouse onto it –
cleaned up language to make them a bit more equal. glossary
change pointer versus pointer input
<jeanne> +1 nice job, Patrick.
Patrick: if it sounds good we can merge the pull request
<jeanne> I especially like the definition change
<patrick_h_lauke> https://github.com/w3c/Mobile-A11y-Extension/pull/8
Patrick: clean up the gene has already accepted a support request, on discussion already on github
<patrick_h_lauke> https://github.com/w3c/Mobile-A11y-Extension/issues
<davidmacdonald> next
David: Good pull request
Shadi: make coarse and fine a definition. Cross-referencing needs to be a bit more clear
<patrick_h_lauke> https://github.com/w3c/Mobile-A11y-Extension/pull/8
<patrick_h_lauke> which references https://github.com/w3c/Mobile-A11y-Extension/issues/4 and https://github.com/w3c/Mobile-A11y-Extension/issues/1
<patrick_h_lauke> https://github.com/w3c/Mobile-A11y-Extension/issues/6
<Detlev> Kim explaining the devastating effect of single key shortcuts to speech users
<Detlev> Advice is for users to be able to customise / turn off single key shortcuts
<Detlev> Kim: without ability to turn off these shortcuts it creates a huge barrier for speech input users
<patrick_h_lauke> to me this feels like a Level AAA allow users to disable/customise keyboard shortcuts
<Detlev> Kim: focus issues as well, speech by others can interfere - Gmail is a big problem
<Detlev> Kim: YOu can customise single key shortcuts in Gmail so you won't trigger them accidentally
<Detlev> Kim: option to preface commands with a keyword to make sure that the command is intended
<Detlev> Kim: commands surrounded by pauses to be discerned / interpreted
<Detlev> Kim: custom commands don't interfere with other input likekeyboard
<Detlev> David: connection to access keys?
<Detlev> Kim: no
<Detlev> Kim: enabling a phrase as command is enabling for speech
<jon_avila> How hard would that be for JavaScript to interpret a string of characters rather than a keystroke?
<Detlev> Kim: mapping of kb commands and speech commands would be useful - key is customisation
Kathy: will talk about speech more later
<patrick_h_lauke> requiring on/off for single-key commands sounds like a potential level AA. requiring that users can customise the single-key commands sounds like a level AAA
<patrick_h_lauke> and potentially there's cross-over with what UAs should be doing, can't lump it all under author requirements i'd say
<davidmacdonald> NEW SC Possibility: Either there is a mechanism to turn off Keyboard shortcuts
<patrick_h_lauke> (or rather, it's unlikely all authors will do this...a hard sell)
Kathy: start thinking about gaps that we are missing so we can get that on the agenda. Not necessarily success criteria but anything
<davidmacdonald> NEW SC Possibility: If there is a customization feature for Keyboard shortcuts, it allows up to 20 characters.
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) No ScribeNick specified. Guessing ScribeNick: Kim Inferring Scribes: Kim WARNING: No "Topic:" lines found. Present: patrick_h_lauke Kathy Detlev marcjohlic shadi jon_avila Kim Chris David Jeanne Regrets: Alistair WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 21 Jul 2016 Guessing minutes URL: http://www.w3.org/2016/07/21-mobile-a11y-minutes.html People with action items: 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[End of scribe.perl diagnostic output]