<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
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
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
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?
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
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!
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
<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.)[End of scribe.perl diagnostic output]