<J_Mullen> forgive - ant to be avail for scribing but in hypercar emeeting at same time where i must be ready to accept escalation

<Rachael> scribe: Wilco

<J_Mullen> hypercare (went spelled correctly)

New members and topics

Rachael: Any new members or new roles?
... And then what topics do we need to discuss in the near future?

<Rachael> Wilco: We should decide whether or not if the policy subgroup should give a quick update or not. we haven' done it with some but we should decide.

Announcements

<shadi> https://github.com/w3c/silver/wiki/Guidance-for-policy-makers-Subgroup

Shadi: Link to the subgroup page above. This is the guidance for policy makers subgroup.

<scribe> ... Continues on an outcome from the conformance options subgroup.

UNKNOWN_SPEAKER: This is not about trying go change WCAG's conformance requirements. We hope to get a rough sketch of what a guidance doc for policy makers could look like.
... Around mid June we'll report back to the group with interim findings.
... We meet Monday at noon Eastern, all info is on the page. You're welcome to participate or read minutes.

Bruce: We should think about if there's space for WCAG or related work to address the accessibility of ML / AI systems

Michael: The research questions task force is looking at this. I expect they'll develop guidelines for AI and accessibility.
... On training ethics, that is done by the machine learning working group.

<LoriO> where are the minutes kept for this meeting?

Michael: Training guidance probably belongs there.

<alastairc> I think the research group is the most similar to what LoriO was looking for

<MichaelC> -> Web Machine Learning Working Group https://www.w3.org/groups/wg/webmachinelearning

<laura> https://www.w3.org/WAI/GL/minutes-history.php

WCAG 2.2 ISSUE RESOLUTIONS https://www.w3.org/2002/09/wbs/35422/wcag22-misc5/results

Failure technique for Focus-not-obscured https://usercontent.irccloud-cdn.com/file/7ICVdk2c/image.png

Failure technique for Focus-not-obscured

<Rachael> PR: https://github.com/w3c/wcag/pull/3178

<Rachael> Preview: https://raw.githack.com/w3c/wcag/focus-not-obscured-failure-technique/techniques/failures/focus-not-obscured.html

Alastair: We have a couple WCAG 2.2 questions, than we'll go to backlog

<alastairc> Patrick's comment has been addressed

Rachael: ... reading from survey

Mike: Suggest just leaving the SC number.

GN: I hope it's clear what minimum and enhanced means

Laurie: Off topic, suggest we talk about methods for verification codes. I'll e-mail the chairs.

Alastair: It should be completely obscured for AA, partial for AAA. This one should make sense for the enhanced version.
... You're right this is the wrong way around. I think this version should line up with the SC, and then we can do a largely identical one for the other SC.

<Rachael> Draft RESOLUTION: Accept failure technique with edits discussed in meeting.

<LoriO> +1

<laura> +1

<mbgower> +1

<dan_bjorge> +1

<Ben_Tillyer> +1

<JenStrickland> +1

<bruce_bailey> +1

<jo_weismantel_> +1

<ShawnT> +1

<iankersey> +1

<J_Mullen> +1

<GN015> +1

<alastairc> +1, we'll keep it to one SC for now, and come back with an update to cover the other SC.

<Jaunita_George> +1

<Zakim> mbgower, you wanted to say what is etiquette for failing against lower level?

Mike: This technique would obviously fail the lower requirement, partially hidden. But do we only include it in AAA, or do we have it at AA as well?

Alastair: I thought we had a solution, forgot which one.
... I think for now we should keep it to one criterion and have a separate update to work for both.

RESOLUTION: Accept failure technique with edits discussed in meeting and come back with update to cover the other SC

Does 2.4.12 Focus not obscured encourage a keyboard anti-pattern #2809

<Rachael> PR: https://github.com/w3c/wcag/pull/3163/files

<Rachael> Issue: https://github.com/w3c/wcag/issues/2809

<trackbot> Sorry, but no Tracker is associated with this channel.

Alastair: We've done several PRs to go towards this. Particularly one from last week outlining examples.

Bruce: There aren't many changes since the last time we looked at this.

Alastair: 6 people reviewed. I think the typo Laurie found was fixed.

Bruce: I don't much like the phrasing, don't have a suggestion.
... The bigger conversation around lightboxes. If the focus is completely within the shadow of a lightbox, does that fail enhanced or not
... At enhanced there's a bit of a disconnect between the name and the text of the SC

Mike: I recommend open an issue separately.

<bruce_bailey> +1 for separate issue

Mike: I think the only way to bring that in would be to change the normative text.

GN015: I understood the normative text between focus obscured minimum and enhanced to be the same text.

Alastair: I think that's a copy/paste error. This section is there for preview. We'll correct that.

<Rachael> DRAFT: Accept PR 3163 and open new issue on lightbox issue.

<laura> +1

<Rachael> draft RESOLUTION: Accept PR 3163 and open new issue on lightbox issue.

<ShawnT> +1

Bruce: Can I open an issue for substituting pointer for maybe mouse cursor?

<Rachael> draft RESOLUTION: Accept PR 3163 and open new issue on lightbox and on substituting pointers.

Rachael: I'll capture that.

<LoriO> +1

<bruce_bailey> +1

<alastairc> +1

<J_Mullen> +1

<Ben_Tillyer> +1

<GN015> +1

<jo_weismantel_> +1

<mbgower> + .5 only because it's hard to parse exactly what was changed in the enhanced

<iankersey> +1

<Makoto> +1

<JenStrickland> +1

RESOLUTION: Accept PR 3163 and open new issue on lightbox and on substituting pointers.

WCAG 2.x backlog issues https://www.w3.org/2002/09/wbs/35422/wcag2x-backlog1/results

Changes/corrections to 1.4.3 and 1.4.6 understanding #3020

<Rachael> PR: https://github.com/w3c/wcag/pull/3020

Alastair: All these are working through our WCAG 2.x issues backlog. It's mostly on understanding and techniques documents.
... In this case, Patrick proposed including non-text contrast info into the text contrast documents regarding inactive components.
... This is aligning older contrast criteria with the newer ones.

GN: We have non-text contrast with 3:1, for example highlighting.
... When measuring before rounding its mostly impossible to fulfil these requirements together.

Rachael: I think a separate issue is appropriate here.

Alastair: I would wonder whether you need to have both text contrast and non-text contrast clashing.
... It would help to go into that scenario more in the issue.

Mike: I left a suggestion in the PR. There's stuff saying to suggest using text, but it's a requirement.

<alastairc> +1 to the suggesiton

Gregg: The understanding doc shouldn't use words like requires. Any sentence using requires or must sets a new requirement for WCAG.
... Must, shell, requires cannot be in informative documents.
... We don't say you can't have an image of text, we're saying you should have text where you have an image of text.

<JenStrickland> "shell" s/b "shall"

Mike: This is in a note an the existing understanding document.
... It doesn't cross-reference images of text.

Gregg: We can't reword a requirement.
... The best way you can do is quote from WCAG.

<Zakim> alastairc, you wanted to suggest just linking through to the other SC and to also talk about the language in understanding docs

Dan: I wanted to ask a clarification. I'm confused by what Gregg's describing. The entire purpose is to explain and reword the requirements that's more detailed and easier to understand. I wasn't aware there was a restriction of using the word "requires"

Alastair: My suggestion is to link to images of text SC. Then we don't have to spell out the requirements.
... We've had complaints about using words like must and should, as they are seen to add to normative requirements.

<mbgower> Existing note: Images of text do not scale as well as text because they tend to pixelate. It is also harder to change foreground and background contrast and color combinations for images of text, which is necessary for some users. Therefore, we suggest using text wherever possible, and when not, consider supplying an image of higher resolution.

Gregg: The understanding documents is to explain the rational, background, but cannot restate the requirement in other words.

<mbgower> Suggested change (last sentence only): Therefore, WCAG requires using text wherever possible (see _1.4.5 Images of Text_), and when not, it is recommended to consider supplying an image of higher resolution.

<Zakim> bruce_bailey, you wanted to ask if "we suggest" be "we recommend"?

<GN015> +

<mbgower> Me

<GN015> +q

Alastair: I removed that text entirely.

<mbgower> +1

<Rachael> Draft RESOLUTION: Accept PR 3020 with link to images of text and open an issue about the challenges on contrast

<alastairc> Images of text do not scale as well as text because they tend to pixelate. It is also

<alastairc> harder to change foreground and background contrast and color combinations for images

<alastairc> of text, which is necessary for some users. See <a href="images-of-text">1.4.5: Images of Text</a>.

GN: The text currently says "higher resolution" shouldn't it say "high resolution"?

<bruce_bailey> +1 for high resolution

<GreggVan> +1 has to be high not higher unless you state what it needs to be higher than.

Mike: The wording "higher resolution" is in the note. It predates the changes.

<Rachael> This is the text we are discussing: Suggested change (last sentence only): Therefore, WCAG requires using text wherever possible (see _1.4.5 Images of Text_), and when not, it is recommended to consider supplying an image of higher resolution.

Mike: I don't think the resolution should including having the PR.

<bruce_bailey> in context, note using "higher" is okay

Gregg: What Alastair suggested is different from the resolution. And you can't say "high" because "higher than what"?

<bruce_bailey> @gv, in context, higher is just an adjective

<Rachael> Draft RESOLUTION: Accept PR 3020 with a change to use a link to images of text instead of wording around requred and open an issue about the challenges on contrast

<GreggVan> bingo

<GreggVan> q_

<bruce_bailey> +1

<mgifford> +1

<GreggVan> +1

<dan_bjorge> +1

<garcialo> +1

<mbgower> +1 with the understanding that Gundula is opening the issue, not the WG

<JenStrickland> +1

<alastairc> +1

<kirkwood> +1

<LoriO> +1

<iankersey> +1

RESOLUTION: Accept PR 3020 with a change to use a link to images of text instead of wording around required and open an issue about the challenges on contrast

Inactive components in 1.4.3 & 1.4.6 Understanding #481

<GN015> +1 (yet I do not plan to open an issue on this "higher")

<dan_bjorge> It was in one of mbgower's suggestions earlier in IRC but isn't present in the PR anymore

<Rachael> https://github.com/w3c/wcag/issues/481

<Rachael> https://github.com/w3c/wcag/pull/3020/files

Alastair: This is taking the bit from non-text contrast and copying it into the text contrast document

<Zakim> alastairc, you wanted to comment on the word-smithing war of "disabled" vs "inactive"

<mbgower> "User Interface Components Visual information required to identify user interface components and states, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;"

Alastair: I thought there was a difference so that they're not interchangeable.

<AWK> +AWK

Mike: Inactive is not a defined term, but it's used in normative text.
... We use inactive as a synonym for disabled. If we were to change the meaning of it we'd have to do some work.

<dan_bjorge> The specific example with an unselected tab in a tab strip is something we've specifically run across people with questions/misunderstandings about - most of our users consider such a tab as "inactive" but not "disabled"

<bruce_bailey> +1 that there was a round of changing "disabled" to "inactive"

Rachael: Because a change in one place has a massive effect in other places I think we consider this a separate issue.

+1 Rachael

<garcialo> +1 Rachael

<dan_bjorge> +1

<JenStrickland> +1 to that conversation

<LoriO> +1

<bruce_bailey> +1 to approach

<mgifford> +1

<alastairc> +1, it needs some research into where it is used

<AWK> +1

<kirkwood> +1

<ShawnT> +1

<Makoto> +1

<mbgower> +1 (and note that there is a clarifying parenthetical piece of info used in this PR)

Alastair: I'll open an issue for that

<Zakim> bruce_bailey, you wanted to mention "not available"

Bruce: I want to capture the concern. Not available is also a third category? Not sure.

<alastairc> the term 'inactive' is interpreted as 'not receiving action' which implies read-only elements as well as ordinary text.

<alastairc> It is also interpreted as 'not currently active' like tabs in a tab strip which are not currebtly selected.

<alastairc> Therefore please use the term 'disabled' exclusively and do not use the term inactive in this context.

<alastairc> ^ From Gundula's comment

<Rachael> draft RESOLUTION: Accept PR 3020 but open an issue examining inactive, disabled, and not available.

<alastairc> +1

<iankersey> +1

<dan_bjorge> +1

<Rachael> +1

<laura> +1

<bruce_bailey> +1

<LoriO> +1

<Ryladog> +1

<Ben_Tillyer> +1

<AWK> +1

<JenStrickland> +1

<garcialo> +1

<mbgower> +1

<Makoto> +1

<mgifford> +1

<kirkwood> +1

<GreggVan> +1

<GN015> +1

<ShawnT> +1

RESOLUTION: Accept PR 3020 but open an issue examining inactive, disabled, and not available.

2.5.3 Label in Name - aria-hidden on part of visual label #2302

<Rachael> https://github.com/w3c/wcag/issues/2302

Rachael: This addressed two issues

<Rachael> https://github.com/w3c/wcag/issues/2276

<Rachael> https://github.com/w3c/wcag/pull/2725/files

Alastair: Another one from Mike, where label in name had some interesting impact in terms of things people might do to benefit screen readers, causing them to fail label in name.
... The example, a label that hires "(required)" From assistive tech to avoid duplicating itself.
... We're more or less trying to say this is not a problem if punctuations aren't read out.

Rachael: Numbers on the survey are a bit low
... There are different ways we can do this.

Mike: We have to have wording on what the rules should be.

<Rachael> Wilco: ACT is actively working on this area and shoudl get a chance to review this.

Mike: there are some other questions from ACT on how to interpret label in name.

<alastairc> suggest 2nd approach, aprove and hand to ACT to review, prior to merging

Mike: I think we have to lead with guidance from the working group.
... We have to put the line in the sand.

Rachael: Alastair suggested approving from us, and passing to ACT before merging.

+1 on that approach

<dan_bjorge> +1 to that approach

Mike: There is a change in the actual testing of G211

<Rachael> Options: 1. Hold off approving, 2. Approve but ask for review before merging 3. Approve and merge and ask for review and new issues

<Rachael> draft RESOLUTION: Accept PR 2725 but request review from ACT before merging.

<bruce_bailey> +1

<ShawnT> +1

<laura> +1

<garcialo> +1

<mgifford> +1

<LoriO> +1

<Makoto> +1

<mbgower> +1 although I think 3 is also a valid approach

<Ryladog> 1

<alastairc> +1

<iankersey> +1

<dan_bjorge> +1

<JenStrickland> +1

<Ben_Tillyer> +1

<kirkwood> +1

<Raf> +1

RESOLUTION: Accept PR 2725 but request review from ACT before merging.

<Rachael> scribe: bruce_bailey

How can we make surveys easier to fill in?

Rachael, through survey, to alstair side bar

alastairc: We have good stack of issues, we need feedback in survey for meeting

<Rachael> You can always see the surveys at https://www.w3.org/WAI/GL/wiki/Upcoming_agendas

alastairc: can fill in and revisit, we have a backlog
... what might chair do different to encourage more answers?

Wilco: Can we have two weeks rolling as default?

<dan_bjorge> For me it's just lack of work time to allocate, I think the surveys are already very well-organized

Wilco: Some of these survey have a very long list of items.
... Some take 30 minutes to review in detail.

Andrew: I would like to have more context, especially for 2.x items
... some are one of N number of issues and some are fairly trivial but some are deep
... need more context if possible
... especially if survey is holding up a publication.

<Ben_Tillyer> +1 to AWKs comments

Andrew: might be apparent for some people, but as a long time participant, the urgency is not apparent.

alastairc: We have about dozen 2.2 issues and those are prioirities, but we do not have PRs so cannot put into survey...

<Rachael> Calendar: https://www.w3.org/groups/wg/ag/calendar

alastairc: please be encourages to look for some on git hub
... sympathize with Wilco because it is also quite a bit of work to put items into survey

<alastairc> 11 left! https://github.com/w3c/wcag/issues?q=is%3Aissue+is%3Aopen+label%3A%22WCAG+2.2%22

alastairc: backlog items are lower priorities but there are a bunch and we fill in between 2.2 blocking items

AWK: I would like more information about how many questions, how much time survey might take, and urgency.

alastairc: That is hard to know ahead of time -- because it depends on what work is made during the week.
... please at least take a half hour and get through as many as you can.

<alastairc> Good point, we can spread it out

rachael: if you only have half an hour -- pick a survey question that has few replies

<mbgower> We can also aim to make changes be discrete, so they are easier to digest and assess

alastairc: Github issues are tagged, please take a look

Updating landmark techniques

alastairc: AGWG members invited to work through.

<Rachael> https://github.com/w3c/wcag/issues/291

<Rachael> https://github.com/w3c/wcag/pull/1269/files

<Rachael> https://github.com/w3c/wcag/pull/2338/files

[alastair demos working through issue]

<Rachael> https://github.com/w3c/wcag/pull/2435/files

[alastair demos how to follow links from survey into github issue and then to PR]

<Rachael> draft RESOLUTION: Accept PRs 2435, 2338, 1269

<LoriO> @bruce_bailey +1

<alastairc> Thank you :-)

<GN015> +1 to thank you

<mbgower> +1 in memoriam to Carolyn

bruce thanks alastair for making surveys easy (as possible) to follow

<Jaunita_George> +1

<LoriO> +1

<laura> +1

<ShawnT> +1

Rachael: neg one if you want more time or to disagree

<Wilco> I wouldn't mind more time for this...

<mgifford> +1

<garcialo> +1

<Makoto> +1

<Ryladog> +1

alastairc: Wilco can I email list with request for additional update?

wilco: okay

RESOLUTION: Accept PRs 2435, 2338, 1269. Alastair will email update to list for additional review

Clarification on 3.1.2 Language of Parts #297

<Rachael> https://github.com/w3c/wcag/issues/297

<Rachael> https://github.com/w3c/wcag21/issues/287

<Rachael> https://github.com/w3c/wcag/issues/1174

alastairc: We have had a few issues and questions about if language of parts applies to a single word...

<Rachael> PR: https://github.com/w3c/wcag/pull/808/files https://usercontent.irccloud-cdn.com/file/nn2DzBBr/image.png

alastairc: there is an additional example

<Rachael> https://github.com/w3c/wcag/pull/808/files

Rachael: 4 people accepted with no comments

Mike Gifford: There are lots of times when single words are in the vernacular -- have we added clarification for that exception?

<AWK> e.g., deja vu

<Ben_Tillyer> Example - I've been looking at some thai sites today, which make use of the word "ACCESSIBILITY" in latin script

Wilco: Seems very strict, does not seem intent of the SC...

<mbgower> "Because this is so common in some languages, single words should be considered part of the language of the surrounding text unless it is clear that a change in language was intended."

Wilco: language menu makes sense -- but individual words in a sentence ?

<Zakim> mbgower, you wanted to say have a look at https://www.w3.org/WAI/WCAG21/Understanding/language-of-parts.html

Wilco: switch LANG ends up pausing Screen Reader sometimes

<mgifford> Thanks for the clarification on the change Mike.

MikeGower: Not changing any normative requirement or even the guidence -- Patrick just added a example of language menu.

<Zakim> alastairc, you wanted to say that it's worth reading the threads, they did seem to resolve

Glenda Sims: We have done testing and single words don't interupt screen reader like it might have in the past.

alastairc: The consenus from the issue thread is that single words should be marked up more often than not

<garcialo> +1 Wilco

Wilco: The example is stricter than the exception mentioned in the SC text

Rachael: Since there is so much conversation today, I will table this one, and pick up next week.

<mbgower> "words or phrases that have become" Don't see how it is expanding the meaning

alastairc: This will be at top of the survey -- but survey URL will be unchanged

Rachael: We will also defer on Time Outs since survey feedback light

Subgroup reporting

Right now we are focused on 2.2, but there are 3 subgroups active and in planning

scribe: question asked if email reports are sufficient?

Rachael: We are primariliy 2.2 for a while, so not so fair to 3 folks

<Wilco> +1

<Rachael> strawpoll: 1) Short update at meeting 2) Email only 3) other

<kirkwood> 1

bruce prefers in-person reporting and having in agenda

<Ryladog> 1

<Jaunita_George> 1

<mbgower> 1

<dan_bjorge> 1

<LoriO> +1 Bruce

<ShawnT> 1

<Ben_Tillyer> 1

<laura> 1

<LoriO> +1 Bruce's suggestion

Rachael: seeing a strong preference for update in meeting

Any thing else?

Rachael notes that folks less in favor have dropped

<Glenda> I’m curious, when will WCAG 2.2 CR be updated? I’m still seeing the Jan 25th date. Am I having a caching problem?

<Rachael> Wilco: Previous topic on Label in Name, I am curious why we are ok with that () exception. Does that give us flexibility there? Does it apply to other things?

Wilco: Going back to Lable in Name, I agree with technique but does SC provide that flexibility?

Wilco is this first time this has come up? I do not think so.

Mike Gower: Agree it is NOT first time, and maybe Label in Name might have been phrased a little better...

scribe: but I think it comes down to what *looks* like a label versus what is programatically a label
... I am not confident with research and some complaints seem to antedocal or even theoretical...
... and would locking down create more problems?

<Wilco> Thanks. That's a fair point

dan_bjorge: Agree that WCAG definition for label is where the ambiguity comes from. There is disconnect to normative

<Rachael> Rachael: CR will be updated very soon

This is scribe.perl Revision VERSION of 2020-12-31
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/not currebtly active/not currently active/
Default Present: jon_avila, alastairc, Jennie, bruce_bailey, Ben_Tillyer, J_Mullen, dan_bjorge, Rachael, Makoto, Daniel, Laura_Carlson, sarahhorton, LoriO_, mbgower, kirkwood, Detlev, shadi, GreggVan, Chuck, Francis_Storr, LoriO, ShawnT, Jaunita_George, JustineP, Wilco, MichaelC, iankersey, JenStrickland, Caryn, garcialo, AWK, Katie_Haritos-Shea, Glenda, GN015_
Present: jon_avila, alastairc, Jennie, bruce_bailey, Ben_Tillyer, J_Mullen, dan_bjorge, Rachael, Makoto, Daniel, Laura_Carlson, sarahhorton, LoriO_, mbgower, kirkwood, Detlev, shadi, GreggVan, Chuck, Francis_Storr, LoriO, ShawnT, Jaunita_George, JustineP, Wilco, MichaelC, iankersey, JenStrickland, Caryn, garcialo, AWK, Katie_Haritos-Shea, Glenda, GN015_
Regrets: detlev, Sarah H
Found Scribe: Wilco
Inferring ScribeNick: Wilco
Found Scribe: bruce_bailey
Inferring ScribeNick: bruce_bailey
Scribes: Wilco, bruce_bailey
ScribeNicks: Wilco, bruce_bailey

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

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.)