Mobile Accessibility Task Force Teleconference -- 23 Feb 2017

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

- DRAFT -

Mobile Accessibility Task Force Teleconference

23 Feb 2017

Attendees

Contents

where we are with the draft

extension document

touchscreen

Kathy: add under 2.4.2

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output