– DRAFT –
AGWG-2022-01-04

Chuck: Any introductions?

(None)
… Any new topics?

(None)

WCAG 3 Issues - Survey https://www.w3.org/2002/09/wbs/35422/wcag3/

<Chuck> https://www.w3.org/2002/09/wbs/35422/wcag3/results

<AWK> +AWK

Chuck: number of responses not on topic.
… want to stay on topic.
… file a GH comment.

AC: comments around prematurity and direction.
… these will all be marked as exploratory.
… yes, we are trying to work though the comments.

Question 1 - 256 - Clear Words vs Plain Language

AC: Should be straight forward.

<Rachael> https://rawgit.com/w3c/silver/status-indicators-new/guidelines/index.html

Rm: week after next we will be talking about exploratory.
… will make it clear to the public.

<Zakim> bruce_bailey, you wanted to ask q from last week

Jf: all of survey questions are in posed as approval. Need a disagree option.

Chuck: may have lost previous minutes.

chuck: 256 - Clear Words vs Plain Language

<LisaSeemanKest> can I have the link

chuck: gregrgay requested we change the guideline title from "clear words" to "plain language." The subgroup responded that there was the potential for confusion based on already existing standards by that name

<bruce_bailey> minutes from last meeting are not correctly formated

<bruce_bailey> https://lists.w3.org/Archives/Public/w3c-wai-gl/2021OctDec/0172.html

<bruce_bailey> https://www.w3.org/2021/12/21-ag-minutes.html

chuck: proposed response: This was originally considered, but the decision was made that Plain Language is comprised of a comprehensive set of writing requirements that would be too large to include in one guideline. We were also concerned about causing confusion where there are laws and regulations that refer to plain language. For example in the United States, there's the Plain Language Writing Act of 2010 and plainlanguage.gov serves as a resource for[CUT]
… 5 Agree with the response
… 3 Agree with some adjustments

<bruce_bailey> @alastairc -- zakim did not see me as scribe -- so what i typed is not formatted as would be expected

Ac: Given the usage of the term "plain language" in other parts of the guideline documentation, it would help if the "Get started" page had a line about the difference and what is meant by it in relation to Clear words.
… I suggest updating the response to say that will be included.

Chuck: bruce wanted active voice.

JF: it is premature to be having this conversation.

Chuck: Laura said "t seems premature to begin processing outside comments on the content of WCAG 3 that the AG working group itself hasn't reviewed and commented on yet. "

awk: Agree with other comments that this seems premature - I'll agree that we can change the name now but only if we also agree not to use this change as a reason that it can't be changed again after further work on the guideline.

Lisa: agree that it is premature.
… in COGA we use easy to understand language.
… will run into conflict in different jurisdictions.
… don't want to use either Clear Words vs Plain Language.

Chuck: anything we decide here can be changed. Not set in stone.

<AWK> Great, thanks Chuck.

ac: we have an agreed first public working draft.
… plain language may not be a good name.
… it is a work in progress.

<Zakim> alastairc, you wanted to talk about dealing with issues

<Lauriat> +1 to Alastair

ac: want to close issues.

<Zakim> jeanne, you wanted to say that we have been requested to close issues. We are attempting to close simple issues.

<JF> -1 to Alastair

<LisaSeemanKest> Easy to Understand Language

<LisaSeemanKest> Sometimes called: “easy reading”, “easy to read”, “plain language”, “easy to understand”.

<LisaSeemanKest> Easy to Understand Language refers to text content that is in an accessible, easy to understand, form. It is often useful for people with learning disabilities, and is easier for many other people as well.

rm: not committing to plain language
… want to close issues.

<alastairc> And that it is unlikely it would be called 'plain language'.

Jf: maybe respond that this is being reviewed.

Js: then we can't close it.

rm: don't to be unresponsive to issues.

<LisaSeemanKest> +1 to rachael

<kirkwood> +1 to Rachael

<JF> +1 to AWK

<Jaunita_George> +1 to Rachael

<Lauriat> +1 to AWK & Rachael

Awk: thank them for feedback. Record in another place. And then close.

<JF> +1 to AWK, but record where?

Awk: thank you for feedback. We will record your comment and revisit it. And then close the issue.
… can use a wiki page or google doc.

<alastairc> Err, the github issue? Closed is not deleted

Mc: link to the place where it is recorded.

<alastairc> "The working group is planning further review of this guideline and expects that it will be revisiting the name as party of that process. We will recorded your comment so it is taken into consideration when the guideline is refined."

<alastairc> github label?

rm: concerned about maintenance and transparency.

<kirkwood> +1 to Rachael

<Chuck> who just tried to q plus?

Lisa: we have had this conversation before.

<Chuck> verbally?

<bruce_bailey> +1 to Rachael and plan to close rather than try to figure out how to revisit

Lisa: add a cross reference to previous coga conversation.

<janina> +1 that documenting where this has been discussed could be helpful

Lisa: then close it.

Ac: label it input for refinement.

<LisaSeemanKest> +1 good idea

Ac: subgroup would have it for future reference.

Jf: GH may not be the answer. larger problem. Could have a links to COGA.

Mc: shouldn't be a usual practice.

Lisa: would add a comment on GH issue and link to COGA repository.
… Then close it.

<Rachael> https://www.irccloud.com/pastebin/PpIQEnmF/

Rm: Draft comment: "Thank you for your comment. We originally considered using Plain Language, but decided that that Plain Language is comprised of a comprehensive set of writing requirements that would be too large to include in one guideline. We were also concerned about causing confusion where there are laws and regulations that refer to plain language. The working group is planning further review of this guideline and we will revisit the name as pa[CUT]

<kirkwood> +1 to Rachael

<Chuck> +1

<AWK> +1 to that - we are going to need a reproducible way to do this sort of thing MANY times in the next few years

<Chuck> proposed RESOLUTION: Accept the amended response to address issue 256

<kirkwood> +1

<Rachael> If we are comfortable with this approach we can start using it for these situations

<alastairc> draft: "Thank you for your comment. We originally considered using Plain Language, but decided that that Plain Language is comprised of a comprehensive set of writing requirements that would be too large to include in one guideline. We were also concerned about causing confusion where there are laws and regulations that refer to plain language.

<alastairc> The working group is planning further review of this guideline and we will revisit the name as part of that process. We are closing this issue but are adding a label input-for-refinement to ensure the group considers your point as we move forward."

<AWK> +1

<LisaSeemanKest> +1

<Chuck> +1

<kirkwood> +1

<bruce_bailey> +1

<alastairc> +1

<ToddL> +1

<Detlev> +1

<JF> 0

<Jennie> +1

<janina> +1

Laura: +1

<Ryladog> +1

<Raf> +1

<Rachael> +1

<Francis_Storr> +1

<Jaunita_George> +1

<janina> Intolerable!

<Ryladog> * says it is tolerable

RESOLUTION: Accept the amended response to address issue 256

Question 2 - 359 - Measuring words question

Chuck: In issue 359, paulairy asks "Is it feasible to test using a readability feature, like the one included with Grammarly?"
… The Clear Words subgroup agrees with John Rochford. The current state of readability tools are not supported by current research. There are new tools being developed that the group is looking into and hope to include in a future draft. We are not opposed to readability tools per se, but current tools, such as Flesch-Kincaid are not designed to meet the needs we’re targeting.
… 7 Agree with the response

RM: I would add a link to John Rochford's comment in github to help it be clear what this response is referring to or remove the second sentence.

Ac: This guideline is still in early development, how it is going to be tested is not yet agreed. In general the Clear Words subgroup agrees with John Rochford. The current state of readability tools @@may not be sufficient. There are new tools being developed that the group is looking into and hope to include in a future draft. We are not opposed to readability tools per-se, but current tools, such as Flesch-Kincaid are not designed to meet the needs [CUT]

mg: I think it is feasible to test with tools.

<LisaSeemanKest> +1 to mike

Jf: what is it they are trying to do?
… need to know what to goal is.
… goes back to being premature.

<JF> +1 to Janina

js: feasible- yes. But not a clear path to tooling.

Lisa: what we are working on in sub group has tools or techniques.
… tools are available. database is available. Needs to put them together.

Jf: in guideline it has 3 methods.
… can handoff first to tooling.
… feels premature.

<alastairc> draft: "Thank you for your comment. This guideline is still in early development, how it is going to be tested is not yet agreed. In general the Clear Words subgroup [agrees with John Rochford.](https://github.com/w3c/silver/issues/359#issuecomment-825205091) The current state of readability tools @@may not be sufficient. There are new tools being developed that the group is looking into and hope to include in a future draft. We are not

<alastairc> opposed to readability tools, but current tools such as Flesch-Kincaid are not designed to meet the needs we’re targeting."

Chuck: focus on ac's language.

<JF> Q: what are "the needs we’re targeting"?

jf: what are "the needs we’re targeting"?

<jeanne> jeanne: Suggests that JF read the HowTo for the user needs analysis.

Rm: that question is secondary.

<LisaSeemanKest> readability tools do not typicaly adress it, understandability tools do

Rm: just trying to close small issues.

<alastairc> from the how-to, it is "to improve the experience of individuals with cognitive and learning disabilities"

<LisaSeemanKest> dont use the words "current tools" and I am ok

Jf: no evidence that tooling is there.

rm: question for next week.
… we have to trust the subgroups.
… can't function otherwise.
… there is a tension there.

<tink> +1 to Rachel

<kirkwood> +1 to Rachel

<jeanne> +1 to Rachael

<alastairc> Adjust to this? "We are not opposed to using tools, but tools such as Flesch-Kincaid are not designed to meet the needs we’re targeting."

Lisa: if we say readability tools are not sufficient. But we are looking at others.

<LisaSeemanKest> perfect

<alastairc> https://github.com/w3c/silver/issues/359#issuecomment-1004990301

<alastairc> Thank you for your comment. This guideline is still in early development, how it is going to be tested is not yet agreed. In general the Clear Words subgroup agrees with John Rochford. The current state of readability tools may not be sufficient. There are new tools being developed that the group is looking into and hope to include in a future draft. We are not opposed to using tools, but tools such as Flesch-Kincaid are not designed to meet

<alastairc> the needs we’re targeting.

<LisaSeemanKest> +1

<Chuck> proposed RESOLUTION: Accept the amended response to address issue 359

<LisaSeemanKest> +1

<jeanne> +1

<JF> -1

<Rachael> +1

<Ryladog> +1

<ShawnT> +1

<kirkwood> +1

<Jaunita_George> +1

<Jennie> +1

<Detlev> +1

<JakeAbma> 0

<tink> +1

<ToddL> +1

Jf: objecting because we don't know the needs of the audience.

<Raf> +1

<Ryladog> Understandability for people with cognitive disability

Jf: need clear definition of the needs.

<Jennie> All the identified needs?

<janina> +1

Lw: we have a subgroup that has recommened this. Accept the recommendation, JF.

chuck: the -1 will not hold up the resolution.

<jeanne> User Needs Analysis on Clear and Understandable Content

Lw: if you don't understand, how can you push back?

<kirkwood> +1 to Leonie

jf: can any one define what the needs are?

<Ryladog> Understandability for people with cognitive disability

Js: it is at: https://docs.google.com/document/d/1PiU58yc0mLEwRL-bos_03h5Zql7PNCpi9o43bNUa6gE/edit#heading=h.n4dn1ix27i11

jf: I have read that.

<LisaSeemanKest> LOL we have been working on it all year

RESOLUTION: Accept the amended response to address issue 359

<Jaunita_George> +1

Question 3 - 380 - Question on Clear Words

Chuck: melaniephillip asks "Will a tool like dictionary lookup provided at the OS or browser level be a sufficient technique for Method: Use Clear Words?".

<bruce_bailey> https://www.w3.org/2002/09/wbs/35422/wcag3/results#xq4

Chuck: proposed response: The group discussed this and we do not think a browser lookup function is sufficient to meet user needs. First, these tools are available today and they do not solve the overall issue of the necessity of writing with clear words.

<JF> https://www.w3.org/WAI/GL/WCAG3/2021/how-tos/clear-words/#develop-button

Chuck: If we were to say that using browser lookup functions was a sufficient technique, there would be no incentive for authors to provide clear language. The lookup function definition often does not provide the correct context for the content.
… Also, the number of steps required to use a browser lookup function can be too complex for people who need to look up multiple words. The fatigue factor for people with certain types of disabilities can be too great.
… 7 Agree with the response

<Detlev> I'll scribe then

<Detlev> OK

<kirkwood> Agree with question on user agent side or author side. Therefore the response is difficult

alastairc: Agree with some comments. It was confusing to me if it was user agent side or another side. I ended up agreeing with the response, but want to change group to sub-group

<JF> https://www.w3.org/WAI/GL/WCAG3/2021/how-tos/clear-words/#develop-button

<Zakim> alastairc, you wanted to respond to JF

JF: it feels contradictory according to the link

alastairc: There are two different roles that need clarifying

<JF> +1 Melanie

JF: We don't have a mechanism in browsers that can do this. The User Agent might be able to do this in the future.

AWK: I agree with John. There used to be requirements for authors that became obsolete because of browser updates
… we should look at the requirements and see if the user agent handles it and if that would meet the requirement
… we have to accept that there may be a possibility that the developer might not have to do anything

Lisa: The issue with the tools is that you never had a guarantee that the definition is correct, which could be even more confusing

<LisaSeemanKest> for john ...https://lists.w3.org/Archives/Public/w3c-wai-gl/2002AprJun/0271.html

Rachael: We should say something like, "Thank you for the comment...." This brings up to a larger issue: If the user agent already does it, do we need a guideline?

JF: There's a fatigue factor and there's an issue with potentially incorrect definitions. There's no obvious answer to the fatigue issue, but the dictionary issue depends on what's used.

<Rachael> draft: Thank you for your comment. Most tools available today do not solve the overall issue of the necessity of writing with clear words so can’t be a sufficient technique. It may be a partial technique. Currently, the browser lookup function definition often does not provide the correct context for the content. We are closing this issue but are adding a label input-for-refinement to ensure the group considers your point as we move forward

<Rachael> and look at techniques.

Chuck: We have two options: amending and deferring

<mbgower> -1

<JF> -1

<MelanieP> -1

<ToddL> -1

mbgower: I think a better way to respond is to say the user agent mechanism doesn't meet the requirement

Chuck: I think we should defer and continue working on this

MelanieP: I think providing this technique doesn't require folks to use unclear words, just to define them.

<mbgower> The Design responsibilities cover the desired outcome; the dev responsibilities are 'back fill'

<LisaSeemanKest> john, you can see the latest drafts at https://docs.google.com/document/d/1XdI8vuEunDOcIJ0kY2eKGpCKxndEvflEDp737Q148IQ/edit#heading=h.g226sbxfxfhp

Zakim: next item

WCAG 2.2 Misc https://www.w3.org/2002/09/wbs/35422/wcag22-misc/

Chuck: Deferring focus appearance discussion due to absent members

<Chuck> https://www.w3.org/2002/09/wbs/35422/wcag22-misc/results

Question 1 - “Conformance Criterion” instead of “Conformance Requirement” used in the WCAG 2.1 Glossary #1758

Chuck: reviewing survey results

<JF> @Lisa, thank you for that link, which also suggests "...the user has access to an explanation within one click or event." and "Related Methods: * Using a popup glossary"

AWK: I'm in favor of the errata

Chuck: *reads Stephan's comments*

mbgower: The last two words of the sentence don't make sense

<bruce_bailey> +1 to AWK that this seems to be a 2.0 era shift in terminology

Chuck: This sounds like an amendment

mbgower: If we're doing an errata anyway, we can add this

<mbgower> https://www.w3.org/TR/WCAG20/#conformance-reqs

alastairc: We're in the conformance section and we're not talking about success criteria. We changed success criteria to requirement to avoid confusion

<Chuck> proposed RESOLUTION: Address issue 1758 by amending and updating PR for in WCAG 2.2 and include an errata on 2.1

Chuck: Any concerns adding Mbgower's change?

<mbgower> or lease toss "that" before Conformance Requirement

<Zakim> AWK, you wanted to agree that it only comes up in the note that is just in WCAG 2.1 (and 2.2)

mbgower: I can live with this, if it's been like this for a long time

<alastairc> https://github.com/w3c/wcag/pull/1777/files

alastairc: I've removed the last two words just in case

<Chuck> proposed RESOLUTION: Address issue 1758 by amending and updating PR for in WCAG 2.2 and include an errata on 2.1

<Chuck> proposed RESOLUTION: Address issue 1758 by amending and updating PR for WCAG 2.2 and include an errata on 2.1

+1

<AWK> +1

<mbgower> +1

<Detlev> +1

<ToddL> +1

<alastairc> +1

<ShawnT> +1

<kirkwood> +1

<bruce_bailey> +1

<Chuck> proposed RESOLUTION: Address issue 1758 by amending and updating PR for WCAG 2.2 and include an errata in 2.1

<JakeAbma> +1

<MelanieP> +1

<Chuck> +1

<laura> +1

RESOLUTION: Address issue 1758 by amending and updating PR for WCAG 2.2 and include an errata in 2.1

Question 2 - Incomplete/no techniques #1813

Chuck: Reviewed #1813

<MelanieP> +1 to Gregg

Chuck: Greg do you want to comment?

<Zakim> alastairc, you wanted to respond to gregg

<Chuck> proposed RESOLUTION: Accept PR 2131 to address issue 1813

alastairc: So to respond to Gregg, this change does not change anything except how it's presented. We should be okay to move ahead with this update.

<mbgower> +1

<bruce_bailey> +1

<Chuck> +1

+1

<ShawnT> +1

<laura> +1

<ToddL> +1

<alastairc> +1

<MelanieP> =1

<kirkwood> +1

<MelanieP> +1

RESOLUTION: Accept PR 2131 to address issue 1813

Question 3 - Problems with WCAG 2.0 Flash Definition #553

Chuck: Reviews survey

alastairc: To be honest, I'm not sure about the PR for #553. I have a feeling it's about one side of this update. I don't think we'd be doing any harm by transitioning to CSS

Chuck: *reads Gregg's comment*

<kirkwood> +1 to changing to CSS pixels per Alastair

Chuck: Gregg wanted something else, but the other comments wanted to tweak. Have you made those tweaks Mike?

mbgower: I'm making them now.

<Chuck> proposed RESOLUTION: Accept amended PR 2127 to address issue 553 and 585

+1

<Chuck> +1

<kirkwood> +1

<ToddL> +1

<alastairc> +1

<Ryladog> +1

<laura> +1

<ShawnT> 0

<Rachael> +1

<bruce_bailey> 0

RESOLUTION: Accept amended PR 2127 to address issue 553 and 585

Question 4 - Problems with WCAG 2.0 Flash Definition - max luminance #553

Chuck: *Reviews Q4*

<mbgower> pushed minor changes to #2127 to meet survey responses

<bruce_bailey> I think this is Andy Sommers comment that Chuck mentioned: https://github.com/w3c/wcag/issues/553#issuecomment-996157667

AWK: Basically my comment says that the luminance of white is one and black is zero, so you have to have a luminance difference of .1 (10 percent of max value). You're not measuring contrast, just luminance. You can have the colors flash because the difference between the colors is not enough

AWK: If you have two bright colors flashing, that would not count as a "flash" either

bruce_bailey: Mostly I think we need to rewrite this from scratch so that we all understand it.

<AWK> This should be an update to the understanding document for this SC

Chuck: *reads detlev's comment*

<mbgower> +1 to Detlev

<bruce_bailey> wrt my comment just now, we do seem to be consistent with *writing* "relative luminance" and not "luminance"

<bruce_bailey> https://www.w3.org/TR/WCAG22/#dfn-relative-luminance

<bruce_bailey> https://www.w3.org/TR/WCAG22/#dfn-general-flash-and-red-flash-thresholds

alastairc: So it sounds like we have two levels of things here. What is relative luminance: Maximum white in SRGB. It sounds like we could take on a rewrite.

AWK: So Alastair, are you saying we need a change to the document or response?

alastairc: Change to the document.

AWK: This would change general flash and red flash thresholds. We would add clarification. The more difficult alternative is to make it an errata

<bruce_bailey> from the URL i most recently pasted: A general flash is defined as a pair of opposing changes in relative luminance of 10% or more of the maximum relative luminance where the relative luminance of the darker image is below 0.80; and where "a pair of opposing changes" is an increase followed by a decrease, or a decrease followed by an increase, and

Chuck: Should we go the errata or understanding document update route?

alastairc: We'll have to come back to it

Chuck: No resolution today

Question 5 - Recommended viewport size for testing? #1829

Chuck: *Reviewed #1829*

<bruce_bailey> https://www.w3.org/2002/09/wbs/35422/wcag22-misc/results#xq6

<bruce_bailey> https://github.com/w3c/wcag/issues/1829

mbgower: The question was about recommended size for testing. A better response besides "all" would be to say you need to meet the requirement in all.

<mbgower> 'should be met across page variations'

rssAgent, make minutes

<JF> bye all