See also: IRC log
<AWK_> hakim who is on the phone?
<AWK_> zakim who is on the phone?
<AWK_> +AWK
<AWK_> agedna?
<scribe> Scribenick: brooks
<Joshue108> https://github.com/w3c/wcag21/pull/377
<Joshue108> https://github.com/w3c/wcag21/issues/371
Josh: We have a few items to go over today, such as a pull request for accessible names. Accessible names terminology are not synced between 2.1 and 2.0. There are a couple of suggested changes.
MichaelC: One question about removing a note about removing a best practice. It should be removed from this pull request. It blocks processing the changes this issue is focused on.
Steve: No problem with Michael's suggestion. We need a cohesive document that uses the same language.
MichaelC: I agree with Steve. But, it should be considered separately. It should be put back in as it is now, then in a future edit process proposed change.
Steve: It should say "Make sure that whatever the text of the label is, should be at the beginning of the accessible name."
Josh: We may have to pick out some of these things and submit them as individual issues.
Steve: Not sure how to individualize the issues.
MichaelC: Support all that Steve mentioned, except the note regarding labels with accessible name.
Steve: If I add it back in to include with the same language, would that be OK?
MichaelC: Put it back in with original text, and submit a separate pull request.
AWK: Take back active UI controls comment. I like the idea of using "Name," because that's whats in 4.1.2.
<lisa> (I love that aim - consistent confusion :)
AWK: warming up to the new title of the relevant SC. "Label in name" may be a good approach.
Steve: Want to put label in name as the suggestion.
Detlev: Was there a survey on this?
<Joshue108> https://www.w3.org/2002/09/wbs/35422/Issues_Sept28th_call/
<Detlev_> https://www.w3.org/2002/09/wbs/66524/20170920_survey/
Josh: Are you talking about a previous survey?
<Joshue108> https://www.w3.org/2002/09/wbs/66524/20170920_survey/results#xq3
<Ryladog_> +1 to suggext changing the name of the SC Accessible Name to something that will not confuse it with accessible name in AAPIs
Josh: I can't recall the details of the survey you referenced by URL. What date was this?
AWK: I think this survey is old.
Detlev: It was linked to the MATF email.
JF: Current definition of name is already defined. Name just needs to be exposed to assistive technology. Let's be consistent and crosslink current definition to create a learning opportunity.
Josh: Are there bits of it you don't like?
JF: At the end of the day, I'll move for consensus - but, it seems like we should just call it what it is.
<JF> https://www.w3.org/TR/WCAG21/#dfn-name
AWK: Does the definition of "name" in WCAG 2.0 match what we've use in the APIs?
JF: Yes, what's currently defined matches what is in APIs.
AWK: In many cases, the name and
the label are the same. At times, there's more text available
in the name versus the visual label. We seek parity between
label and name.
... What Steve is saying is let's have one definition of name.
Let's get rid of the new definition and stick with the old
one.
Katie: We need further clarification.
Josh: In 2.1 it is important to sync up on its own, syncing up with 2.0 is another thing.
<steverep> Would it help if we took some of the "accessible name" definition and put it in as a note in "name"?
<Joshue108> +1 to AWK
David: Steve's point is good one. Consistency is what we need. There should be parity. My preference is to update the word "name" to "accessible name" througout 2.1 - make a note that it corresponds to "name" in 2.0
<JF> either that, or improve the definition of "name" in WCAG, to directly connect it to the accessible name concept
<AWK_> -1 to the suggestion to change "name" to "accessible name". Slippery slope on changing existing SC when we don't need to.
Katie: I agree with David and
point out in this
... we should change "name" to "accessible name" throughout
2.1, and identify that we mean that in relationship to
accessibility APIs
<Joshue108> awk
<Zakim> AWK_, you wanted to say that people understand that "name" in WCAG 2.0 = "accessible name" in accessibility APIs. The thing that would make that confusing is if we offer a separate
<JF> suggestion: NAME (aka Accessible Name)
AWK: We have made it clear that this is not the same as the HTML name attribute. I don't agree that we should change the text of the current SC. It's a slippery slope for changing more SCs.
Katie: We should make it clear the differences in the meaning of the name attribute from what we mean by accessible name.
Gower: I think we are going to run into hot water if we try to change the meaning of name across the board.
<david2> +1
<Joshue108> +1 to that
<Joshue108> I'd rather see the definition made made more explicit also
JF: We have two terms that have nearly identical definitions. Let's remove that redundancy. Let's expand on the definition of the term "Name" by saying it maps the accessible name in accessibility APIs. Let's remove one definition and move to an expanded definition.
<Zakim> MichaelC, you wanted to -1 for redefining WCAG 2.0 name
MichaelC: I would want to see a proposal on. I'm not sure that's the solution.
<AWK_> Could be clarified in Understanding very easily
JF: Just looking to better clarify what we have in place.
MichaelC: Would not want to see "name" changed across the board to "accessible name."
<JF> +1 to STeve's idea (errata)
<Zakim> steverep, you wanted to say then it should be errata on 2.0 and a separate issue
Steve: I will be happy to just add back in the note, and bring this up as a separate issue. I don't want to change the definition of name as part of this issue.
<Zakim> AWK_, you wanted to say that name to accessible name is not an errata.
<Zakim> Joshue, you wanted to say the definition addendum to clarify name == accessible name would be good
<steverep> I meant the note, not changing the term
AWK: We could also address this
clarification in Understanding. Errata are for the things we
made a mistake - calling it "name" in WCAG 2.0 was not a
mistake. Errata isn't appropriate for this clarification.
... I agree that we need one definition, and it should be
"name"
Josh: I agree with that.
<Ryladog_> +1 to Josh add clarification
Josh: Steve, do you have something you can work with to come back with the group?
Steve: If you want that stuff in there, we could add it as a note to the existing definition of "name" - could be confusion between what's in 2.0 and 2.1
AWK: we should be able to accept the update as accepted as amended
Josh: Is there any objections to the pull request, with regard to opinions on the call?
<steverep> Amended means to me adding back in a translated version of the note, and nothing else.
Katie: I can accept this if there is a connection between our use of name and accessible name as definied in accessible APIs
<AWK_> amendments are: re-adding note in accessible-name.html
AWK: Someone will have to come up with a proposal
Josh: Any objections to Steve's pull request as amended.
RESOLUTION: Accepted as amended
Josh: I don't think that clarifying name will hurt anything
Josh: This next item is from
Steve and relates to word "essential"
... do you want to frame up the suggested pull request, then
we'll go through your comments.
Steve: There are two pull requests, trying to get "essential" back to the way it was in 2.0, the other is correcting incorrect uses of the word "essential" in 2.1
<Joshue108> Apologies that these got conflated - my bad..
<Detlev_> Can someone put in a link to the pull request?
Steve: The first pull request has to do with the change in the definition of "essential" when we added Orientation into. This pull request removes the definition from SC and adds it as a note.
<lisa> fry next week i will miss both calls
<Joshue108> https://github.com/w3c/wcag21/pull/393
<laura> https://github.com/w3c/wcag21/pull/393/files?diff=split
Josh: Thumbs up to the first part of this. Any objections to accepting this pull request?
<Detlev_> +1 to PR
RESOLUTION: Accepted #393
<laura> “Examples wwhere”
AWK: Steve, change "where" so that is spelled with one "w" - In orientation.html
<lisa> I am a but confuced here
Josh: Andrew, your comment is related to 3.3.3? Right?
MichaelC: Yes
AWK: Pull request 398 is the one my comments are based on.
<lisa> the link to 393 is opening an irc channel for me
<lisa> so i have no idea what we are talking about
Josh: Can we take up number 6 now?
Josh: Steve, was this one you again?
Steve: Yes
<lisa> does this issue affect the coga scs?
<Joshue108> https://github.com/w3c/wcag21/pull/398
AWK: There are few of these where we need something else in the language. We need to consider each instance where we want to remove "essential" and thoughtfully replace the word with an appropriate or phrase.
<Glenda> We have a problem with the way “essential” is defined in WCAG 2.0. It only applies to things that CANNOT CONFORM.
<Glenda> essential
<Glenda> if removed, would fundamentally change the information or functionality of the content, and information and functionality cannot be achieved in another way that would conform
AWK: Like with graphics contrast,
if there are a large number of colored buttons, you don't have
the ability to provide adequate contrast between all of the
choices. This is an instance where we need to choose the right
language to replace essential.
... The privacy interest group wants to visit with one of the
chairs, and that's going to be Josh. So I will be taking over
now.
<Glenda> So…I’m willing to replace “essential” with “necessary”
Lisa: I'm confused on where the last topic was effecting the COGA Success Criteria.
AWK: We haven't talked about this item yet. No conclusion on this yet.
Glenda: I got what Steve was
trying to convey what he meant about clearing up the way we use
"essential." We can only use "essential" for exceptions, based
on the way we have defined "essential."
... I just replaced the word "essential" with "necessary."
AWK: The current pull request suggestion is to make the language read "required steps" in the authentication process.
<Zakim> steverep, you wanted to ask if those concerns regarding Adapting Text are nullified by the current wording
Glenda: The definition of "essential" in 2.0 makes it so we can use it in a negative way, not positive. When we need to use "essential" in a positive way, we need to use a synonym for "essential."
<laura> I'm okay with removing essential modifier in the adapting text SC. What kind of text would not be considered essential? Are ads the only example?
Steve: I tried to do what Glenda
has suggested. I tried to replace postive uses of "essential"
with synonyms.
... I wonder if previous concerns are now moot?
AWK: If use absolute language, we may not yield the best result. Agree that "essential" may not be the right word, but we need to figure out what the right word is.
Steve: It feels like this another issue separate.
<Glenda> agreed. We don’t always drop the word essential. Pardon the pun, but if “essential” is essential…we replace the positive use of the word “essential” with “necessary” or “required”.
AWK: I wouldn't want to take up removal of text as a separate issue.
Jason: I am concerned about these
concepts of things like "essential" and "required."
... In relation to adapting text, I would remove
qualifications, unless there are clear examples that are
meaningful. Good concrete case are needed, then we use those to
try to general language we can use.
<laura> +1 to Jason.
Jason: If we aren't careful, we may wind up with unintended interpretations.
<Ryladog_> +1 to AWK
AWK: From my part, I need more than an hour to come up with specific examples. If this goes through a CfC, process that's OK. If it is going through a comment, I'm not OK with that.
<Zakim> steverep, you wanted to say how subjective it is really depends on the SC
Steve: Let's take a look at each SC and determine the context to figure out the appropriate language.
<Glenda> crazy idea - could we use the WCAG 2.0 “essential” definition as “essential” when used in an exception. And add a clause for when “essential” is used as a positive requirement.
Alex: If the function is already there, and you can't achieve it any other way, it is essential.
Jason: Greg V.'s point was unless the criteria for determining essentiality is carefully define, and the use of it is constrained, then you can open up interpretation of the standard to problems.
<JF> +1 to needing clear definitions: critical for testability
Jason: It depends upon the use of the term "essential" in the context in which it used.
Alex: It depends on the use case.
<AndyHeath> +1 for Jason’s point
Jason: "Essential" depends on
what you interpret the purpose of the content is. If you open
up those kinds of judgments on the part of standards users, it
will create problems.
... Steve's right when he asked us to consider each use of
"essential" on a case-by-case basis. We need reliablly testable
grounds.
<Detlev_> I think we are moving in circles - is anyone disputing Steve's point?
Alex: In which success criteria would removing "essential" have an impact?
AWK: What we should do is to give people some more time to look at these instances of "essential" and discuss individually.
<steverep> No, because I need to go :)
<JF> +1 to resuming this discussion on our next call
AWK: Do we want to spend more time on this now, or should we ask people to consider this carefully later?
Alex: If you find any disagreeable use of essential exceptions, let's talk about it.
AWK: Let's leave this one open, and we'll pick up back again when people have had more time to review.
Gowerm: Let's break it into different items for each instance where we consider the word "essential"
RESOLUTION: Leave open
Lisa: Is the issue you wanted to be on the call for was the use of the word "easily?"
Lisa: The word easily was
objected to, but the phrase "easily available" was actually
used. It is linked to a definition. There should not be a
problem with this.
... If you take out the word "easily," you are probably not
helping people with cognitive disabilities.
<laura> easily available definition: https://www.w3.org/TR/2017/WD-WCAG21-20170912/#dfn-easily-available
<AWK_> Based on https://www.w3.org/TR/WCAG21/#interruptions-minimum
Lisa: We can tweak the definition, but taking out the word "easily" has a huge negative impact.
<MichaelC> https://github.com/w3c/wcag21/issues/373
<MichaelC> https://github.com/w3c/wcag21/issues/375
<Glenda> +1 I agree. The word “easily” is not objective.
MichaelC: I filed two issues related to this. There was an instance where we found a mechanism was "easily available". Found no difference in meaning when we remove "easily". Need to clean up definition.
<lisa> agreed - the definition needs cleen up
Detlev: I could not easily understand the definition - to be honest, it's not clear. I don't think the current definition works as something that's understandable. It needs to be very simple and clear
Jason: I commented on the mailing. I'm not going to repeat those details, but basically I agree with what Detlev is saying. There are problems with the definition we have.
<lisa> +1 t editing the definiton to meet these concerns
Jason: Given the way that it is
worded, it is not reliably testable.
... one option is to change the definition. The other option is
to drop both the term and the definition. Let's solve it in a
different way, such as to provide meta data or some other
mechanism that users can employ to get to controls
quickly/easily.
<KimD> *For me, "easily" is a problem because it's a such a commonly used word already, with its own meaning already.
<laura> Maybe change the term?
Alex: I have serious problems with the definition of "easily available". The term "easily" brings into a play a higher degree of subjectivity than we can accept. We should change the term to make it more concrete.
Lisa: We all agree that we should
tidy up and change the definition. There's another option: Put
language in the SC to help define the specific context of
"easily" for each SC.
... We can include globally available as a definition, or
handle it in the Understanding text.
<JF> perhaps use the term "readily" instead? and then as Lisa suggests define that more explicitly?
Detlev: Question to Lisa: What do you think if we dropped "easily."
Lisa: It is difficult to go into
application-specific settings to change preferences. It is hard
to manage. It makes the "availability" actually useless.
... Direct link from the current application to turn off
notifications would work.
<gowerm> Use Examples and Intent in the Understandings doc
<Detlev_> +1 to Michael
MichaelC: I prefer to keep "mechanism is available" and drop "easily". Tacking on clarification to provide further definition of "easily" is OK.
<gowerm> +1 remove "easily"
RESOLUTION: leave open
AWK: If we want to have an alternative way, then someone's going to need to do that. Any volunteers to implement this in a different way on a different branch, that would be helpful.
<laura> Bye.
<lisa> mihael do you want to work on a draft with me?
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) Default Present: AWK, brooks, Detlev_, Roy, Joshue, KimD, Glenda, Melanie_Philipp, Greg_Lowney, steverep, JF, David-MacDonald, Laura, MichaelC, lisa, Pietro, AndyHeath, Katie_Haritos-Shea, jasonjgw, MikeGower, kirkwood WARNING: Replacing previous Present list. (Old list: (no, one), brooks, Detlev_, Roy, Joshue108, KimD, Glenda, Melanie_Philipp, Greg_Lowney, steverep, JF, David-MacDonald) Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ AWK, brooks, Detlev_, Roy, Joshue, KimD, Glenda, Melanie_Philipp, Greg_Lowney, steverep, JF, David-MacDonald Present: AWK brooks Detlev_ Roy Joshue KimD Glenda Melanie_Philipp Greg_Lowney steverep JF David-MacDonald Laura MichaelC lisa Pietro AndyHeath Katie_Haritos-Shea jasonjgw MikeGower kirkwood Found ScribeNick: brooks Inferring Scribes: brooks Found Date: 28 Sep 2017 Guessing minutes URL: http://www.w3.org/2017/09/28-ag-minutes.html People with action items:[End of scribe.perl diagnostic output]