MATF Minutes 23 February 2017

*MATF Minutes 23 February 2017 link: *
https://www.w3.org/2017/02/23-mobile-a11y-minutes.html**
**


  Mobile Accessibility Task Force Teleconference


    23 Feb 2017

See also: IRC log <http://www.w3.org/2017/02/23-mobile-a11y-irc>


    Attendees

Present
    Detlev, patrick_h_lauke, shadi, marcjohlic, Kathy, chriscm, Kim, Jon
Regrets
    Henny
Chair
    Kathleen_Wahlbin
Scribe
    Detlev, Kim


    Contents

  * Topics <https://www.w3.org/2017/02/23-mobile-a11y-minutes.html#agenda>
     1. where we are with the draft
        <https://www.w3.org/2017/02/23-mobile-a11y-minutes.html#item01>
     2. extension document
        <https://www.w3.org/2017/02/23-mobile-a11y-minutes.html#item02>
     3. touchscreen
        <https://www.w3.org/2017/02/23-mobile-a11y-minutes.html#item03>
     4. Kathy: add under 2.4.2
        <https://www.w3.org/2017/02/23-mobile-a11y-minutes.html#item04>
  * Summary of Action Items
    <https://www.w3.org/2017/02/23-mobile-a11y-minutes.html#ActionSummary>
  * Summary of Resolutions
    <https://www.w3.org/2017/02/23-mobile-a11y-minutes.html#ResolutionSummary>

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

<Detlev> scribe?


      where we are with the draft

<Detlev> scribe: Detlev

<patrick_h_lauke> 
https://rawgit.com/w3c/wcag21/FPWD_review/guidelines/index.html

<Kim> Kathy: there is a first public working draft. We have 10 success 
criteria that we went through last week that we propose to go into the 
first public working draft

<scribe> scribe: Kim

Kathy: those 10 are marked as being propose but they haven't been fully 
reviewed by the working group – caveat, everything can be changed, but 
we did get 10 in there last week. the ones that we took out we 
recommended to wait till silver based on comments in github

<chriscm> Sorry, I'm watching my niece today :)

Kathy: there's more discussion that needs to take place. Instead of 
trying to rush through, trying to change on the fly the decision by the 
chairs was to have 8-10 success criteria from each of the different 
taskforces go into the first public working draft so we can start 
getting comments and feedback on those. That's what the status is of 
this first public working draft. Any questions?

Marc: is there a discussion going on about folks just not wanting to 
change any of the existing success criteria?

Kathy: when the decision was made about creating the Trask forces it was 
voted on that we couldn't make substantial changes to any existing 
success criteria. 2.1 and 2.0 stay the same with some add-ons. It hasn't 
been decided that we can change them. Has wider implications – COGA 
misunderstood and wrote a lot of their success criteria to change 
existing instead of separate ones. There are a...
... lot of moving pieces that really need to be thought through – 
implications, what were actually going to do. Until that decision is 
made we can't really move forward. originally we were thinking of 
changing 2.1.1, but then there's been a lot of thought in writing 
keeping at the same.
... comment – first get comment and then look at the bigger picture – 
what's going to happen in silver versus 2.1. That's where were at – 
there's no decisions that have been made to date
... I didn't want us to try and rush to get something in just because we 
were on the deadline for first public working draft. We would've had 
nothing in for mobile because we would not have gotten consensus within 
a weeks time when we had spent several years developing it. So we will 
look at it again and the working group will look at it – we'll get there.
... CSUN, Shadi Kim and I will be doing a presentation we will be asking 
for comment on the working draft
... they are fine with us working on techniques for existing success 
criteria and putting them in. Also changes that we think – things like 
adding a technique. There's still confusion out there about how WCAG 
applies to mobile

Shadi: hate to have people stalled. my understanding is techniques are a 
much more atomic level and will be quite movable depending on how the 
success criteria is formulated

Kathy: I think to a certain extent we probably could – we haven't gotten 
a lot of guidance from working group in how they should be written

Detlev: we started with developing techniques and then moved to 
developing success criteria, so there's one where I already did 
something – mobile navigation for narrow break points – don't know 
whether that could be mapped to some other existing success criteria. 
There may be others
... would want to make sure work would be used. we could go through the 
list and see what can be mapped on to 2.0 success criteria right now and 
is safe to develop anyway. We would probably be wise not to develop 
techniques for things that would be going in 3.0 right now

Kathy: we have started going through some of those old ones – from the 
standpoint of what was done and what we could add and we've got a bunch 
of actions were were going to be writing techniques or modifying 
techniques to go into WCAG 2.0 or 2.1, so we have a clear picture of 
what we can start working on

<Kathy> http://w3c.github.io/Mobile-A11y-Extension/


      extension document

Kathy: going through determining whether we should keep them in or remove

We left off on 3.3


      touchscreen

<patrick_h_lauke> 
https://www.w3.org/TR/UNDERSTANDING-WCAG20/minimize-error-cues.html

Kathy: labels required – that's for everybody not just for people with 
disabilities

Patrick: adding touchscreen here – clearly stated how the user should 
act with the page as an example. Beyond that the general sense of this 
is fine – not sure we need a specific extra technique

Detlev: might get in the way if you didn't have touchscreen – don't see 
how this could be dealt with independently of the different type of user 
agent you're using

Patrick: in the example bullet point clearly saying the case of on a 
touch enabled kiosk or something like that. I know that was it vague 
enough to interpretation but I think the overall sense that instruction 
should be given is already in WCAG 2

Marc: in addition to the bullet update one of the existing techniques 
with another code example where it's kind of obvious that it's untouched 
voice given instructions that are in the code snippet. G131 or H44, just 
adding another example

Kathy: originally if it was standard for the platform we weren't going 
to do that but just if we were creating a custom gesture
... to a certain extent this is part of the assistive technology – to a 
certain extent we can rely on assistive technology to provide that 
information

Patrick: a shortcut way of doing something may be relevant

Kathy: I like your idea of just adding examples in the understanding 
document. We can also add one to one of the existing – I think we would 
want to stay away from descriptive label ones and just add more ones on 
the instructions
... it sounds like the consensus is that we don't need another technique 
but we might want to just add an example of minimum to the 
understanding, possibly add an example to an existing technique

<patrick_h_lauke> https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/G131

Detlev: technique 131, it could be written so that using most of what 
the text there says already – that allows pinch zooming once it detects 
that the user is navigating with, which it can do on the map itself – 
then it can say use pinch zoom to zoom into the map – something like that

Patrick: we don't need to go into specifics, just leave it very high 
level, but at least it mentions the idea that sometimes it might be good 
to provide these instructions and hints even for things like touch

Kathy: G ones are supposed to be technology independent, H ones are HTML

Patrick: leave it high-level, just touch without saying exactly how

Kathy: any objection to modifying the first example in G131 and adding 
to the understanding document in 3.3.2

Marc: no objection but we aren't focusing on custom M005

*RESOLUTION: have no additional techniques for 3.3.2, just add an 
example to the understanding documents, write the example that Patrick 
just did on the fly for G 131*

Patrick: originated on BBC mobile but also covered in using appropriate 
markup – has the effect on mobile that in many cases and then switches 
to the appropriate keyboard. I'm not sure why exactly its fallen here. 
Once it switches the keyboard we need to write instructions about this 
will bring up a numeric keyboard, choose it from here. You would have to 
sniff exactly which browser, which...
... platform it is. If it is that then I think we've already made the 
decision that it wasn't necessary.

Kathy: next ones are 3.3.3-3.3.6 we didn't have any specific suggestions 
for mobile for those, does anyone see any need to add anything for mobile
... we can skip over 3.4 because that is part of what are doing. That 
brings us to principal 4, robust
... 4.1 parsing, does anyone see anything we need to do differently for 
mobile and parsing
... 4.2 hamburger menu technique example – that's what M017 was all about

Detlev: that can be far more general

Kathy: looking to see if there is already a technique on that

Patrick: 4.1.2 is more programmatic
... having a visual representation is not 4.1.2

<patrick_h_lauke> 
https://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-rsv.html

Patrick: looking for expanded in intent – don't see any sufficient 
techniques that cover this

<jon_avila> 
https://www.w3.org/WAI/GL/wiki/Using_the_WAI-ARIA_aria-expanded_state_to_mark_expandable_and_collapsible_regions

Kathy: ARIA 5 – we could add an example there

<patrick_h_lauke> 
https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/ARIA5

Patrick: simple disclosure widget doesn't have to be specific to a menu 
– just any kind of disclosure widget, also applies to large screen not 
just small screen

Kathy: thoughts about putting an example under ARIA 5

Jon: link above to something that was started but never finished by 
another group

Patrick: this gives a little indication and a few examples – the actual 
meat of the things that you should do you have to go to the ARIA 
documentation itself. We could add an example but it will never cover 
everything very completely

Kathy: or do we want to take the one that was already written and 
finalize it as a new one – using the wai aria expanded state to mark 
expandable and collapsible regions

Patrick: putting that into ARIA 5 technique seems appropriate

Jon: at the same time it's like a catch also I don't know that people 
will look to that for this particular need
... also test procedure – simpler if it split out

<jon_avila> Agreed - i vote for a separate technique

Kathy: I would vote for having separate rather than ARIA 5 just because 
ARIA 5 is so broad
... is anybody against having it separate

no objections

<scribe> *ACTION:* Jon to create separate disclosure widget technique 
for mobile [recorded in 
http://www.w3.org/2017/02/23-mobile-a11y-minutes.html#action01]

<trackbot> Created ACTION-64 - Create separate disclosure widget 
technique for mobile [on Jonathan Avila - due 2017-03-02].


      Kathy: add under 2.4.2

<Kathy> https://www.filamentgroup.com/lab/accessible-responsive.html

Detlev: change the title for the new state

Kathy: link – things you may want to think about from responsive design
... spatial and behavioral cues, issues with different modalities – 
arrow keys doesn't work with touch, for example

Patrick: some of these are sweeping – example of Google sheets 
supporting mouse on android. Just going by screen size, on smaller sized 
viewports and don't say anything about arrow keys is probably not the 
right approach. Just looking at spatial and behavioral cues not using 
things like above left – I have a vague feeling that this is already 
covered in WCAG 2

Kathy: yes you can't use any sensory characteristics

Patrick: I'm not sure that this brings a lot new

Kathy: the other big comment in there was around toggles and focus order 
– problematic when different screen sizes. Technique around that challenge

Patrick: that would fall under the more general do we need a technique 
under the focus order and content order SC's
... I think we've touched on those

Kathy: I just wanted to make sure we had those things covered that 
Alistair had put out to the list

<Kathy> Accessible hiding: Where something is visually hidden but can be 
focused with the keyboard, I tend to fail that under 2.1 Keyboard or 
Focus visible depending on the content. It seems there could be another 
technique for this though.

Kathy: accessible hiding – technique on that

Patrick: focus isn't currently visible because it's offscreen
... if there is a technique the covers this we could write one in 
cross-reference

Kathy: I'll do research to find if that's already covered
... there's no meeting next week, majority will be at CSUN. I'll create 
a list. We have been creating actions we will go on with those waiting 
for next steps with success criteria. For the next few weeks will be 
working on finalizing these and getting these submitted. We'll figure 
out a timeline moving forward once we hear from the working group.


    Summary of Action Items

*[NEW]* *ACTION:* Jon to create separate disclosure widget technique for 
mobile [recorded in 
http://www.w3.org/2017/02/23-mobile-a11y-minutes.html#action01]


    Summary of Resolutions

 1. have no additional techniques for 3.3.2, just add an example to the
    understanding documents, write the example that Patrick just did on
    the fly for G 131
    <https://www.w3.org/2017/02/23-mobile-a11y-minutes.html#resolution01>

[End of minutes]
------------------------------------------------------------------------
Minutes formatted by David Booth's scribe.perl 
<http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm> 
version 1.148 (CVS log <http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2017/02/23 17:16:08 $



__________________________________________________

Kimberly Patch
President
Redstart Systems
(617) 325-3966
kim@redstartsystems.com <mailto:kim@redstartsystems.com>

www.redstartsystems.com <http://www.redstartsystems.com>
- making speech fly

www.linkedin.com/in/kimpatch <http://www.linkedin.com/in/kimpatch>
___________________________________________________