<Kathy> meeting: Mobile A11Y TF

<Kathy> scribe: Kim

current status

<patrick_h_lauke> https://github.com/w3c/wcag21/labels/MATF

Kathy: success criteria are in the process of being reviewed. Within github there is a comment section. Most of the members of the WCAG working group have been assigned to be an owner of a particular SC

<patrick_h_lauke> for all MATF related issues

Kathy: SC manager is outside the group that submitted. I wouldn't be a manager of any Mobile ones. The idea is to have fresh eyes and have someone else shepherded through the process. That said we can all add comments.
... if anybody wants to get more involved in the success criteria for 2.1 everybody is welcome to become messy manager of any of the success criteria. There are some that have been assigned and some that have not. These are all going to be shepherded through. Each week the WCAG group reviews some.
... that's where were at within the existing success criteria in what's happening within the working group. Questions or concerns about that process?

<patrick_h_lauke> https://github.com/w3c/wcag21/issues/59

Patrick: pointer – probably would affect all users to some extent so I would propose to retire this.

Kathy: I think we need to put it in the silver bucket rather than retire it. Issue is we can't make changes 2.0. We need to have all this information when we do silver.

Patrick: makes sense

Kathy: revisiting it in silver doesn't mean it will go in, but the whole keyboard model, touch, input has to be revisited and structured well. There's a lot of redundancy right now, but that was because the way we needed to structure it

Patrick: is there some label that can be added – deferred to silver, waiting for working group review etc.
... so people don't start reading it and form opinions and see at the end that we've effectively retired it

Kathy: will get with Andrew about that

<Kathy> https://github.com/w3c/wcag21/issues

<patrick_h_lauke> https://github.com/w3c/wcag21/issues?utf8=%E2%9C%93&q=label%3AMATF%20is%3Aissue

<Kathy> https://github.com/w3c/wcag21/issues?q=is%3Aopen+is%3Aissue+label%3AMATF

Kathy: will set aside some time on the calls to make sure comments are answered and everything is clear
... next step is they will come back to us potentially to write the techniques
... any other comments on the submitted SC's to the working group

Technique development for existing SCs

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

Kathy: we'd identified a number of techniques for mobile to put under existing success criteria – one under WCAG 1.1 5 under 1.3.1 etc.
... one of things we can be working on now is techniques under existing criteria – we can submit these at any time
... I'd like to look at these today and see if there are any that are missing, and for each of us to take one or more of these and write the technique up. Then we'll review these during the calls. So we will not only get new,, but also techniques for some existing

Patrick: are these set or still some debate about whether we need them or not

Kathy: that's what we are going to do now – get a final list of what we think we need to do under WCAG 2.1
... WCAG 1.1.1 technique for providing media metadata – that's the only technique listed for that guideline. Any comments

Patrick: question – is this a mobile thing or are we taking the opportunity to provide new techniques which will not be mobile specific – I can't think of mobile specific for this one

Kathy: that came from the BBC gap analysis – they had it in their mobile
... we should concentrate on mobile. We can list this one, but we don't need to prioritize it
... does anybody see any other technique that we need to provide specifically for mobile under text alternative – anything that has to do with video or audio
... guideline 1.3.1 several techniques. Virtual keyboard can be set to several types of data entry. It seems like some redundancy here. With HTML 5 we can write some specifics as far as different types go. Other comments on that or things that are missing for 1.3.1?

Patrick: not completely convinced they would be necessary under 1.3.1 altogether. possibly 4.1.2
... writing the technique to trigger a particular user agent rather than specifying what the nature of a particular input is

Kathy: there's a lot of crossover between 4.1.2 and 1.3.1

Patrick: possibly boil down to if you are expecting a particular type of input set the type and the note saying if you do this on mobile devices generally this will also have the beneficial effect of virtual keyboard – I would suggest merging all of those – could fit under 1.3.1 or 4.1.2 or both

Kathy: I agree, and we've got others that fit under two

Patrick: will take this on

<scribe> ACTION: Patrick to write one technique that covers items under 1.3.1 [recorded in http://www.w3.org/2017/01/26-mobile-a11y-minutes.html#action01]

<trackbot> Created ACTION-56 - Write one technique that covers items under 1.3.1 [on Patrick Lauke - due 2017-02-02].

Kathy: 1.3.2 This technique specifically about changing orientations and what needs to be done to have the correct reading sequence
... one of the things we had in the mobile note was talking about orientation and reading order, which I think is specific to mobile because you don't have landscape and portrait mode necessarily on a desktop or laptop

Patrick: you do if you change the aspect ratio of the browser window
... it would be triggered exactly the same way on the desktop, unless you did something very specific where you only checked wider than taller or vice versa. But that would happen the same way on desktop so I think it's a universal problem not specifically a mobile one as long as we are not talking about other aspects such as focus needing to be retained as you flip the display, but...
... that would be covered under the SC for device orientation

Kathy: what do other people think about this?
... reading sequence between device orientation or aspect ratio for responsive layout – clarify what is actually acquired for the different layouts. Is it really mobile specific?

Jon: not really mobile specific. I'm not sure making sure it's consistent between layouts is important

Kathy: within each layout it needed to have a correct reading sequence. Not saying the same reading order in different layouts. I see this is kind of a mobile technique but happy to be overruled

Patrick: note on the existing meaningful sequence SC that also mentions that users have different viewport ratios and this applies to all. Doesn't change the meaning of the SC but clarifies. Applies to mobile as well as desktop.

Kathy: maybe this is not a technique but– an addition to the understanding document

<scribe> ACTION: Kathy to draft addition to understanding document 1.3.2 about meaningful sequence for different viewport [recorded in http://www.w3.org/2017/01/26-mobile-a11y-minutes.html#action02]

<trackbot> Created ACTION-57 - Draft addition to understanding document 1.3.2 about meaningful sequence for different viewport [on Kathleen Wahlbin - due 2017-02-02].

Kathy: 1.3.3 sensory characteristics. We'd talked about this in the context of a touchscreen – so users know where the spots are actually located

Patrick: you shouldn't rely on particular locations so now if we propose a technique about that it seems in contrast to the SC backspace unless it says even though you shouldn't rely on spatial, here's more you can do

Kathy: I agree. What if we added a paragraph to the understanding on this stating that it would be helpful for users who are using a touch screen to know the location so have additional information in there that could be the location but it does not rely just on that

Patrick: you can do this but make sure you don't rely on it – just additional hint

Kathy: useful for blind users so they know where it is on a page

<scribe> ACTION: Kathy to draft understanding addition for 1.3.3 additional hint on location [recorded in http://www.w3.org/2017/01/26-mobile-a11y-minutes.html#action03]

<trackbot> Created ACTION-58 - Draft understanding addition for 1.3.3 additional hint on location [on Kathleen Wahlbin - due 2017-02-02].

Kathy: 1.4.4 issues

Patrick: pinch zoom either user agents have specific setting or they just ignore it so I think the issue itself around that technique has fallen by the wayside. Additionally in HTML specification and CSS adaptation I submitted notes – we've covered all the bases without needing an explicit technique

Kathy: how about a technique for iOS on how to support the Apple font

Patrick: that could be valuable

Chris: yes, a lot of people don't know about that

Kathy: blog item I can adapt for technique

Patrick: whoever take this on might be worth checking chrome – question is sizing, not sure if it also inherits the user-defined size

Jon: I believe it does

Patrick: it's worth adding if it is indeed the case

<scribe> ACTION: 1.4.4 larger text size Jon to write technique [recorded in http://www.w3.org/2017/01/26-mobile-a11y-minutes.html#action04]

<trackbot> Error finding '1.4.4'. You can review and register nicknames at <http://www.w3.org/WAI/GL/mobile-a11y-tf/track/users>.

<scribe> ACTION: 1.4.4 larger text size Jon_avila to write technique [recorded in http://www.w3.org/2017/01/26-mobile-a11y-minutes.html#action05]

<scribe> ACTION: 1.4.4 Jon_avila to write technique larger text size [recorded in http://www.w3.org/2017/01/26-mobile-a11y-minutes.html#action06]

<trackbot> Error finding '1.4.4'. You can review and register nicknames at <http://www.w3.org/WAI/GL/mobile-a11y-tf/track/users>.

Kathy: 1.1.4, on page controls

Patrick: technique would be right lots of JavaScript – actual button in your page

<scribe> ACTION: Chris to write new technique, 1.4.4, on page controls [recorded in http://www.w3.org/2017/01/26-mobile-a11y-minutes.html#action07]

<trackbot> Created ACTION-59 - Write new technique, 1.4.4, on page controls [on Chris McMeeking - due 2017-02-02].

Patrick: dropping M016, M018, M013, MO21

Kathy: 1.4.8 M009 viewport width

Patrick: 1.4.8 does have in its current form – does have to be changed not only for mobile different levels of zoom levels. Low vision might later want to look at this of actually changing current 1.4.8 if they are not already doing that

Kathy: or even just doing this under silver

Patrick: little tidbits written when desktop was only platform and this made sense but look at knowing that user can have any kind of screen size – more realistic than just adding a technique

Kathy: will put this under silver
... 2.1.1 keyboard
... two techniques – interface can be used with physical keyboard. Ensure that navigation can work with different screen sizes. Not sure that this is specific to mobile or you would do anything different with mobile

Patrick: for the keyword one I can't off and think of a scenario where you would satisfy 2.1.1 in its current form and somehow block the use of a physical keyboard

Chris: there's an issue on android where the keyboard navigation and the slight gesture navigation – you don't end up using the same focus order and you could end up with navigation traps that exist in the keyboards version of sequential navigation versus the gesture-based sequential navigation. That whether that belongs here or not and not under sequential navigation itself – but you can...
... end up with things being accessible on one without the other

Kathy: HTML or native

Chris: anything that exists in native can exist in HTML it's just a matter of how long it takes to catch up

Kathy: so if we had one under no keyboard trap do you want to write that up Chris

<scribe> ACTION: Chris to write up technique under no keyboard trap 2.1.1 [recorded in http://www.w3.org/2017/01/26-mobile-a11y-minutes.html#action08]

<trackbot> Created ACTION-60 - Write up technique under no keyboard trap 2.1.1 [on Chris McMeeking - due 2017-02-02].

Kathy: could add something under keyboard understanding – when you go into keyboard X make sure that all controls are keyboard accessible
... 2.1.1 note – calling out for mobile

Patrick: probably even more general – if your interface changes at different screen or viewport sizes make sure all elements also work with keyboard at all those sizes – at a very high level. Example small viewports, hamburger menu make sure that that also can be opened and closed correctly and navigated correctly with a keyboard

<scribe> ACTION: Patrick to write 2.1.1 note [recorded in http://www.w3.org/2017/01/26-mobile-a11y-minutes.html#action09]

<trackbot> Created ACTION-61 - Write 2.1.1 note [on Patrick Lauke - due 2017-02-02].

Kathy: moving on to no time – I don't see anything specifically needed for mobile – anybody else?
... will stop there and pick up on 2.3

next steps

Kathy: continuing to identify, then finalizing and we will submit those two WCAG 2.0 and those will get incorporated in. Once we submit those those will just go in to review, and they would then transfer over to 2.1

Patrick: I would argue that the two notes are purely editorial, don't change the meaning of the SC so fair game to submit

Kathy: a lot of those will go through if they don't affect Sc's
... we will meet next week

This is scribe.perl Revision: 1.148  of Date: 2016/10/11 12:55:14  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: Kim
Inferring ScribeNick: Kim
Present: Kathy shadi patrick_h_lauke jon_avila chriscm Kim Henny
Found Date: 26 Jan 2017
Guessing minutes URL: http://www.w3.org/2017/01/26-mobile-a11y-minutes.html
People with action items: 1.4.4 chris jon jon_avila kathy larger patrick size text