MATF Minutes 21 July 2016

*MATF Minutes 21 July 2016 link: 
*https://lists.w3.org/Archives/Public/public-mobile-a11y-tf/2016Jul/0009.html
*Text of minutes:*


  Mobile Accessibility Task Force Teleconference


    21 Jul 2016

See also: IRC log <http://www.w3.org/2016/07/21-mobile-a11y-irc>


    Attendees

Present
    patrick_h_lauke, Kathy, Detlev, marcjohlic, shadi, jon_avila, Kim,
    Chris, David, Jeanne
Regrets
    Alistair
Chair
    SV_MEETING_CHAIR
Scribe
    Kim


    Contents

  * Topics <https://www.w3.org/2016/07/21-mobile-a11y-minutes.html#agenda>
  * Summary of Action Items
    <https://www.w3.org/2016/07/21-mobile-a11y-minutes.html#ActionSummary>
  * Summary of Resolutions
    <https://www.w3.org/2016/07/21-mobile-a11y-minutes.html#ResolutionSummary>

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

<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.


    Summary of Action Items


    Summary of Resolutions

[End of minutes]
------------------------------------------------------------------------
Minutes formatted by David Booth's scribe.perl 
<http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm> 
version 1.144 (CVS log <http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2016/07/21 16:21:41 $


_