15:15:30 <RRSAgent> RRSAgent has joined #ag
15:15:30 <RRSAgent> logging to http://www.w3.org/2017/06/22-ag-irc
15:15:32 <trackbot> RRSAgent, make logs public
15:15:32 <Zakim> Zakim has joined #ag
15:15:34 <trackbot> Zakim, this will be WAI_WCAG
15:15:34 <Zakim> ok, trackbot
15:15:35 <trackbot> Meeting: Accessibility Guidelines Working Group Teleconference
15:15:35 <trackbot> Date: 22 June 2017
15:15:36 <Joshue108> Chair: Joshue
15:15:44 <Joshue108> zakim, agenda?
15:15:44 <Zakim> I see nothing on the agenda
15:16:01 <Joshue108> agenda+ EOWG 'Accessible Media Tutorial' https://www.w3.org/2002/09/wbs/35422/2017-06_wai-media-intro/
15:16:11 <Joshue108> agenda+ New MATF SCs (Speech Input / Accessibility Name, Concurrent Input Mechanisms)
15:16:11 <Joshue108> https://www.w3.org/2002/09/wbs/35422/MATFSC_june/
15:25:53 <Kathy> Kathy has joined #ag
15:27:50 <Greg> Greg has joined #ag
15:28:10 <jasonjgw> present+
15:28:53 <shadi> shadi has joined #ag
15:29:33 <Kathy> present+ Kathy
15:29:51 <shadi> present+
15:30:11 <Rachael> Rachael has joined #ag
15:30:19 <Joshue108> present+ Joshue108
15:33:20 <Joshue108> https://www.w3.org/2002/09/wbs/35422/MATFSC_june/
15:33:24 <Greg> present+ Greg_Lowney
15:34:21 <Rachael> Scribe: Rachael
15:34:26 <Rachael> present+ Rachael
15:34:33 <Rachael> Zakim Takeup 1
15:34:48 <Joshue108> zakim, next item
15:34:48 <Zakim> agendum 1. "EOWG 'Accessible Media Tutorial' https://www.w3.org/2002/09/wbs/35422/2017-06_wai-media-intro/" taken up [from Joshue108]
15:34:49 <Rachael> Zakim, next
15:34:50 <Zakim> I don't understand 'next', Rachael
15:35:30 <Rachael> Joshue: New accessible media tutorial. Take a look at it. We've had good response.
15:35:42 <Alex> Alex has joined #ag
15:35:56 <KimDirks> KimDirks has joined #ag
15:36:08 <Rachael> Joshue: We are looking for a technical review, so anything wrong or that could be improved please flag.
15:36:57 <Rachael> Shadi: Editors are still iterating and refining it. Try not to get distracted by that. Most important: Is thi sin line with WCAG?
15:37:01 <jasonjgw> q+
15:37:04 <Rachael> Joshue: Please take a look at it if you haven't already.
15:37:09 <Joshue108> ack jas
15:37:21 <Rachael> Jason: Quickly read through it and it seems fine to it.
15:38:11 <Rachael> zakim, next item
15:38:11 <Zakim> agendum 2. "New MATF SCs (Speech Input / Accessibility Name, Concurrent Input Mechanisms)" taken up [from Joshue108]
15:38:36 <Rachael> Joshue: We have a couple of new candidate success criteria to take a look at. We'll look at those now.
15:38:36 <Joshue108> https://www.w3.org/2002/09/wbs/35422/MATFSC_june/results
15:38:40 <Rachael> Kathy: Should I take them through that?
15:38:58 <Joshue108> zakim, ping me in 20 minutes
15:38:58 <Zakim> ok, Joshue108
15:39:01 <Rachael> Joshue: Yes. We are dividing the rest of the call between both of them. 20-25 minutes for the first?
15:40:10 <Rachael> Kate: The first one originated from a requirement for speech. The reason this is important is becuase we sometimes have applications/websites that have a button or control that does not include all visible information in the control name.
15:40:44 <Rachael> This is simply saying the accessible name for the control needs to include the text string available to the visible label.
15:40:45 <Greg>  /me Rachael, add topic header for this question into transcript?
15:41:10 <Joshue108> q?
15:41:20 <Joshue108> q+ to ask about icons etc?
15:41:24 <Rachael> Topic: 1. Speech Input / Accessibility Name #68
15:41:25 <Joshue108> ack me
15:41:25 <Zakim> Joshue, you wanted to ask about icons etc?
15:41:45 <gowerm> gowerm has joined #ag
15:42:01 <Rachael> Joshue: How do icons relate to controls? What about visual affordances? Does that need to be included or is this only visible text?
15:42:05 <gowerm> present+ MikeGower
15:42:30 <KimDirks> Present+ KimDirks
15:42:48 <Rachael> Kathy: This is only visible text, not the icon.  The accessibe name for hte control should be in the help documentation but that isn't testing. That woudl be good for the best practice document.
15:43:06 <Rachael> Kathy: Just hte icon alone doesn't fall into this.
15:43:12 <Rachael> Scribe: Gowerm
15:43:27 <allanj> allanj has joined #ag
15:44:07 <gowerm> q+
15:44:23 <Joshue108> ack gower
15:44:27 <steverep> steverep has joined #ag
15:44:40 <Joshue108> MG: Just to confirm you removed text about the position of the name etc?
15:44:43 <steverep> present+steverep
15:44:44 <Joshue108> KW: Yes.
15:44:46 <jasonjgw> q+
15:45:21 <Greg> q+ to ask about labeling as temporary content
15:45:26 <gowerm> MikeGower: Does it contain any mention of position?
15:45:35 <Joshue108> ack jas
15:45:40 <gowerm> Kathy: No, that has been removed. It is now mentioned as a best practice
15:46:26 <gowerm> Jason: Possible exception is to use terminology of user interface components
15:46:57 <gowerm> Jason: I haven't come up with situations where this would be a bad idea. We need to make sure there are none, and where there are, we need an exception.
15:47:15 <Joshue108> +1 to Kathy on AccName
15:47:17 <gowerm> Kathy: Could not find such cases. Accessible name is already defined for accessible name
15:47:39 <steverep> q+ to comment on low vision benefits, suggest not naming this speech input, and also need to remove best practice for labels in front since the opposite is true for chechboxes and radio buttons
15:48:08 <Kathy> Accessible Name The accessible name is the name of a user interface element. Each platform accessibility API provides the accessible name property. The value of the accessible name may be derived from a visible (e.g., the visible text on a button) or invisible (e.g., the text alternative that describes an icon) property of the user interface element. See related accessible description.  A simple use for the accessible name property may be illustrated by an "OK" butt
15:48:26 <gowerm> Jason: concerns with specifity of Accessible Name definition
15:48:46 <gowerm> q+
15:48:56 <Kathy> https://www.w3.org/TR/accname-aam-1.1/#dfn-accessible-name
15:49:00 <Joshue108> ack greg
15:49:00 <Zakim> Greg, you wanted to ask about labeling as temporary content
15:49:11 <gowerm> Kathy: I pasted in the current definition.
15:49:24 <Greg> Should we address the use of transient labels, e.g. hover text or initial content of a text input field or list?
15:49:26 <Greg> It might be a bad idea when author uses inappropriate label, e.g. a whole sentence of instructions.
15:50:03 <gowerm> Greg: It will be for the user when the author has picked a bad label for the visible label.
15:50:16 <gowerm> Greg: For instance a whole sentence.
15:50:43 <Alex> q+
15:50:48 <gowerm> Kathy: We can have that issue for a lot of differnet cases. It might be a point to put in the understanding document, as an example of bad user experience.
15:51:01 <gowerm> Shadi: But that is bad user experience for everyone
15:51:07 <Joshue108> ack steve
15:51:07 <Zakim> steverep, you wanted to comment on low vision benefits, suggest not naming this speech input, and also need to remove best practice for labels in front since the opposite is true
15:51:10 <Zakim> ... for chechboxes and radio buttons
15:51:30 <Joshue108> s/chechboxes/checkboxes
15:51:38 <gowerm> Steve: I agree that putting the label in front doesn't always apply. Checkboxes, radio buttons, etc
15:52:55 <gowerm> Steve: happy that Accessible name is now used as SC name.
15:53:10 <gowerm> Kathy: Agree the SC doc should call those out. Happy to have Steve's help with authoring it.
15:53:17 <Joshue108> ack gower
15:53:43 <Joshue108> MG: The definition of AccName doesn't account for ARIA concatenation etc
15:53:59 <shadi> q+
15:54:01 <Joshue108> MG: May they should consider this?
15:54:06 <shadi> q-
15:54:37 <steverep> Suggest adding a reference to the name calculation document
15:55:08 <Joshue108> q?
15:56:06 <gowerm> Kathy: It doesn't matter how it is implemented. Whatever name is given for the control in the API would be relevant. I think the definiton meets technology concerns.
15:56:17 <Joshue108> ack alex
15:57:00 <gowerm> Alex: Accessible name is available in .NET. Have you done the comparison that is Apples to Apples and used consistently across platforms?
15:57:33 <gowerm> Kathy: The accessible name we are referring to is the property in the accessible API. Those are the same in all
15:57:37 <Kathy> https://www.w3.org/TR/accname-aam-1.1/#dfn-accessible-name
15:57:46 <gowerm> Alex: And you've checked it against UIAutomation, etc?
15:57:58 <Joshue108> q?
15:57:59 <gowerm> Kathy: Yes there is a table (pasted in) that compares them all.
15:58:15 <gowerm> +1
15:58:18 <KimDirks> +1 YES
15:58:20 <Joshue108> +1
15:58:21 <Kathy> +1
15:58:22 <shadi> +1
15:58:24 <steverep> +1
15:58:25 <marcjohlic> +1
15:58:32 <Rachael> +1
15:58:43 <Alex> 0 this is my first look today
15:58:58 <Zakim> Joshue108, you asked to be pinged at this time
16:00:06 <gowerm> RESOLUTION: success criteria Accessible Name accepted for editors draft with minor editorial changes (i.e., removing the note)
16:00:58 <gowerm> Alex: the table only looks at 4 APIs
16:01:05 <gowerm> Michael: There are only 4 in use
16:01:25 <gowerm> Michael: I believe there is a fifth one, but we didn't have information on it.
16:01:46 <gowerm> Zakim, next item
16:01:46 <Zakim> I do not see any more non-closed or non-skipped agenda items, gowerm
16:02:04 <gowerm> TOPIC: Concurrent Input Mechanisms
16:02:41 <gowerm> Kathy: There was concern in MATF this was too broad, and we didn't have time to finalize
16:03:55 <Joshue108> q?
16:04:06 <gowerm> Kathy: We're looking to see if people have suggestions for how to move this one forward, or general thoughts.
16:04:54 <Kathy> The ability to perform an action using a given input device or modality is not restricted due to either of the following: (a) the presence of a different input device or modality on the system; (b) the user having used a different input device or modality at a previous time."
16:04:54 <gowerm> Greg: I was following up on something Patrick and pointed out, which is we don't want to only prevent content from restricting users from using different inputs. Ie., when a touchscreen is detected, disabling mouse.
16:05:05 <Greg> "The ability to perform an action using a given input device or modality is not restricted due to either of the following: (a) the presence of a different input device or modality on the system; (b) the user having used a different input device or modality at a previous time."
16:05:08 <Kathy> The presence of one input device or modality on the system, or the user having used that device, does not prevent the use of any other device for performing subsequent actions
16:06:04 <Greg> Alternate wording might be "The presence of one input device or modality on the system, or the user having used that device, does not prevent the use of any other device for performing subsequent actions"
16:06:14 <gowerm> Kathy: I like both of those suggestions. There was alternate wording I just put into IRC. Looking at one of those 2 might be a way of moving forward
16:06:23 <Joshue108> q?
16:07:25 <gowerm> Greg: This was an attempt to short cricuit the discussion on something broader. We have 2.1.1 as a start for that. It should be a separate discussion rather than hijacking this SC, which is potentially valuable in its own right.
16:07:36 <gowerm> Kathy: Agrees the larger discussion can go in Silver
16:07:50 <Joshue108> q?
16:08:08 <gowerm> Kathy: I think the scope of 2.1.1 is too limited.
16:08:36 <gowerm> Kathy: We can't address 2.1.1 in the time we have
16:09:23 <gowerm> Josh: So what is problematic with Concurrent Input?
16:09:31 <Greg> Correction: we have only postponed changing 2.1.1 until later in the 2.1 process, not forbidden the changes.
16:09:32 <gowerm> Kathy: Greg's suggestions may address.
16:09:55 <gowerm> Kathy: How are we going to test it, and is it testable under 2.1?
16:09:58 <Joshue108> q?
16:10:09 <Greg> I'll push for my proposed change to 2.1.1 (expanding the exception) later in the 2.1 process.
16:10:15 <gowerm> kathy: How do people feel about Greg's suggestion?
16:10:17 <gowerm> q+
16:10:35 <gowerm> 	"The ability to perform an action using a given input device or modality is not restricted due to either of the following: (a) the presence of a different input device or modality on the system; (b) the user having used a different input device or modality at a previous time."
16:10:36 <Kathy> The ability to perform an action using a given input device or modality is not restricted due to either of the following: (a) the presence of a different input device or modality on the system; (b) the user having used a different input device or modality at a previous time
16:11:16 <Alex> q+
16:11:21 <gowerm> Greg: 	Alternate wording might be "The presence of one input device or modality on the system, or the user having used that device, does not prevent the use of any other device for performing subsequent actions"
16:11:25 <Joshue108> ack gower
16:11:42 <Joshue108> MG: Am having problems parsing this, may be hard to test.
16:11:47 <Joshue108> ack alex
16:12:30 <gowerm> Alex: Similar concerns. How does this change in wording address testing issues?
16:12:41 <gowerm> Kathy: That is still the outstanding question
16:12:47 <Joshue108> q+
16:12:52 <Joshue108> -q
16:13:07 <gowerm> Alex: Even if it doesn't work, it may not be prolbem of content. It could be device. How do you ascribe failure?
16:13:18 <Joshue108> q+ to ask how this relates to existing SC like Keyboard Accessible?
16:13:25 <Joshue108> ack me
16:13:25 <Zakim> Joshue, you wanted to ask how this relates to existing SC like Keyboard Accessible?
16:13:43 <jasonjgw> q+
16:13:56 <Greg> q+ to address testability
16:14:12 <gowerm> Kathy: It doesn't chagne keyboard access. All it says that when you switch modality, you aren't restricting input.
16:14:39 <gowerm> q+
16:15:25 <Joshue108> ack jas
16:15:25 <gowerm> Josh: The developer needs to know what listeners to consider. How will this address this?
16:15:31 <gowerm> Kathy: That could be a technique
16:15:38 <gowerm> Jason: I'm trying to think of some of the implications.
16:15:42 <Joshue108> s/chagne/change
16:16:43 <gowerm> Jason: Music-related hardware. You have an online music editor. It needs to handle all those inputs, even though you might have a pointing device and touch display. Are authors going to have to accept keyboard and touch as equivalent to music?
16:17:06 <Joshue108> q?
16:17:09 <gowerm> music hardware.
16:17:38 <gowerm> Jason: I'm trying to think of such exmaples where it might be a good example or a bad example. I'm not sure where music software fits on that spectrum.
16:17:57 <Greg> Jason, No, this does not require authors to add support for any devices, nor make any particular functionality available by any particular device. It only forbids modality where the ability is suddenly turned off.
16:18:32 <gowerm> Kathy: The thought of this is that you always have keyboard access under 2.1.1. For the inputs you are supporting, you are not going to restrict those. So an exception or clarity that it covers the inputs being used by the system is what it is restrcited to.
16:18:53 <Greg> That is, the author does not need to make every function available via a musical keyboard, but pushing keys on the musical keyboard cannot turn off the normal keyboard or pointing device.
16:19:18 <gowerm> Jason: Does that mean that a text field needs to support pointing input as well? I don'
16:19:34 <gowerm> don't want to have to write my own on-screen keyboard input for pointers
16:20:28 <gowerm> Kathy: If we had something about supported inputs for specific controls that would cover.
16:21:07 <gowerm> Kathy: if we focus on not restricting, we get closer
16:21:17 <Joshue108> ack greg
16:21:17 <Zakim> Greg, you wanted to address testability
16:22:01 <jasonjgw> q+
16:22:17 <gowerm> Greg: Jason was still thinking that this required author to support inputs by a music keyboard device, if there was one. The author does not need to make every function avialable, but turning on the musical keyboard should not turn off keyboard input.
16:23:02 <gowerm> Jason: What I was talking about as the opposite. Is it desireable if I'm only taking music keyboard input to force the author to also allow that input via a mouse or keyboard.
16:24:00 <gowerm> Greg: I was explicity trying to take that concern into a separate discussion, which some were suggesting to delay until Silver
16:24:23 <Joshue108> q?
16:24:49 <gowerm> Greg: plugging in a musical keyboard input should not suddenly nullify existing inputs
16:25:53 <Joshue108> ack gower
16:25:53 <gowerm> Josh: we may be talking at cross purposes here, as it relates to web techjnologies
16:26:10 <Joshue108> s/techjnologies/technologies
16:26:45 <Greg> Joshue, I didn't get to the point I'd signed up on the queue for, which was testability :-)
16:28:03 <gowerm> Greg: Addressing concerns about testability: If one took normal testing procedures and interspersed another use of an input modality, that should not change the outcome of a test
16:28:17 <jasonjgw> q+
16:28:26 <Joshue108> zakim, close queue
16:28:26 <Zakim> ok, Joshue108, the speaker queue is closed
16:28:39 <gowerm> Greg: We can't anticipate every moment at which someone might switch devices, but that could serve as a basic test.
16:28:53 <gowerm> Kathy: I think we need to restrict to inputs currently supported
16:29:31 <Joshue108> ack jason
16:29:33 <gowerm> Josh: We will come back to this on Tuesday.
16:29:54 <Joshue108> rrsagent, draft minutes
16:29:54 <RRSAgent> I have made the request to generate http://www.w3.org/2017/06/22-ag-minutes.html Joshue108
16:30:13 <gowerm> Jason: I suspect this is not an example intended. There is an interest in having an application operate on a mobile phone and on desktop concurrently, and you can switch between devices
16:30:58 <gowerm> Jason: That requires some complex interaction coding, given different user agents on different machines. My assumption is that this proposal doesn't address that situation, but we need to be mindful of how it would be interpretted.
16:31:41 <gowerm> Josh: would be good to get one in, even if stripped down. Good point of discussion.
16:31:46 <Greg> We could add a Note to the SC clarifying that nothing in this SC requires adding support for additional input devices or modalities.
16:31:59 <Joshue108> trackbot, end meeting
16:31:59 <trackbot> Zakim, list attendees
16:31:59 <Zakim> As of this point the attendees have been jasonjgw, Kathy, shadi, Joshue108, Greg_Lowney, Rachael, MikeGower, KimDirks, steverep
16:32:07 <trackbot> RRSAgent, please draft minutes
16:32:07 <RRSAgent> I have made the request to generate http://www.w3.org/2017/06/22-ag-minutes.html trackbot
16:32:08 <trackbot> RRSAgent, bye
16:32:08 <RRSAgent> I see no action items