trackbot, start meeting

<trackbot> Meeting: Mobile Accessibility Task Force Teleconference

<trackbot> Date: 28 July 2016

Patrick's pull requests

<patrick_h_lauke> https://github.com/w3c/Mobile-A11y-Extension/pull/9

Patrick: we did talk about that on the last call – I think generally the feeling was that it was mostly hitting the right notes. Will add David's suggestion

<patrick_h_lauke> https://github.com/w3c/Mobile-A11y-TF-Note/pull/37

Patrick's Comments on the note

<patrick_h_lauke> https://github.com/w3c/Mobile-A11y-TF-Note/pull/37/files

Patrick: talks about HTML 5 form fields – just about the correct type of input that the user agent will switch to the appropriate keyboard. Input method editor API is generally more about complex scenarios for IME where you have Japanese where you need to tweak the keyboard

Kathy: I'm fine with those changes – anybody have objections?

<davidmacdonald> fine w me

<Alan_Smith> Alan +1

no objections

<Detlev> +1

Touch and other input methods proposal  (Patrick, Detlev & Chris)

Kathy: on the agenda today we have to go over the recommendations on touch and other input methods – Patrick's githhub link.

<patrick_h_lauke> https://gist.github.com/patrickhlauke/96110b10547770021e58f5098dd31087

Patrick: go to that link – this is all very rough. Conversation with Detlev, who summarized into list of SCs. I fleshed out some of them. This is diametrically opposite from my previous approach of generalizing 2.1. This approach is put down all sorts of input methods scenarios and see what we need to do with them

<davidmacdonald> cursory reading

Patrick: we talk a lot about keyboards. There are specific things for keyboard with AT. We talked about touch. Similar keyboard scenario – jaws lead to certain situations where if an author has – still satisfying 2.1.1 and 2.1.3 and author has added custom events for any arbitrary keys on the keyboard, they pass 2.1.1 but as soon as assistive tech is running on top of the regular browser...
... and you've got a physical keyboard situation where you're not able to hit particular keys because the AT will swallow those keystrokes
... AT and speech like we talked about last week we generally fall under this
... when it's touch with assistive tech or speech with assistive tech – high level of events move the focus to this particular element – this helps disambiguate some of the discussion that we always have with some of the things about gestures and swipes and differentiating whether author has to do something about it or AT interprets
... this tries to separate that out in a sensible way.

Detlev: author requirement – say web app that has keyboard shortcuts, to author to make sure there's always another way, say a menu or on-screen that will do the same thing as the keyboard shortcut. Would that be a requirement – I'm not sure which would take precedent the AT or the authors keyboard shortcut

Patrick: under 2.6.1 requirements and techniques – you have to have some other form of control. You can have keypress handlers but you have an alternative. You're not relying on the fact that a user can press an arbitrary key at any point they want. This also plays into touchscreen where the user can't always trigger the on-screen keyboard and therefore can't always trigger arbitrary keys
... there's probably a little bit of overlap in certain area but obviously satisfying all of these will make sure it's input agnostic or have all the things that work for all the different scenarios of input
... the short answer is have a button that can be focused. The point of a shortcut is that they are shortcut – you can still use those if you provide a menu it might take two or three steps to get to that functionality but as long as the end result is that the user can still actually get to it even if they cannot trigger arbitrary keystrokes that's the idea
... a lot of the wording is not in a final SC stage – this was just to give some initial direction of these other sorts of things where we're thinking about covering. Some may get tweaked or merged, touch with AT we've already written that out, might need tweaking
... 2.7 advanced input that covers what we talked about – we called fancy pointers which is a stylus that recognizes tilt and twist, or a pressure sensitive touchscreen
... also when you have additional sensors on the device 2.72 – similarly feel free to take advantage of extra information such as twist, light sensor information or rotation of a device, however users may not have that sensor or have the sensor but not be able to use it at all or accurately enough therefore make sure that functionality is also available in a fashion that does not use...
... these sensors. Particularly with force touch that gels with Apple advice in guidelines – force touch is shortcut
... there will be exceptions but we want to say that if the primary purpose of your app is to do this – something like a game that you explicitly want to make only tilt control or something like that or brushstroke emulator – that may be an exception
... however if that is not the core intent of the app you have to abide by this SC
... need wordsmithing and gathering use cases, good examples of where this applies and what we actually mean by this. Rough brain dump at the moment

Kathy: there are areas where it's already written and finalized. Was there anything that you merged or did you take what we had there and reorganize it and add to that

Patrick: I don't think we dropped anything. We just added bits around it and cobbled it together in some areas

<davidmacdonald> http://www.davidmacd.com/blog/should-WCAG-require-all-functionality-by-mouse.html

David: I think it's the approach that we need to make in terms of stepping back and being very granular and getting things past piece by piece. I think there's a lot of review and maybe that's useful to bring us all on the same page. Important to understand what the previous people have been doing. The one new thing is 2.5.1 – previously was assistive technology thing. What were introducing...
... here is the pointer accessibility. I've been asking shouldn't we be requiring all functionality by mouse. Pretty big requirement that we haven't had previously. This is a big new introduction of something.
... most usability people are creating things to be usable by mouse these days but we kind of left that out of WCAG. is it in our jurisdiction to bring this forward or just go to the larger group?

Kathy: we've been looking at touch and pointer it's fine to do here. We are talking touch and pointer

Patrick: were talking mouse, touch, stylist – anything that falls under the choose an X and Y point on the screen
... it's a big one – it's one of those elephant in the room issues. especially if we start looking at all these other types of inputs and modalities it would be a strange omission not to have that there. If it is as many say implied, then it should not be a problem the past that SC.

David: I'm intrigued whether we should or not. My concern around the whole requiring pointer is this is the kind of thing that could take up quite a bit of our bandwidth if we pursue it to try to get to an SC stage with it. I'm wondering whether we want to put it as a priority after we get the other ones that we feel really are causing trouble.
... I haven't found any user that's asked me about this. I'm wondering if anyone else has found this as an accessibility issue or if it's just a matter of completeness

Kathy: I think there are new devices out there that are tapping onto the pointer technology now

Jeanne: I think this is about making ourselves technology neutral, making us more forward compatible – trying to instead of having 2.1 just the oriented toward past problems and past technology we're really making the orientation more future proof

Kathy: as far as what we have to have done for December were proposing the success criteria – will going to take a look at all of those and flesh out – December deadline just success criteria and understanding
... there's a lot to get to that point but lot of these like touch target size are almost finished. We could put this down and get to some of the other ones first especially the ones that are almost done

David: I think the next step is now to start to create the success criteria and plug in what we have already. AT remapping is pretty close to being done. 2.5.1 keep it as it is now until the other ones are done

Kathy: keep in mind that the numbering means nothing

Patrick: my main concern was making sure that we cover all the bases – speech input as well under the inputs with assistive tech. And we can see are we missing anything – are there gaps that we haven't even considered?

<davidmacdonald> +1

Patrick: situations on-screen keyboard or if you're using speech and saying press a press b – I think the end result of that is it emulates a keyboard and key events so those kinds of things relating to that would generally fall onto the keyboard type of requirements. It's about divorcing what the user is really doing and what is the end result that the app sees. Does the app think it's a...
... keyboard event regardless of whether it's a keyboard or on-screen keyboard
... purely the ones that using the accessibility API actually programmatically move the focus in the UA to a particular element without say faking 20 tabs strokes or something like that.. The ones that actually activate something

Alan: with wearable devices – we may have others things, proximity – wearable devices may present new avenues of user input also

Patrick: it would depend on what it looks like to the app
... proximity might translate into a touch. If we had indie UI and it was developed further that would be great, but I haven't seen any indication. Could also fall under device inputs. We need to make sure that were released open ended for the possibility of the types of events

<jon_avila> not at the moment

<Alan_Smith> "that we are at least open ended"

yes - scribe speako

<marcjohlic> So a +1 from me :)

David: next step look at comments

Kathy: does it make sense to continue on this document or incorporate it in a pull request – what's gonna be helpful for you?

Patrick: purely for myself I find it easier to look at this because this covers just the input type stuff so it makes it – zoom on my browser a bit so I get a better overview. It's a little bit lost on the bigger document. Personally I find it easier at this stage – but it doesn't make a huge bit of difference. Maybe take another two weeks to flesh it out, then drop it in.

Kathy: we want to Inc. in before the end of the month for sure. We do need to go through the rest of the comments. So would be good to look at one document one we are going through the comments.
... need to incorporate only in one area when we do that

David: does it make sense to collapse everything we are not working on, that's outside our scope

<davidmacdonald> http://davidmacd.com/blog/an-accessible-expand-collapse-mechanism.html

Jeanne: I'm pretty flexible, I have to adjust my way of working to pulling the branch and putting in the requests. I can accept pull requests – when they are ready

<patrick_h_lauke> https://w3c.github.io/Mobile-A11y-Extension/

Patrick: it's already quite cut down a for looking at this
... once I go through this and respect properly so it also generates the table of contents that will help – document outline on the left-hand side

Kathy: Jeanne does that make sense if he puts it in respec

<patrick_h_lauke> respec is a dark art...

<patrick_h_lauke> dark and annoying

Jeanne: have to figure that out

Kathy: any other comments

<davidmacdonald> +1

<Detlev> +1

Kathy: great work – thanks for going through that. Next week we'll go back through those, work in parallel with the other ones

look at all the success criteria that we had suggested for mobile and identify any other gaps that were missing or other concerns that you may have, then we can get those scheduled to talk about

David: everything that I was concerned about with mobile is in there now

Kim: longer discussion about speech at some point, some issues are queued up here: https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Speech_Input_Accessibility_(Guideline_2.7)

pay no attention to the number – feel free to add to this document

Chris: switch access – I don't know if we have time to talk about that now

Kathy: we can put that as an item to talk about
... anything else
... if you do think of anything else let me know and will start getting a consensus together. I'm going to put together a rough timeline with Kim to go over– the beginning of December is going to come quickly. If you do have any other topics of things we need to cover let me know and we'll get them scheduled in. anything else?

<jeanne> +1, GJ thanks

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
Present: Kathy patrick_h_lauke jon_avila DavidMacDonald jeanne Alan kim Henny Chris Detlev
Regrets: Alistair
Found Date: 28 Jul 2016
Guessing minutes URL: http://www.w3.org/2016/07/28-mobile-a11y-minutes.html
People with action items: