See also: IRC log
<Joshue108> https://www.w3.org/2002/09/wbs/35422/MATFSC_june/
<Joshue108> https://www.w3.org/2002/09/wbs/35422/MATFSC_june/
<Rachael> Scribe: Rachael
Zakim Takeup 1
Joshue: New accessible media
tutorial. Take a look at it. We've had good response.
... We are looking for a technical review, so anything wrong or
that could be improved please flag.
Shadi: Editors are still iterating and refining it. Try not to get distracted by that. Most important: Is thi sin line with WCAG?
Joshue: Please take a look at it if you haven't already.
Jason: Quickly read through it and it seems fine to it.
Joshue: We have a couple of new candidate success criteria to take a look at. We'll look at those now.
<Joshue108> https://www.w3.org/2002/09/wbs/35422/MATFSC_june/results
Kathy: Should I take them through that?
Joshue: Yes. We are dividing the rest of the call between both of them. 20-25 minutes for the first?
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.
This is simply saying the accessible name for the control needs to include the text string available to the visible label.
<Greg> /me Rachael, add topic header for this question into transcript?
<Zakim> Joshue, you wanted to ask about icons etc?
Joshue: How do icons relate to controls? What about visual affordances? Does that need to be included or is this only visible text?
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.
... Just hte icon alone doesn't fall into this.
<scribe> Scribe: Gowerm
<Joshue108> MG: Just to confirm you removed text about the position of the name etc?
<Joshue108> KW: Yes.
MikeGower: Does it contain any mention of position?
Kathy: No, that has been removed. It is now mentioned as a best practice
Jason: Possible exception is to
use terminology of user interface components
... 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.
<Joshue108> +1 to Kathy on AccName
Kathy: Could not find such cases. Accessible name is already defined for accessible name
<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
Jason: concerns with specifity of Accessible Name definition
<Kathy> https://www.w3.org/TR/accname-aam-1.1/#dfn-accessible-name
<Zakim> Greg, you wanted to ask about labeling as temporary content
Kathy: I pasted in the current definition.
<Greg> Should we address the use of transient labels, e.g. hover text or initial content of a text input field or list?
<Greg> It might be a bad idea when author uses inappropriate label, e.g. a whole sentence of instructions.
Greg: It will be for the user
when the author has picked a bad label for the visible
label.
... For instance a whole sentence.
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.
Shadi: But that is bad user experience for everyone
<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
Steve: I agree that putting the
label in front doesn't always apply. Checkboxes, radio buttons,
etc
... happy that Accessible name is now used as SC name.
Kathy: Agree the SC doc should call those out. Happy to have Steve's help with authoring it.
<Joshue108> MG: The definition of AccName doesn't account for ARIA concatenation etc
<Joshue108> MG: May they should consider this?
<steverep> Suggest adding a reference to the name calculation document
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.
Alex: Accessible name is available in .NET. Have you done the comparison that is Apples to Apples and used consistently across platforms?
Kathy: The accessible name we are referring to is the property in the accessible API. Those are the same in all
<Kathy> https://www.w3.org/TR/accname-aam-1.1/#dfn-accessible-name
Alex: And you've checked it against UIAutomation, etc?
Kathy: Yes there is a table (pasted in) that compares them all.
+1
<KimDirks> +1 YES
<Joshue108> +1
<Kathy> +1
<shadi> +1
<steverep> +1
<marcjohlic> +1
<Rachael> +1
<Alex> 0 this is my first look today
RESOLUTION: success criteria Accessible Name accepted for editors draft with minor editorial changes (i.e., removing the note)
Alex: the table only looks at 4 APIs
Michael: There are only 4 in
use
... I believe there is a fifth one, but we didn't have
information on it.
Kathy: There was concern in MATF
this was too broad, and we didn't have time to finalize
... We're looking to see if people have suggestions for how to
move this one forward, or general thoughts.
<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."
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.
<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."
<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
<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"
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
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.
Kathy: Agrees the larger
discussion can go in Silver
... I think the scope of 2.1.1 is too limited.
... We can't address 2.1.1 in the time we have
Josh: So what is problematic with Concurrent Input?
<Greg> Correction: we have only postponed changing 2.1.1 until later in the 2.1 process, not forbidden the changes.
Kathy: Greg's suggestions may
address.
... How are we going to test it, and is it testable under
2.1?
<Greg> I'll push for my proposed change to 2.1.1 (expanding the exception) later in the 2.1 process.
kathy: How do people feel about Greg's suggestion?
"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."
<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
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"
<Joshue108> MG: Am having problems parsing this, may be hard to test.
Alex: Similar concerns. How does this change in wording address testing issues?
Kathy: That is still the outstanding question
<Joshue108> -q
Alex: Even if it doesn't work, it may not be prolbem of content. It could be device. How do you ascribe failure?
<Zakim> Joshue, you wanted to ask how this relates to existing SC like Keyboard Accessible?
Kathy: It doesn't change keyboard access. All it says that when you switch modality, you aren't restricting input.
Josh: The developer needs to know what listeners to consider. How will this address this?
Kathy: That could be a technique
Jason: I'm trying to think of
some of the implications.
... 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?
music hardware.
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.
<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.
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.
<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.
Jason: Does that mean that a text field needs to support pointing input as well? I don'
don't want to have to write my own on-screen keyboard input for pointers
Kathy: If we had something about
supported inputs for specific controls that would cover.
... if we focus on not restricting, we get closer
<Zakim> Greg, you wanted to address testability
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.
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.
Greg: I was explicity trying to
take that concern into a separate discussion, which some were
suggesting to delay until Silver
... plugging in a musical keyboard input should not suddenly
nullify existing inputs
Josh: we may be talking at cross purposes here, as it relates to web technologies
<Greg> Joshue, I didn't get to the point I'd signed up on the queue for, which was testability :-)
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
... We can't anticipate every moment at which someone might
switch devices, but that could serve as a basic test.
Kathy: I think we need to restrict to inputs currently supported
Josh: We will come back to this on Tuesday.
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
... 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.
Josh: would be good to get one in, even if stripped down. Good point of discussion.
<Greg> We could add a Note to the SC clarifying that nothing in this SC requires adding support for additional input devices or modalities.
<Joshue108> trackbot, end meeting
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/chechboxes/checkboxes/ Succeeded: s/chagne/change/ Succeeded: s/techjnologies/technologies/ Default Present: jasonjgw, Kathy, shadi, Joshue108, Greg_Lowney, Rachael, MikeGower, KimDirks, steverep Present: jasonjgw Kathy shadi Joshue108 Greg_Lowney Rachael MikeGower KimDirks steverep Found Scribe: Rachael Inferring ScribeNick: Rachael Found Scribe: Gowerm Inferring ScribeNick: gowerm Scribes: Rachael, Gowerm ScribeNicks: Rachael, gowerm Found Date: 22 Jun 2017 Guessing minutes URL: http://www.w3.org/2017/06/22-ag-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]