<scribe> scribe: Glenda
<AWK> relates to https://github.com/w3c/wcag21/issues/840
<AWK> https://github.com/w3c/wcag21/pull/931/files?utf8=✓&diff=split
AWK: entire change is just an additional example.
<Chuck> +1
AWK: Question, does this work for you?
<laura> +1
Glenda = +1
<bruce_bailey> +1
<Brooks> +1
AWK: Anyone have an objection
<KimD> +1
RESOLUTION: Accepted as proposed
<AWK> https://github.com/w3c/wcag21/pull/903
<AWK> “The publication of WCAG 2.1 does not deprecate or supersede WCAG 2.0. While WCAG 2.0 remains a W3C Recommendation, the W3C advises the use of WCAG 2.1 to maximize future applicability of accessibility efforts. The W3C also advises that new or updated Web accessibility policies reference WCAG 2.1.”
<laura> +q
Laura: I agree we are advising the use of WCAG 2.1, but not mandating.
Kim: I’m off two minds. I see what you and others are saying. But I’m not comfortable with the word “policies”. I think that crosses a line.
<jon_avila> Agree with Laura. If we don't advise using it then why introduce a new standard? It is by nature called a recommendation.
<AWK> Text from WCAG 2.0: "WCAG 2.0 succeeds Web Content Accessibility Guidelines 1.0 [WCAG10], which was published as a W3C Recommendation May 1999. Although it is possible to conform either to WCAG 1.0 or to WCAG 2.0 (or both), the W3C recommends that new and updated content use WCAG 2.0. The W3C also recommends that Web accessibility policies reference WCAG 2.0."
AWK: we are not setting the policy, but we are putting forth a standard that is ready to be implemented in to policy. This is helpful to people who are trying to understand what to do with their policy going forward.
<jon_avila> WCAG 2.0 uses the word "Recommendation" rather than "advise" but still addresses policy.
<bruce_bailey> Good to see earlier (2.0) reference to "new and updated" content and mention of policy.
Brooks: Seems to me like there is
a difference. I totally get the point of advocating use of this
standard. But to Kim’s point, policy has to take in a lot of
factors that this group is not aware of.
... I think we are reaching to far if we advocate for changes
in policy.
gowerm: Do we just want to go with the language used in WCAG 2.0?
<bruce_bailey> I think that precident means that this less controversial.
Judy: My first reaction is reusing what we did in WCAG 2.0 won’t make sense. Because 2.0 replaced 1.0.
<Detlev> sorry to be late! Do you want me to take over scribing?
<laura> Judy’s email: https://lists.w3.org/Archives/Public/w3c-wai-gl/2018AprJun/0537.html
Judy: I’m hoping that Kim and
Brooks saw my comments to the list. Offering some context, as
to why this phrasing is in the standard to provide guidance.
The Working Group does not deal a lot with policy. But the W3C
staff is often called on to answer how the guidelines can work
as technical solutions in the context of a policy.
... W3C sees this as an improvement on WCAG 2.0. We are not
mandating a change to WCAG 2.1. But is very normal for us to
encourage the update of our new standard. One of the main
uptake drivers is policy in business and goverment
settings.
<Zakim> bruce_bailey, you wanted to comment about 2.0 being a big change from 1.0
<jon_avila> Not putting the statement in would cause confusion and people would use it against upgrading to WCAG 2.1
Judy: If this reference to advising the uptake of WCAG 2.1 be consider for future policy is not included, it will raise the burden on W3C staff for answering this common question that gov and business have about what to do with WCAG 2.1.
Bruce: fine with the use of policy advice. We have a precedent.
AWK: To Brooks and Kim, Are there reasons that an org or gov should not adopt WCAG 2.1?
Brooks: We must consider the impact of advising future policy be updated to WCAG 2.1. Concerned about the burden.
<AWK> Current proposed version: The W3C also advises that new or updated Web accessibility policies reference WCAG 2.1.
Judy: That is an interesting
misunderstanding fo the suggested language. The intention is
not to say, “please update your policy”. Instead, it is
actually communicating, “If you are updating your policy,
consider moving to WCAG 2.1” We are very aware of the impact of
updating a policy. That is now what this proposed language
says.
... We know that updating policy is extraordinarily complex. So
many layers and dependencies. What do you think of the language
“advising considering”. Policy update is a significant engine
for getting accessibility in place.
<AWK> The W3C also advises that when developing or updating Web accessibility policies to use the most current version of WCAG.
Brooks: good points Judy. I’m not a lawyer, but I work with one. I let my colleague speak to that.
Judy: you are less concerned with language that “advises considering”?
Brooks: yes, as a non-lawyer. I’m more comfortable. But I defer to Kim.
AWK suggests “The W3C also advises that when developing or updating Web accessibility policies to use the most current version of WCAG.”
<laura> +1 to awk’s text
Kim: I think that is better, Andrew.
Judy: I’m interested in your language Andrew. It is very consistent with what the W3C says. And additionally, it is evergreen. We can safely and normally repeat. Especially if we continue to do more dot releases.
<Zakim> Judy, you wanted to comment on Andrew's suggestion of "most current"
<AWK> Kim suggests: The W3C also advises that new or updated Web accessibility policies reference WCAG 2.1 <<++where it does not cause undue burden
<AWK> or:
<AWK> The W3C also advises that new or updated Web accessibility policies reference WCAG 2.1 <<++to the maximum extent practicable++>>.
Kim: I suggested language to mitigate the concern that someone may take this as an implication that we want you to update your policy to WCAG 2.1. Adding something like, “where it does not cause undue burden.”
Judy: speaking on behalf of W3C, "undue burden" sounds like a “P”olicy statement. It also sounds like US legislation. This is an international standard. The "undue burden" ties too closely to US policies..
<Brooks> How about "The W3C also advises that when developing or updating Web accessibility policies to consider using the most current version of WCAG."
Judy: “to maximum extend
practible” sounds lawyerly and is out of place in a technical
standard. We are providing this advice to help people who will
have these questions for their org.
... can we use “encouraging consideration”? Can we take a straw
poll?
<Zakim> gowerm, you wanted to say I would have real concern with putting in an undue burden phrase
<Jon_avila_> I do not agree with Kim’s proposal.to addi mitigating language to the end.
gowerm: I agree with the problem with the “undue burden” phrase.
Chuck: I’m not a lawyer. This is simply a recommendation to try to. But when we add the lawyerly language, it actually feels more like a requirement. It gets so much more serious.
<KimD> "The W3C encourages entities who are developing or updating web a11y policies to incorporate..."
AWK: any group that is charged with developing a policy, clearly gives them the right to make their policy fit their organization’s needs.
<AWK> "The W3C also advises that when developing or updating Web accessibility policies to use the most current version of WCAG"
Kim: I don’t disagree with Chuck. I think it is heavy handed. And I don’t love it. But when I was trying to reword it. That is what I could come up with. I like the language that AWK is proposing.
AWK: Can we live this this version?
Kim: can we replace “advises” with “encourages”
<AWK> "The W3C also encourages use of the most current version of WCAG when developing or updating Web accessibility policies."
Judy: I see Kim’s point. We are just trying to indicate, “look, we’ve got a new one.” I think “encourages” will accomplish the signal we are trying to send.
<bruce_bailey> +1
<gowerm> +1
<laura> +1
Glenda +1 love it
<Chuck> ++++++1
<KimD> +1
<Brooks> +1
<Judy> +1
<MarcMobile> +1
Judy: I thought there were favorable responses to remove “new and updated” in front of content.
<AWK> "The publication of WCAG 2.1 does not deprecate or supersede WCAG 2.0. While WCAG 2.0 remains a W3C Recommendation, the W3C advises the use of WCAG 2.1 to maximize future applicability of accessibility efforts. The W3C also encourages use of the most current version of WCAG when developing or updating Web accessibility policies."
<KimD> +1
<bruce_bailey> +1
<Chuck> still +++++++1
<Brooks> +1
<gowerm> +1
Glenda: +1
<MarcMobile> +1
<laura> +1
AWK: any objections to incorporating this into the editors draft?
<Detlev> no objections
RESOLUTION: accept edited version posted at by AWK at 11:45am central time
<AWK> Issues 914, 913, 901, 933
AWK: seems to be the one SC that we have the most issues with. Issues 914, 913, 901 and 933. We also have a comment from Funka on the public email list.
<AWK> https://github.com/w3c/wcag21/issues/901
AWK: We did get through our AC vote. But the two concerns were about target size being at AAA, and some concerns about 1.4.11. So we should make sure this is clear.
<AWK> https://github.com/w3c/wcag21/issues/913
AWK: 901 is simple, lets go to
913.
... is contrast on hover included or not.
gowerm: the hover state provides a redundant visual indicator, because the pointer indicator changes shape.
<Zakim> bruce_bailey, you wanted to ask if new and updated still in previous sentence
<gowerm> It's true. Submit inputs do not change shape cursor shape on hover!
AWK: hover contrast - are we saying sufficient contrast against the background?
Jon: I was talking about the background.
<AWK> For reference: https://www.w3.org/TR/WCAG21/#non-text-contrast
Detlev: The pointer is quite different than the needs of a keyboard only user. A person using the mouse, the user is actively moving the mouse pointer to the spot (or actively moving their finger to the spot). Where as a keyboard only user has a higher need to understand the focus.
gower: this became an question
when we linked to definition of “states” because that mentions
“hover”.
... input submit button does not change shape on hover
... input submit button does not change pointer shape on
hover
... so this would be exempt because it is a user agent default
(we can solve later at the browser level)
Glenda: could we just add something to the understanding document about the pointer shape change be sufficient?
gower: it would be great if 1.4.11 didn’t include hover.
jon: I’m more worried about seeing something when my mouse pointer is hovering. I don’t want to derail this.
AWK: I don’t think anyone would say that the hover state switches it to an incredible low contrast. We don’t want to encourage that.
<Zakim> Brooks, you wanted to say that hover contrast with the background shouldn't matter if there is a visual focus indicator that has 3.0:1 contrast with the background on hover.
Brooks: can we say that hover contrast with the background shouldn't matter if there is a visual focus indicator that has 3.0:1 contrast with the background on hover.
<Detlev> I'm not sutre I get what your point was..
<Detlev> s/sutre sure
AWK: Here is what we need to
figure out. We need to get the understanding documents
finalized. This quesiton is the main question that needs to be
resolved.
... Can I ask that people pay attention and engage on the list?
Anyone willing to take this on?
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/for future policy/for future policy is not included/ Succeeded: s/every green/evergreen/ Succeeded: s/it sounds like/"undue burden" sounds like/ Succeeded: s/This ties to closely to US/The "undue burden" ties too closely to US policies./ WARNING: Bad s/// command: s/sutre sure Present: AWK Chuck Brooks KimD Glenda Laura gowerm jon_avila Detlev kirkwood bruce_bailey Found Scribe: Glenda Inferring ScribeNick: Glenda Found Date: 24 May 2018 People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]