IRC log of mobile-a11y on 2014-05-16
Timestamps are in UTC.
- 12:46:29 [RRSAgent]
- RRSAgent has joined #mobile-a11y
- 12:46:29 [RRSAgent]
- logging to http://www.w3.org/2014/05/16-mobile-a11y-irc
- 12:46:31 [trackbot]
- RRSAgent, make logs public
- 12:46:31 [Zakim]
- Zakim has joined #mobile-a11y
- 12:46:33 [trackbot]
- Zakim, this will be WAI_MATF
- 12:46:33 [Zakim]
- I do not see a conference matching that name scheduled within the next hour, trackbot
- 12:46:34 [trackbot]
- Meeting: Mobile Accessibility Task Force Teleconference
- 12:46:34 [trackbot]
- Date: 16 May 2014
- 12:46:53 [Kathy]
- zakim, this will be 6283
- 12:46:53 [Zakim]
- I do not see a conference matching that name scheduled within the next hour, Kathy
- 12:47:07 [Kathy]
- agenda?
- 12:47:30 [Kathy]
- agenda+ 1.New Mobile WCAG Techniques & Best Practices - https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/New_WCAG_2.0_Techniques. We will review the results of the survey: https://www.w3.org/2002/09/wbs/66524/20140512_survey/results
- 12:47:45 [Kathy]
- agenda+ 2.Next Steps - next meeting will be Friday May 30th. There will be no meeting on Friday May 23rd.
- 12:47:48 [Kathy]
- agenda?
- 12:48:10 [Kathy]
- rrsagent, make log world
- 13:04:18 [Kathy]
- zakim, this will be 6283
- 13:04:20 [Zakim]
- ok, Kathy; I see WAI_MATF()10:00AM scheduled to start in 56 minutes
- 13:29:19 [KimPatch]
- KimPatch has joined #mobile-a11y
- 13:49:16 [wwu]
- wwu has joined #mobile-a11y
- 13:52:56 [Zakim]
- WAI_MATF()10:00AM has now started
- 13:53:03 [Zakim]
- +Kim_Patch
- 13:53:31 [Zakim]
- +Kathy_Wahlbin
- 13:56:39 [kathleen]
- kathleen has joined #mobile-a11y
- 13:59:20 [Zakim]
- + +1.910.278.aaaa
- 13:59:36 [kathleen]
- zakim, aaaa is me
- 13:59:37 [Zakim]
- +kathleen; got it
- 14:00:15 [jeanne]
- jeanne has joined #mobile-a11y
- 14:00:42 [Kathy]
- http://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/New_WCAG_2.0_Techniques
- 14:01:55 [Zakim]
- +Jeanne
- 14:02:03 [Zakim]
- +WuWei
- 14:02:59 [jeanne]
- zakim, who is here?
- 14:03:01 [Zakim]
- On the phone I see Kim_Patch, Kathy_Wahlbin, kathleen, Jeanne, WuWei
- 14:03:01 [Zakim]
- On IRC I see jeanne, kathleen, wuwei, KimPatch, Zakim, RRSAgent, Kathy, MichaelC, trackbot
- 14:05:03 [jeanne]
- scribe: jeanne
- 14:05:14 [Kathy]
- https://www.w3.org/2002/09/wbs/66524/20140512_survey/results
- 14:06:28 [jon_avila]
- jon_avila has joined #mobile-a11y
- 14:06:35 [Zakim]
- +[GVoice]
- 14:06:54 [jon_avila]
- zakim, I am +[GVoice]
- 14:06:54 [Zakim]
- sorry, jon_avila, I do not see a party named '+[GVoice]'
- 14:07:01 [jon_avila]
- zakim, I am GVoice
- 14:07:01 [Zakim]
- ok, jon_avila, I now associate you with [GVoice]
- 14:09:07 [Kathy]
- http://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Technique_Development_Assignments
- 14:09:56 [jeanne]
- [intro to survey]
- 14:10:24 [jeanne]
- KW: We still need to identify which apply to mobile, mobile apps, and hybrid
- 14:10:43 [Kathy]
- https://www.w3.org/2002/09/wbs/66524/20140512_survey/results
- 14:11:08 [jeanne]
- ... I reviewed the funka nu best practices and did a gap analysis which i added to the new techniques page
- 14:11:31 [jeanne]
- topic: Survey Q1
- 14:11:52 [jeanne]
- KW: we could break this into multiple techniques and possibly a failure technique
- 14:12:19 [jeanne]
- ... there are a lot of ways that someone can control their device: bluetooth keyboard, switch, etc.
- 14:12:34 [jeanne]
- ... what would be a path for WCAG for keyboard access?
- 14:12:53 [jeanne]
- q+
- 14:14:01 [Zakim]
- -Kathy_Wahlbin
- 14:14:26 [jon_avila]
- q+
- 14:14:42 [Zakim]
- +Kathy_Wahlbin
- 14:15:34 [jeanne]
- JS: Alan had a good point that if the device doesn't support bluetooth or any other connection, it seems overboard to require the app to do so. I think we need to word the technique around this.
- 14:15:46 [Zakim]
- -Kathy_Wahlbin
- 14:16:32 [Zakim]
- + +1.978.760.aabb
- 14:16:33 [jeanne]
- JA: If you have an app on a phone that doesn't support addon devices, then WCAG cannot be supported.
- 14:17:05 [jeanne]
- ... you could never meet that
- 14:17:07 [Kathy]
- zakim, aabb is Kathy
- 14:17:07 [Zakim]
- +Kathy; got it
- 14:17:19 [jeanne]
- JS: Isn't that Accessibility Supported Technology?
- 14:17:27 [jeanne]
- JA: That's a part of it.
- 14:17:37 [jeanne]
- zakim, who is making noise?
- 14:17:48 [Zakim]
- jeanne, listening for 10 seconds I heard sound from the following: Kim_Patch (4%), [GVoice] (73%)
- 14:18:14 [jeanne]
- zakim, mute [GVoice]
- 14:18:14 [Zakim]
- [GVoice] should now be muted
- 14:18:31 [jeanne]
- zakim, unmute [GVoice]
- 14:18:31 [Zakim]
- [GVoice] should no longer be muted
- 14:19:09 [Zakim]
- -[GVoice]
- 14:19:45 [Zakim]
- +[GVoice]
- 14:22:14 [jeanne]
- JA: Example: if you have audio description for a multimedia presentation, but didn't have enough room to pause, and you made extended audio descriptions, you could meet WCAG AAA, but not AA.
- 14:22:52 [jeanne]
- KW: If you could do everything with the keyboard, but you were on a device that didn't have a keyboard, could you claim compliance?
- 14:24:18 [jeanne]
- ... the default interaction with a desktop is keyboard, so you have to meet keyboard access to comply, but on mobile, the primary mobile input is touch and gestures, so when we are looking at keyboard access and defining what keyboard access is, there has to be some way to input.
- 14:24:18 [jon_avila]
- zakim, I am GVoice
- 14:24:18 [Zakim]
- ok, jon_avila, I now associate you with [GVoice]
- 14:24:24 [jon_avila]
- q+
- 14:24:40 [jeanne]
- ... what do we say for what the minimum, or what should be required on a mobile device?
- 14:24:43 [jeanne]
- ack je
- 14:26:35 [jeanne]
- JA: We could take a functional approach, and say that you have to have an input method that doesn't require speech, vision, etc.
- 14:26:52 [jeanne]
- ... we could require a method that serves the most people
- 14:29:26 [KimPatch]
- Jeanne: keyboard is the most useful interface – not physical keyboard, but the concept of the keyboard was the most universal because which could use a keyboard, Bluetooth keyboards could be attached, individual tapping of a virtual keyboard is very common, so keyboard was the most universal of the input types because people can always emulate a keyboard. The danger with the functional...
- 14:29:28 [KimPatch]
- ...approach is that it can easily be set up to exclude people, especially people with multiple disabilities. I would really encourage us to keep looking at this and finding a way that we could approach this that would not leave out people – particularly people with multiple disabilities
- 14:30:30 [jeanne]
- KW: I think that the keyboard is not the most universal device on mobile
- 14:30:52 [jeanne]
- KP: I htink it depends on what you are doing. you could spend the whole day on keyboard on a mobile device.
- 14:31:27 [jeanne]
- kW: If you have everything you can access with a bluetooth keyboard, does that mean that everything can be accessed with switch and keyboard.
- 14:32:07 [jeanne]
- JA: i don't know how to support the iOS problem, where it is very accessible, but it doesn't support keyboard access to everything.
- 14:32:23 [jeanne]
- ... there is a product that can take advantage of that interface.
- 14:33:40 [jeanne]
- JA: propose: defining that an alternative would be exposed and it would be programmatically supported to that interaction.
- 14:34:58 [jeanne]
- ... the product can take advantage of the input exposed, and the application could take advantage of the action that the item can performed programmatically in some way.
- 14:36:00 [jon_avila]
- sounds good
- 14:36:01 [jeanne]
- KW: i think we should call this out in the notes and take it to the different working groups for more feedback from WcAGWG and UAWG
- 14:37:18 [jeanne]
- KW: I think it would be a sufficient technique, and could be a failure technique if it doesn't support keyboard
- 14:38:03 [jeanne]
- JA: In a programmatic way, if it didn't support keyboard emulation
- 14:39:07 [jeanne]
- ... it goes back to Accessibility Supported. It's a broad term. It would also have to work with switch control or keyboard. It also goes back to the device, if it didn't have the device support, it isn't Accessibility Supported.
- 14:39:42 [jeanne]
- KW: the failure would be that it didn't have an input method that was accessibility supported.
- 14:39:58 [jeanne]
- kathy: that would be a failure of the device platform and not of the app
- 14:40:50 [jeanne]
- JA: If it worked on a platform, and failed on a different platform because the platform doesn't support it, then they could make an argument for accessibility supported.
- 14:41:21 [jeanne]
- Kathy: we shouldn't penalize the developer because of a failure of the platform
- 14:41:53 [jeanne]
- KW: you might define your platform as X and Y and not support Z because of a lack of accessibility support.
- 14:42:09 [jeanne]
- ... it is so much more complex on mobile because of all the variations of platform
- 14:42:44 [jeanne]
- JS: The app must support the programmatic access to the platform
- 14:44:00 [jeanne]
- JS: We should take it to UAWG, because they have worked on this a lot and have a lot of language already worked out.
- 14:44:15 [jeanne]
- KW: We have it as a sufficient technique and as a failure technique
- 14:44:23 [jeanne]
- topic: Survey Q2
- 14:44:37 [jeanne]
- 2. Provide visual/audio indication for all functions
- 14:45:20 [jeanne]
- KW: on the desktop, you have focus indicator, but how do you alert people to the functional areas of the screen on mobile/
- 14:45:35 [jeanne]
- s/mobile/mobile?
- 14:45:37 [wwu]
- wwu has joined #mobile-a11y
- 14:45:59 [jon_avila]
- q+
- 14:46:15 [jeanne]
- ack jon
- 14:46:22 [jeanne]
- ack {G
- 14:46:28 [jeanne]
- ack [GV
- 14:47:51 [jeanne]
- JA: Two things - I'm not sure everything has to have an audio -- if you have the programmatic correct, it could be announced by a screenreader. Are we aiming it so it is available to assistive technology? i don't think we need to have it read aloud.
- 14:50:06 [jeanne]
- KW: Let's considr this a duplicate of #28, that seems like better wording.
- 14:50:23 [jeanne]
- topic: 3. Provide instructions for custom functions and gestures
- 14:50:45 [jeanne]
- JA: Is advising the user different from providing instructions
- 14:51:19 [jeanne]
- ... we have to be more clear about where it needs to be. Are we advising the user or providing instructions
- 14:52:41 [jeanne]
- JA: 3.3.2 is about instructions for input. This appears to be more about keyboard access -- maybe the keyboard trap technique may be helpful. It says if it requires more than one keystroke, the user must be advised of the method for moving away.
- 14:53:06 [jeanne]
- ... we could use that language, this is not a keyboard trap
- 14:53:23 [jeanne]
- ... if you have a custom gesture, then you have to advise the user.
- 14:53:54 [jeanne]
- ... I'm not sure it should be connected to 2.2.1 keyboard input, maybe it maps to 3.3.2
- 14:55:11 [jeanne]
- kW: I'm not sure how it maps to WCAG, but I think i agree
- 14:55:32 [jeanne]
- JS: i'm not sure it is an accessibility issue, it seems more like a usability issue.
- 14:56:23 [jeanne]
- KW: Example: there is a gesture to expand an area by swiping up and down that people are using in apps. You need to perform the gesture to perform that action.
- 14:57:35 [jeanne]
- JA: And there is no instructions for how it would be executed with a keyboard.
- 14:58:29 [jeanne]
- jS: So it seems that the alternative input instruction is more of an issue than the custom gesture instruction.
- 14:59:28 [jeanne]
- JS: provide instructions for alternative input for custom gestures and functions
- 15:00:17 [jeanne]
- JA: I would prefer advise rather than instructions
- 15:01:24 [Kathy]
- Provide advisement on custom gesture and functions for alternative input
- 15:01:52 [jeanne]
- WCAG: The user is advised of the behavior before using the component
- 15:02:20 [Kathy]
- The user has been advised on custom gestures and functions for alternative input
- 15:03:12 [jeanne]
- The user is advised of the alternative input of custom gestures and functions
- 15:03:40 [jeanne]
- JA: Qualify it with "when alternative is not available with standard input method"
- 15:04:39 [jeanne]
- The user is advised of the alternative input of custom gestures and functions when alternative is not available with standard input methods.
- 15:04:50 [jeanne]
- kW: This would be a sufficient and also a failure.
- 15:05:42 [jeanne]
- Topic: next meeting
- 15:05:49 [jeanne]
- no meeting next week because of holiday
- 15:06:08 [Kathy]
- http://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Technique_Development_Assignments
- 15:06:21 [jeanne]
- Go through the techniques and identify which are applicable to mobile web, mobile apps or both.
- 15:06:27 [jeanne]
- rrsagent, make minutes
- 15:06:27 [RRSAgent]
- I have made the request to generate http://www.w3.org/2014/05/16-mobile-a11y-minutes.html jeanne
- 15:06:33 [Zakim]
- -Kathy
- 15:06:34 [Zakim]
- -[GVoice]
- 15:06:34 [Zakim]
- -kathleen
- 15:06:44 [Zakim]
- -WuWei
- 15:06:44 [jeanne]
- rrsagent, make logs public
- 15:07:53 [jeanne]
- present+ jeanne, jon, kathy, kim, kathleen, WuWei
- 15:08:10 [jeanne]
- chair: Kathy
- 15:08:25 [jeanne]
- rrsagent, make minutes
- 15:08:25 [RRSAgent]
- I have made the request to generate http://www.w3.org/2014/05/16-mobile-a11y-minutes.html jeanne
- 15:16:03 [Zakim]
- -Kim_Patch
- 15:16:04 [Zakim]
- -Jeanne
- 15:16:05 [Zakim]
- WAI_MATF()10:00AM has ended
- 15:16:05 [Zakim]
- Attendees were Kim_Patch, Kathy_Wahlbin, +1.910.278.aaaa, kathleen, Jeanne, WuWei, [GVoice], +1.978.760.aabb, Kathy
- 17:54:23 [Kathy]
- Kathy has left #mobile-a11y
- 17:58:00 [jeanne]
- regrets+ Alan
- 17:58:05 [jeanne]
- rrsagent, make minutes
- 17:58:05 [RRSAgent]
- I have made the request to generate http://www.w3.org/2014/05/16-mobile-a11y-minutes.html jeanne