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

present

I

<laura> https://www.w3.org/WAI/GL/wiki/Scribe_List

It's only my second meeting so Im very new. But I can try to scribe

<alastairc> scribe:Bri

<laura> Scribing Commands and Related Info: https://www.w3.org/WAI/GL/wiki/Scribing_Commands_and_Related_Info

alastairc: gives an explanation of how to scribe

Subgroup updates

alastairc: opened the floor to new members who want to introduce themselves

<scotto> present_

alastairc: first meeting topic is subgroup updates

Francis_Storr: group met yesterday. they're working on writing outcomes and other methods. They are not meeting next week for the 4th. Meeting at Friday at 9am to focus on getting the rest of outcomes written

Rain: giving an update on Harm. gave a quick update last week. Their goal is to to give an exploratory version of the guideline and outcomes for Harm. If time permits they'll work on stretch goals to define motion and harm
... they've accomplished functional needs and developed user stories and outcomes for final output
... listed outcomes they are elaborating on including user-control, continuous motion, and physical reactions
... identified the remaining big open questions

<GreggVan> harm from perceived motion?

Rain: identified the next steps from each outcome
... explained that nothing will be final, it will all be exploratory

<Zakim> mbgower, you wanted to say have you had much luck identifying supporting research for motion triggering thresholds?

alastairc: one question from Mike

Mike5Matrix: when working on 2.1, there was a problem with threshold. Any luck identifying research to support that

<alastairc> z/mbgower/mbgower

Rain: yes members of the group have identified some research to identify threshold. But the goal is to identify high levels and clear path forward at this time

<Zakim> mbgower, you wanted to say that expressing as enabling users could be a positive; but maybe "don't" is okay too?

Mike5Matrix: follow up, if you're looking a more positive spin, "give users control of motion behavior" as an example

WCAG 3 Issues

alastairc: that's it for subgroup updates. Any other questions
... moving on to WCAG 3 issues

<Rachael> https://docs.google.com/document/d/1Zt0j8cBb8cbmwFvO4qmvRnvjPOFyZoR9UOAw3aUxkL4/edit

Rachael: discussed moving issues against 3 moved to new charter/repository
... Thought is we have 3 bins that need to be resolved: one that working draft that have a draft response, questions that we as a group are still discussing, items that apply to guidelines that will be integrated to subgroups
... other bin is editorial
... the question back to group, how would you like to review as we resolve
... as we're done binning, we will draft and ask you to go through them. you can only review those in specific queues (core questions).
... another option only review issues that are reopened
... sorry for the use of binning
... how would the group like to handle this?
... offers a poll

<Detlev> I did not really understand the options, it seemed very complex...

<Rachael> strawpoll: 1) Review everything except other 2) Review only items in one response type 3) Only review issues that are reopened

alastairc: editorial requires small amount of time

<Zakim> jeanne, you wanted to say that the most efficient is better

<Rachael> +1 to efficiency on these

jeanne: old comments, from 2020, should be efficient as possible since many are irrelevant

<kirkwood> +1

<Daniel_HE> +1

alastairc: thinks this would #3

Rachael: yes, that would be #3 only thinks reopened. That's what I would recommend

<Zakim> Chuck, you wanted to ask about individual's '+1', does your plus one mean support for option 3?

<kirkwood> 3

Chuck: I saw +1 and I don't know how to interpret. Is this support in straw poll?

<ShaneDittmar> #3

<Detlev> I don't know if I have enough of an overview of the state of things to make a meaningful choice... abstain

alastairc: not seeing a lot of activity in IRC
... is anyone concerned if we only bring issues that are reopened?
... editorial and fits into response type would be closed and we move on. If concerned, now would be the time to say

<jeanne> 3

Wilco: I'm not comfortable mass closing. People spend a lot of time giving feedback
... I do agree with a wider look would be warranted

<mgifford> If issues are respectfully closed, they can always be re-opened.

Wilco: might as well not ask for public feedback

GreggVan: anything you think the group is going to want to talk about, you should bring to the group
... I think the way I'd do it is to let it be editors discretion

<Zakim> alastairc, you wanted to comment on what happens to the old issues

alastairc: I put myself to chat and respond to the scenario we are in
... a lot of cases, we have a first draft. comments in first draft. comments prompt changes. then go into editorial notes, not been solved which is why left open

<Zakim> jeanne, you wanted to respond to Wilco

alastairc: but not necessarily relevant to the upcoming draft. So since they're not relevant, they've been left or included in editorial drafts

Jeanna: mostly what alastair said. We had editorial is because the group wanted to review everything but no one has that kind of time. we have an old problem

Jeanne: this is a policy for handling old problems. Not for what we should do moving forward

<mgifford> jeanne +1 to that

<Chuck> +1 that this is a one-off, not intended to be precedent setting

shadi: I think the editors are in the best position to decide what needs to be discussed among the group

<alastairc> +1 to sending list out for transparency

shadi: on the other hand, maybe a compromise, maybe send weekly here are the issues we've closed. So if someone has issues/concerns they can reopen them
... this gives editors discretion to what needs discussing

Rachael: this process doesn't mean content would be lost.
... believes there is benefit in this approach. A lot of issues are around core questions so having single discussions and linked/summarizing would make these discussions efficient

<Rachael> +1 to weekly lists

alastairc: confirmed nothing would be lost because old content would be linked in the new repository

Rachael: yes that is correct

<Rachael> draft proposal: Editor's discretion with lists of work done each week

alastairc: it would be closed but not lost/deleted

laura: do you think the commentors would know how to reopen issues or would there need to be a discussion about that?

alastairc: asked who would know the answer to that?

Gregg: congress has something called consent or something. If you have a bunch of issues at the beginning of the meeting you can give a long list

GreggVan: if they want to bring things back up, they can. If not they just run through the rest of the list. This could be something to consider

alastairc: yes I think we are talking roughly about the same thing. grouping the issues

Rachael: there was a question to answer. Anyone who emailed the comment and marked as email, we would email them back

<laura> Thanks.

alastairc: so yes, we have a mechanism to get them back

<jeanne> we also have a list of all the emails on the Comment list archive

shadi: currently a lot of workload to get agreement on every step. Suggestion is to update the draft as a group and then send an email to all commentors and ask them to review it
... those who use github and collaborative system can, but I think it would add a lot of overhead to get agreement from every commentor

alastairc: agrees about getting agreement. It's yes incorporating comment from editorial

shadi: think it might be too early to get external involvement while going through other isues

alastairc: sounds like we have general agreement

<jeanne> Email comments from archive https://lists.w3.org/Archives/Public/public-agwg-comments/2021Mar/

dan_bjorge: asks what the scope is for this

alastairc: there are 3 repos. WCAG 2, Silver repo (old one), and WCAG 3 (new one). The ones in Silver are what coming into WCAG 3
... WCAG 2 is a good resource but out of scope in this conversation
... i think we have general agreement. We have a couple concerns but I think emailing out will be helpful and including links from old issues so they're not lost
... with that in mind, any other concerns with adopting this?

<alastairc> https://docs.google.com/document/d/1Zt0j8cBb8cbmwFvO4qmvRnvjPOFyZoR9UOAw3aUxkL4/edit

<mbgower> +1 looks good

alastairc: by this approach, referencing the document Rachael referenced
... yes lets get a resolution

<Rain> +1

<poornima> +1

<alastairc> draft RESOLUTION: We will adopt the approach outlined in the document "Resolving WCAG 3 FPWD issues", closing them in favour old new issues/discussions in the new repo

alastairc: adopt the approach outlined in the document

<alastairc> draft RESOLUTION: We will adopt the approach outlined in the document "Resolving WCAG 3 FPWD issues", closing them in favour =new issues/discussions in the new repo

<ShawnT> +1

alastairc: if you can +1 or otherwise

<ShaneDittmar> +1

<poornima> +1

<Jennie> +1 (knowing emails will go to those who emailed)

<Rain> +1

<Chuck> +1

<jeanne> +1

<Daniel_HE> +1

<shadi> +1

<Makoto> +1

<sarahhorton> +1

<Detlev> 0

<kirkwood> +1

<JustineP> +1

<tburtin> +1

<Rachael> +1

<iankersey> +1

alastairc: +1 agree. -1 disagree. 0 abstaining or don't mind

<Francis_Storr> +1

<mgifford> +1

<laura> +1

<Wilco> 0

<dan_bjorge> 0

RESOLUTION: We will adopt the approach outlined in the document "Resolving WCAG 3 FPWD issues", closing them in favour new issues/discussions in the new repo

<Chuck> 16 ones, 3 zeroes

alastairc: yes we will resolve. any other questions about that topic?

Rachael: good to move on

alastairc: moving on to WCAG 2

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

alastairc: I could've sworn I did this agenda item

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

GreggVan: quick question. trying to find and hover, pop something up, that has to be true with keyboard focus. I couldn't find that mentioned anywhere. Did we mention that anywhere?

alastairc: that's generally covered under keyboard

GreggVan: I can't hear anything
... I was muted, I hear you now

alastairc: ok yes that is under keyboard
... if you can't find it let us know
... chuck will you take over now?

Question 1 - Understanding for Contrast does not call out Color Blindness #2033 (take 3)

Chuck: yes, if you'll start sharing your screen and we'll start with question 1
... we'll do this traditionally in the past
... issue 2033, understanding contrast doesn't call out color blindness. Discussed last meeting but didn't come to a conclusion
... one individual had a suggestion for changes

alastairc: i'm assuming andrew isn't here which is why Im speaking for him
... he wanted light/dark contrast. I need to refresh my memory on this
... this is a question for Bruce, Mike, and others involved

Chuck: mike is in que

mbgower: agrees it works fine based on grammar rules

GreggVan: lightness and darkness are adj not nouns. so works fine

<Zakim> Chuck, you wanted to ask Alastair if the PR is being updated?

Chuck: are we updating PR

alastairc: PR are remaining because people on the call said it was correct

<Chuck> draft RESOLUTION: Accept PR 3284 to address issue 2033

<Zakim> mbgower, you wanted to say I have a comment

Chuck: okay I'm going to propose a draft

mbgower: the third paragraph seems out of context. Suggests moving it down and specifically says where in my comments

alastairc: text that is decorative is that what you mean?

<Chuck> draft RESOLUTION: Accept PR 3284 to address issue 2033

<dan_bjorge> +1

<alastairc> +1

<GreggVan> +1

<laura> +1

<Ben_Tillyer_> +1

mbgower: says he will handle it in a PR

<ShaneDittmar> +1

<Makoto> +1. Also +1 to Rain's suggestion.

Chuck: submits a PR

<Detlev> +1

<iankersey> +1

<Jaunita_George> +1

<mbgower> +1

alastairc: rain's suggestion was...

Rain: my suggestion is a future consideration than now

<mbgower> Rain, see first note: Note This should not in any way discourage the use of color on a page, or even color coding if it is complemented by other visual indication.

Rain: things related to color in WCAG, now, is color is bad for accessibility. but there are those that color can be a support. So I'm wondering if that is a new issue that can be raised, that color can be helpful

<mgifford> +1 to Rain's point. Color alone is a problem, but color with other indicators is good.

<Zakim> Chuck, you wanted to say that we should treat Rain's comments as a separate issue

Rain: it can help get rid of the myth that color is pure bad

<GreggVan> +1 to ALWAYS include a comment on the "not only color" itme that says color is always great - but should not be only

Chuck: I think it should be a separate issue since we're on the cusp of solving this one. but agreeing it should be an issue

dan_bjorge: the wording, I think is in the use of color understanding page. Also agreeing a separate issue

Chuck: so far draft resolution has all support
... last call

RESOLUTION: Accept PR 3284 to address issue 2033

Chuck: so resolved

Question 2 - Update PDF techniques #3354

Chuck: moving on to second question. as I update topics
... update PDF techniques #3354
... editorial change. 5 people agreed. one person wanted something else. Jedi Lin, oops you're all over the place Alastair

Francis_Storr: the W lifecycle mentioned it. It was one out of 23 different PDF techniques. Doesn't think it is a particular issue

alastairc: I think that's fine for the moment. Potentially anybody would like to add something in, happy to do that. There is a PDF association, promising place for updates

<Chuck> draft RESOLUTION: accept amended PR 3354 to address updating PDF techniques.

Chuck: no one else in queue, making a resolution

dan_bjorge: maybe I missed it. Andrew said he has a subject matter expert. Do we want to merge this before that happens?

<Chuck> +1 to merging and being ready to do updates

alastairc: willing to do updates with one removal

<Chuck> draft RESOLUTION: accept amended PR 3354 to address updating PDF techniques.

LoriO: the group coming out with all PDF techniques, they are supposedly publishing 40 by end of year and we'll have to go through PDFs when they come out

Chuck: going back to PR

<Chuck> +1

<ShawnT> +1

<Francis_Storr> +1

<ShaneDittmar> 1

<Rain> +1

<dan_bjorge> +1

<Raf> +1

<Detlev> +1

<alastairc> +1, and happy to do another update if Andrew/Rob find things to do.

<laura> +1

<GreggVan> +1

<Ben_Tillyer_> 0, haven't had time to read this one

<Makoto> +1

<ShaneDittmar> +1

Chuck: Shane, just to be clear, +1?

<tburtin> +1

ShaneDittmar: yes plus didn't work

<LoriO> +1

Chuck: thank you
... any last concerns?

RESOLUTION: accept amended PR 3354 to address updating PDF techniques.

Chuck: so resolved

<Francis_Storr> yay!

Question 3 - Use of Color Understanding doc: add note concerning same color case #3286

Chuck: question 3 use of color understanding doc #3286. does it fail "use of color" if there is no color difference

alastairc: Andrew wanted to add a note to the sentence. couple of wording suggestions in the PR
... shane do you want to talk through your issue?

ShaneDittmar: concerned about the portion that is explaining it is a bad experience for people
... right now it says it's a bad experience for sighted users. I dont think it is exactly accurate

<Rain> +1 "could be a poor experience for any user"

<Wilco> +1 Shane, the PR doesn't need that language

ShaneDittmar: who are we calling sighted and is it necessary to say it is a "poor experience"

<Rain> and +1 to not needing to be explicit

<dan_bjorge> "Sighted" has already been removed from the PR, it's not in the current version

scotto: I've made updates to the PR.

alastairc: well that would be why I wasn't sure what was being talked about

Chuck: ha that's awesome

alastairc: if we have the people on the call, Mike are you happy with the updates made?

mbgower: yes but I think saying sighted users is accurate

GreggVan: I think to say bad practice to use color coding is too far

<ShaneDittmar> +1 to the new version once it has a small editorial update ("result in" instead of "result for")

GreggVan: that would mean to have it in bold but not also in color. I think we need to say color can be beneficial. I think it should say can, not should

<kirkwood> reducing color can be better for users it causes fatique

Chuck: I do have a comment, I want to pause for a moment
... time to change scribe

<Wilco> scribe+

<Wilco> Chuck: If we are concerned about the mention, could we rephrase it?

<mbgower> it doesn't

<Zakim> Chuck, you wanted to suggest "everyone" instead of "sighted"? and to also ask for a change in scribe

<Wilco> Scott: Already made the update

<Wilco> Detlev: I think the point is its a bad experience. If there's no difference you don't need to use color, underline would be fine.

<mbgower> "such lack of styling differentiation"

<Wilco> ... The lack of any difference would make a poor experience

<alastairc> Current: "Such styling would result for poor usability for many users, regardless of disability."

<Wilco> Scott: Agreed, I understand the point, but the text specifically calls out there is no difference.

<Wilco> ... The whole idea is that the text is no different from static text

<Wilco> Kirkwood: From a cognitive perspective its often recommended to reduce the color on or put it into black and white if you can

<alastairc> Suggestion: "Such such lack of styling differentiation could result for poor usability for anyone looking at the interface, regardless of disability."

<Wilco> ... I think we should be careful about the generalisations. There is an opposite effect as well

<Wilco> Mike: If the wording is being misinterpreted we can be more explicit, but the scenario here is that there is no visual difference.

<Detlev> +1 to Mike

<Zakim> Rain, you wanted to suggest changing the word "would" to "could"

<Wilco> ... Someone who's not looking at this will get the information programmatically. By being more general, we make it less precise

<Chuck> +1 to Mike

<laura> +1 to Mike

<Zakim> ShaneDittmar, you wanted to respond to "sighted"

<Wilco> Rain: In terms of being prepared for edge cases, so change the word should to would

<Wilco> Shane: Sightedness is not a binary state. Not everyone who can perceive will be inherently impacted. I don't think its necessary to ascribe it to visualness

<Wilco> ... This does not impact all sighted users.

<Rain> +1 to alastairc's update

<Chuck> draft RESOLUTION: Accept amended PR 3286 to address issue 1467

<Wilco> Alastair: There are different modes of access. Rather than talk about whether it's visual or not, it can be for anyone who's looking at the interface

<ShaneDittmar> +1 to alastairc's version

<mbgower> new issue

<Wilco> Dan: The context makes this fairly explicit

<Chuck> draft RESOLUTION: Accept amended PR 3286 to address issue 1467

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

<Wilco> Alastair: I think Detlev's suggestion was included

<Chuck> +1

<Rain> +1

<Jaunita_George> +1

<Ben_Tillyer_> +1

<Daniel_HE> +1

<mbgower> +1

<LoriO> +1

<scotto> +1

<ShawnT> +1

+1

<dan_bjorge> +1 (with or without Alastair's last suggestion, fine either way)

<tburtin> +1

<iankersey> +1

<Makoto> +1

<mgifford> +1

<ShaneDittmar> +1

<laura> +1

<Wilco> +1

<kirkwood> +1

<Detlev> +1

<Wilco> Mike: I corrected "such such"

RESOLUTION: Accept amended PR 3286 to address issue 1467

RESOLUTION: Accept PR 3277 to address issue 3187

<Wilco> Chuck: ... Reading question. Everyone agreed with the update, with no comments

<Wilco> Chuck: Any concerns with accepting the PR?

<alastairc> +1, no concerns.

<Ben_Tillyer_> +1 :)

<ShaneDittmar> +1

<dan_bjorge> +1

<kirkwood> +1

<Detlev> +1

<tburtin> +1

<LoriO> +1

<mbgower> +1

<Makoto> +1

<scotto> +1

Question 5 - Tweaks/additions to Understanding Pointer Gestures #910

<mgifford> +1

<Wilco> Detlev: Never been a great fan of the intermediate point concept to define directionality

<Wilco> ... This has been difficult to explain to testers. There are cases where you're required to make horizontal movement ,but it's still basically dragging

<Wilco> ... On mobile a horizontal move may do something different from a vertical move. It has directionality

<Wilco> ... There are other factors too, speed, or swiping half-way, or fully to the end of the screen behaving differently.

<Wilco> ... I would prefer a different definition to pointer gestures. If speed or direction is part of it it should be a pointer gesture

<Zakim> Chuck, you wanted to ask Detlev if this is specific to the PR, or general concerns about understanding of pointer gestures understanding?

<Zakim> alastairc, you wanted to ask whether this improves current understanding doc, with current approach.

<Wilco> Chuck: Does this PR incrementally improve the understanding doc?

<Wilco> Alastair: We have a current approach, Detlev's suggesting a different approach.

<Wilco> ... I don't think we defined pointer gestures, so we have some flexibility, but we don't have something concrete in front of us

<Wilco> Detlev: Its hard to find a definition. Now that we have dragging movement, it does make things easier. I think we need to talk it back to the drawing board.

<Wilco> ... It would be better to postpone this, and I can try to propose something in an issue or PR

<Zakim> mbgower, you wanted to say that I don't see us in a muddier situation with the addition of dragging, but it also seems outside the PR discussion

<Wilco> Mike: I think with the addition for dragging, the only area where you don't have to do something is path based gestures.

<Wilco> Alastair: I still think it improves what we have in the moment. I'd be inclined to merge it and then have a look to see what we can do

<Chuck> draft RESOLUTION: Accept PR 910 to update Pointer Gestures understanding document

<ShaneDittmar> +1

<Chuck> +.5

<LoriO> +1

<ShawnT> +1

<Detlev> 0

<tburtin> +1

<Rain> +1

<Jaunita_George> +1

<mbgower> one sec

<iankersey> +1

<dan_bjorge> -.5

+1

<Wilco> Dan: I'm not that opposed, but the wording of it, and the figure captions in particular are hard to distinguish. It sounds like they are defining path based gesture, rather than as examples

<Wilco> ... This makes it less clear that these are examples

<Wilco> Mike: Line 17 looks like an addition to me, which I don't think I agree with

<Wilco> ... I don't think that description is true

<LoriO> +1 dan

<Wilco> Dan: I think that is a true example of a path base gesture, but the wording makes it seem like a definition

<Wilco> Mike: I think we can tweak this a bit

<mbgower> path-dependent, alastair

<Wilco> Alastair: I thought signatures is more free flowing, but something like two directions like on talkback is a gesture

<Wilco> Detlev: Those come from the operating system. Haven't seen one from authors. I think it would be better to take a step back, but not against

<Wilco> Chuck: So no resolution, this will continue to be worked on

<Wilco> Mike: We've had In brief added to WCAG 2.2 and 2.1

<Wilco> ... We talked with EO and made a few more changes.

<Wilco> ... The 2.0 SCs we just have the existing language. This PR is changes the preface for all WCAG 2.0 SCs

<Wilco> ... There is some phrasing inconsistencies, but it would be useful to have some more eyes on it

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

<Wilco> ... If people want to have a look at it, please. I expect we'll iterate on this a few more times

<Rachael> Please complete the TPAC survey at https://www.w3.org/2002/09/wbs/35422/tpac-2023/

<Rachael> Today if possible :)

<alastairc> Even if you aren't going, it helps to know that!

<Wilco> Chuck: Reminder, please fill out the TPAC survey. This will help us craft the subgroups for TPAC

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/Mike5Matrix/mbgower/
Succeeded: s/coveted/covered/
Succeeded: s/Mike5Matrix/mbgower/
Succeeded: s/I think the use of color/I think is in the use of color understanding page/
Default Present: Francis_Storr, Wilco, ChrisLoiselle, ShawnT, shadi, jon_avila, JustineP, Daniel_HE, ShaneDittmar, alastairc, Jennie, dan_bjorge, Jaunita_george, tburtin, mgarrish, LoriO, Makoto, kirkwood, Laura_Carlson, Rain, scotto, sarahhorton, Detlev, mbgower, jeanne, Chuck, GreggVan, iankersey, mgifford, poornima, Ben_Tillyer_, .5
Present: Francis_Storr, Wilco, ChrisLoiselle, ShawnT, shadi, jon_avila, JustineP, Daniel_HE, ShaneDittmar, alastairc, Jennie, dan_bjorge, Jaunita_george, tburtin, mgarrish, LoriO, Makoto, kirkwood, Laura_Carlson, Rain, scotto, sarahhorton, Detlev, mbgower, jeanne, Chuck, GreggVan, iankersey, mgifford, poornima, Ben_Tillyer_, .5, Raf
Regrets: ToddL
Found Scribe: Bri
Inferring ScribeNick: Bri

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