<laura> scribe: laura
<Rachael> akc dan
RM: Any new members?
... Any new topics?
Dan: I cahnged affilfiations.
RM: no announcements.
Shadi: We met yesterday but not
he week before. Making slow progress. Reviewing use
cases.
... a lot of holidays in our schedule. May want to
extend.
... on june 20 we will have a presentation.
<shadi> https://github.com/w3c/silver/wiki/Guidance-for-policy-makers-Subgroup
chuck: need to discuss extension. What do the members want.
Shadi: I will ask the
group.
... no objections were raised.
<Rachael> Github diff version https://github.com/w3c/wcag/pull/3224/files
Rachael: Decision policy changes is the main topic today.
<Rachael> Proposed Changes to Decision Policy (google doc with track changes) https://docs.google.com/document/d/14ZaniCG35xG9QjCaSLvjHdm7XOIrZNuTp3HRHHr64tc/edit#heading=h.iyc7rgx06mdq
Rachael: we are at a transition
point.
... would like it to be a new start.
... had concerns on charter regarding policy.
... worth considering defaulting to w3c policy.
Rachael: should we have a custom policy?
<Rachael> Process Consensus section https://www.w3.org/Consortium/Process/#Consensus
chuck: it is an option that we didn't consider before we put together the survey.
jeanne: I voted for using the w3c
policy.
... believe in that process. It works well.
... I am a believer in it.
... I like the maturity levels in the document. It would
accelerate the work.
... Our current process may tie our hands.
<Rachael> Quick note: We have some content at developing
<kirkwood> +1 to Jeanne. Similar concerns regarding changing decision policy. use maturity levels as well
jeanne: Can have the best of both worlds.
wilco: I didn't know this was an option. Would like time to review.
<jeanne> Wilco, there is no conflict -- we can use the maturity levels, just not make them the formal decision policy
Rachael: would like to avoid "this group is special" converrsations.
<Zakim> alastairc, you wanted to comment on the likely impact
AC: Our policy was based on w3c
policy.
... it changes with earlier stages.
<bruce_bailey> +1 from Jeanne's argument that we could try using W3C decision policy
AC: some of the changes are nudging us back to w3c policy.
<Zakim> Chuck, you wanted to say I don't see the maturity levels and the decision policy being in conflict.
chuck: no contention with I was going to say.
wendy: I think we should align
with w3c policy.
... It has a maturity level built into it already.
... The closer we can get to w3c policy the better.
<bruce_bailey> +1 to Wendy that simplification of processes is a plus
Ben: decision by vote org has 1 vote.
<Zakim> bruce_bailey, you wanted to ask chairs if tension between maturity levels and using default w3c decision policy ?
Ben: would be massive over head.
<Zakim> alastairc, you wanted to say decisions on what content to publish are not restrictive of labels / notes we add to that content. and to also say that the number of org votes has
bruce: I like good work that has gone on to our policy. Not understanding the tenson.
ac: Maturity levels are basically
lables.
... we would be approving the labels. Doesn't impact the
policy.
... maturity levels have been helpful.
... org votes have always been the case.
Shadi: agree with simplifying the
process.
... maturity levels is something separate.
<Rachael> +1 to separate discussions
<Zakim> Chuck, you wanted to say We've been addressing that issue already (multiple votes from one org).
chuck: 1 org vote is nothing new.
<Zakim> Rachael, you wanted to say we've worked our way back to being close to the process
chuck: when we get to CFC we roll into a single vote. No more overhead for Chairs.
Rachael: separating maturity
levels out would make it easier.
... Many agreed with updates.
... If we went with w3c policy what would we lose.
<kirkwood> And it makes it easier for policymakers (labeling maturity)
wilco: haven't had time to review this. Would like time to review this. Process doc was updated yesterday.
Rachael: wasn't something called out for people to read.
chuck: this content has been there. But the question is a new one.
<jeanne> Chuck, the W3C Process doc was published yesterday
chuck: the possibility is the option.
<Rachael> https://www.w3.org/2023/Process-20230612/
chuck: does anyone else have concerns?
ac: we could put this off one
week.
... what would people miss out on if we go with the w3c
policy?
Rachael: Chairs will craft a new survey for next week.
chuck: we will need to go to legacy survey policy. Will need to rust this through.
Shadi: People have noted how much time we have been spending. Could we make a tentative decision?
<Zakim> bruce_bailey, you wanted to ask if there is a github diff?
JohnK: ability to label and communications is very good.
Bruce: could we get a diff?
<kirkwood> +1 to Bruce
<shadi> https://www.w3.org/2023/Process-20230612/#changes
Rachael: Will think about that.
<Zakim> Chuck, you wanted to offer a suggestion
<bruce_bailey> Thanks @shadi, it was the diff from November I was looking for -- and the link is there
Chuck: perhaps a poll on if we should explore w3c policy.
<jeanne> Diff of the Consensus section https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2021%2FProcess-20211102%2F&doc2=https%3A%2F%2Fwww.w3.org%2F2023%2FProcess-20230612%2F#consensus-building
wilco: feeling whiplash. not
prepared for this conversation.
... nothing about CFC process.
... will we go back to every stage has a decision?
... nothing on durations??
<Zakim> alastairc, you wanted to comment on the CFC aspect and maturity levels
Lori: w3c Process doc is huge. Which part are we following?
RM: The consensus part.
<alastairc> https://www.w3.org/2023/05/media-wg-charter.html#decisions
<Chuck> proposed poll (not final a decision): 1) Support using W3C decision process, 2) Support exploring the W3C decision process, 3) Support the proposed changes to the custom decision process, 4) Support neither the W3C decision process nor the proposed custom process
ac: we would have a little part in the charter about CFCs.
<Wilco> Can we get that text then?
<bruce_bailey> In w3c process doc, section 5.2 is Consensus Building
<Rachael> Straw poll: 1) Explore default to the W3C process (Chairs will bring proposal back for discussion) 2) Discuss defaulting further next week before looking at a proposal 2) Keep custom decision policy 3) something else
<Rachael> Straw poll: 1) Explore default to the W3C process (Chairs will bring proposal back for discussion) 2) Discuss defaulting further next week before looking at a proposal 3) Keep custom decision policy 4) something else
<shadi> 1
<tzviya> 1
<Chuck> 1
<jeanne> 1
<alastairc> 1
<Rachael> 1
<corey_hinshaw> 1
<Poornima> 1
<iankersey> 1
<Jaunita_george> 1
<maryjom> 1
<Makoto> 1
<bruce_bailey> 1
<kirkwood> 1
<sarahhorton> 1
<dan_bjorge> 1
<Ben_Tillyer> 1 *no harm in exploring?
<GN015> 1 or 2
<Wilco> No concern
<alastairc> It's a continuation, should be ok
<Jaunita_george> 1
<corey_hinshaw> But, to Wilco's point, it would be helpful to have the full context of the proposed process including charter updates, etc.
Rachael: anyone concerned about expiditted shedule?
<Rachael> Draft RESOLUTION: Further explore moving to the default W3C process next week
<Chuck> +1
<tzviya> +1
<jeanne> +1
<Ben_Tillyer> +1
<ChrisLoiselle> +1
<alastairc> +1
<sarahhorton> +1
<Wilco> 0
<LoriO> +1
<shadi> +1
<mgarrish> +1
<iankersey> +1
<bruce_bailey> +1
<corey_hinshaw> +1
<kirkwood> +1
<maryjom> +1
<Poornima> +1
<Jaunita_george> +1
<dan_bjorge> +1
<Makoto> +1
<alyssa_priddy> +1
<GN015> +1
RESOLUTION: Further explore moving to the default W3C process next week
RESOLUTION: Further explore moving to the default W3C process next week
ac: In Issue 2433 Jake raised that C42 works for the previous target-size SC, but not the new one.
Frances created PR 3231 to update the technique, with an overview in the PR description.
<Rachael> https://github.com/w3c/wcag/issues/2433
<Rachael> https://github.com/w3c/wcag/pull/3231/files
scribe: It has a double procedure
RM: Reads comments.
Wilco: I find it quite confusing that this technique mixes the 24x24 requirement with the 44x44 requirement. I don't think we should put these two measures in the same technique.
<Zakim> alastairc, you wanted to comment on separating
Wilco: Don't think we have done that for other techniques.
ac: we do have another one that does this.
<Wilco> https://www.w3.org/WAI/WCAG21/Techniques/general/G17 4.5:1 https://www.w3.org/WAI/WCAG21/Techniques/general/G18 7:1
ac: we talked about it .
... "space around it" needs to be tweaked.
dan: agree wiith wilco.
... split them into 2 techiques.
<Rachael> draft RESOLUTION: Separate PR#3231 into two techniques and bring back for review.
<Wilco> me too, sorry Francis
<Ben_Tillyer> +1
<LoriO> 0
<dan_bjorge> +1
<garcialo> 1
Laura: +1
<corey_hinshaw> +1
<bruce_bailey> +1
<GN015> 0
<Wilco> +1
<Jaunita_george> +1
<alyssa_priddy> +1
<garcialo> +1
<Chuck> +1
<alastairc> 0, I was split, so apologies to Frances for not predicting the direct the group would go!
<Makoto> +1
<iankersey> +1
<ChrisLoiselle> +1
RESOLUTION: Separate PR#3231 into two techniques and bring back for review.
<mikeGower> +1
<mikeGower> Present mbgower
<Rachael> https://github.com/w3c/wcag/pull/3191/files
AC: Michael Gower has continued to work on the 'in brief' sections, in PR 3191, after our previous round of feedback.
We think the previous comments have been addressed.
ac: ... eo would like to use them.
mike: 2 main request. Wants to
remove key beneiiary.
... EO want sto expand on it.
... other one is merging first 2 into one.
... useful to have a coinsistant version.
... could publish as is.
... When would adjust thae language.
... take out 3rd line.
ac: eo made other suggestions.
mg: tried to leave things as suggestions.
<GN015> I feel placing the in-brief sections above the SC itself makes them being perceived as normative. People reading only a bit will consume only the in-brief section and memorize thatone. But they are simplified (on intention).
<Rachael> draft RESOLUTION: Publish without the key beneficiaries and with the editorial changes suggested in the survey and then revisit with EO in the future.
mg: ac: agree to merge as is. Key
benfitaries we be removed.
... affer improve with eo's suggestions.
<Rachael> draft RESOLUTION: Publish without the key beneficiaries and with the editorial changes suggested in the survey and then revisit with EO in the future.
<kirkwood> +1
<bruce_bailey> +1
<Wilco> +1
<corey_hinshaw> +1
<mikeGower> +1
<Rachael> +1
Laura: +1
<shadi> +1
<garcialo> +1
<GN015> -1 as for Reflow the in-brief differs substantially from the normative text
<LoriO> 1+
<alastairc> +1
<Makoto> +1
<dan_bjorge> -.5, prefer keeping key beneficiaries, but can accept without
<Raf> +1
<Ben_Tillyer> 0 due to not having time to look at GN015's comment
RM: reads GN's comments.
<GN015> I think the SC on Reflow needs deeper clarification.
mg: Testing has caused massive
problems.
... could use resize without horizonttal scolling.
<Zakim> Chuck, you wanted to say we need a scribe change
ac: this bit is not notmattive. Don't think it is a blocker.
<GN015> The in-brief is not mormative, yet there exist numerous discussions on how to understand the SC, basing on the different sections of the understanding as well as the texts in the techniques.
<alastairc> GN015 - So matching the intent should be ok?
<ChrisLoiselle> scribe: ChrisLoiselle
RM: Gundula notes are read. RM asks Gundula to propose larger issue
Wilco: Can we vote on Gundula's comment suggestion?
<alastairc> “Content can be perceived on a small viewport without requiring horizontal scrolling.”
RM: Content perceived on small viewport discussion?
Wilco: Yes.
<alastairc> VS "ontent can be enlarged without requiring horizontal scrolling"
<Rachael> strawpoll: 1) content can be enlarged without requiring horizontal scrolling 2) Content can be perceived on a small viewport without requiring horizontal scrolling
<mikeGower> 1
<Wilco> 2
<LoriO> 1
<corey_hinshaw> 1
<Jaunita_george> 1
<alastairc> 1
<bruce_bailey> +1
<alyssa_priddy> 1
<garcialo> 1
<laura> 1
<dan_bjorge> 1
<Makoto> 1
<GN015> 2 (limiting one dimension only)
<Chuck> 11 1's and 2 2's
<Raf> 1
RM: Current language as proposed seems to have preference.
<alastairc> I'd also note that getting these objectives within 10 words is always going to be tricky and imperfect.
RM: To Dan's concern, is it just the time concern on EO?
Dan: I was just concerned on why they'd leave to come back in.
AlastairC: EO has persona quotes that may be good in benefits section. Overlap between beneficiary and benefits text . To include aspect in benefit section and include persona quote in benefits section
Dan: Snippet of summary vs. not in expanded section for beneficiaries.
<Zakim> bruce_bailey, you wanted to discuss Gundalla [(2) in poll] be additional sentence.
Bruce: I like Gundala's suggestion, just not as a replacement.
<Rachael> Content can be enlarged or perceived on a small viewport without requiring horizontal scrolling
<garcialo> +1 on "including, but not replacing"
Shadi: To Dan's question, on EO
discussion, some of these proposals were discussed.
... summarizing beneficiaries removed and over simplified.
<alastairc> Good point, that's Shadi.
<alastairc> arg, "thanks Shadi"
<Rachael> Straw poll: 1) Remove beneficiaries or 2) keep beneficiaries
<mikeGower> 1
<alastairc> 1
<laura> 1
<GN015> 2 can live with 1
RM: publish and revisiting will happen by EO
<bruce_bailey> 0
<Rachael> 2 can live with 1
<dan_bjorge> 2 can live with 1
<corey_hinshaw> 0
<LoriO> 1
<alyssa_priddy> 0
<Makoto> 0
<garcialo> 0
<shadi> 1
<Chuck> 4 1's, 3 2's, 5 0's
<Jaunita_george> 1
<Chuck> 6 1's, 3 2's, 5 0's
Shadi: It will still exist in doc.
<bruce_bailey> happy to see where EO goes with this
Bruce: That was my question, it will be kept in the doc. So as long as it is showcasing how it helps people with disabilities.
<alyssa_priddy> no opinion
<corey_hinshaw> I have no opinion
<bruce_bailey> my 0 because i was not clear on poll
Chuck: Were zeros I like neither option?
Bruce: 0 as not clear on poll.
<bruce_bailey> now i think i am a 2
Bruce: Now I'm a 2.
MikeG: I will give a background
comment. On beneficiary terminology. Moving away from abstract
is hard to do.
... Understanding document conversations are what am I supposed
to do vs. the why per EO. EO tends to provide use cases
etc.
... seems to fit better. Consuming two points vs. three in in
brief section is also beneficial.
<corey_hinshaw> Mike's point here is why I have no opinion on keeping or removing from the summary - the key points in the summary IMO are, What does the SC require? and How do I accomplish that?
AlastairC: I'd request people
review the beneficiaries and understand how to summarize how it
briefly impacts those users.
... it is in brief , it is better done more extensively in
benefits section.
Dan: I believe Bruce mentioned, does this help a person with a disability. I agree with that. I think you can use example beneficiary vs. the entire class of beneficiaries. TLDR summary on x, y, z.
RM: Goes to the rework on EO.
<Rachael> Straw poll: 1) Remove beneficiaries in the in brief section or 2) keep beneficiaries in the brief section 3) no strong opinion 4) unhappy with all options
RM: recommends one more straw poll on beneficiaries topic.
?
<garcialo> 1
<bruce_bailey> 1
<alyssa_priddy> 3
<mikeGower> 1
<alastairc> 1, but not very strong opinion
<LoriO> 1
<corey_hinshaw> 3
3
<shadi> 1
<laura> 1
<Wilco> 5: Happy with all options
<Raf> 3
<Makoto> 3
<GN015> 2, can live with 1, can live with comes out of 4 (revisit, I think)
<Jaunita_george> 1 or 3
<dan_bjorge> 3
<mikeGower> Yes. Many versions. Unhappy with all
<Rachael> strawpoll: 1) content can be enlarged without requiring horizontal scrolling 2) Content can be perceived on a small viewport without requiring horizontal scrolling 3) Content can be enlarged or perceived on a small viewport without requiring horizontal scrolling
<Chuck> 8 1's, 1 2's, 6 3's, 0 4's, 1 friggin 5
<laura> s/converrsations /conversations /
<bruce_bailey> -1
<bruce_bailey> q
RM: On horizontal scrolling topic Bruce do you have questions?
Bruce, yes.
<Rachael> strawpoll: 1) content can be enlarged without requiring horizontal scrolling 2) Content can be perceived on a small viewport without requiring horizontal scrolling 3) both sentences
<alyssa_priddy> 1
<LoriO> 1
<bruce_bailey> 3
<mikeGower> 1 strongly
<corey_hinshaw> 1
<Jaunita_george> 1
<GN015> 2, strong on it
<garcialo> 3
<mikeGower> Or rather strongly not 3
<dan_bjorge> 1
<Wilco> 2
<laura> 1
<alastairc> 1. Also note that Mike's been trying to keep them to 10 words... and definitely not 2 sentences!
<Makoto> 1
<Raf> 1
<Chuck> 9 1's, 1 2's, 1 3
<bruce_bailey> 1 if this is "in brief" portion ?
<alyssa_priddy> +1 to <alastairc> comment
RM: Gathering the data on draft resolution.
<GN015> There were 2 2's if I count correctly
<Rachael> draft RESOLUTION: Publish without the key beneficiaries, with the editorial changes suggested in the survey and keep existing wording on "enlarging". Put in ticket to improve understanding document. Revisit briefs with EO in the future.
Bruce: Is this in the in brief section?
RM: Yes, just in the in brief.
<alastairc> Bruce - yes, in brief section. Feel free to do a PR...
Bruce: The comment on viewport is valuable
<LoriO> Chris: why is viewport important?
<Rachael> draft RESOLUTION: Publish without the key beneficiaries, with the editorial changes suggested in the survey and keep existing wording on "enlarging". Put in ticket to improve understanding document to include small viewports and other clarirication. Revisit briefs with EO in the future.
RM: Reads proposed resolution
Lori: Why is small viewport so important?
<GN015> The normative text talks about restricting the viewport in only one dimension.
Lori: why is size of viewport important?
<GN015> Resizing implies or is euivalent to restricting both dimensions at the same time.
<laura> s/lables. /labels. /
Wilco: isn't about just enlarging , it is fitting on larger or smaller screens , i.e. low resolution not resizing.
<bruce_bailey> +1 to wilco explanation
Wilco: it has the resolution numbers in it.
<GN015> Further down the normative text allows that by zooming 400% the text may restrict to enlarging only 200%. Yet this might yield an irritating behavior on zoom.
Alastair: To Wilco's point, it is what it became when we had to make it testable, vs. the intent.
<mikeGower> I'll keep poking at this one.
<dan_bjorge> imo: Making text fit within the width of a small viewport is what the author has to do to support the intent (and that's already reflected in the author task). The *intent* is to enable users to enlarge content.
Alastair: having the objective relate to that. The in brief comes in to play and matches intent. I believe it is worth being different.
<Rachael> draft RESOLUTION: Publish without the key beneficiaries, with the editorial changes suggested in the survey. Keep existing wording on "enlarging". Put in ticket to improve understanding document to include small viewports and other clarirication. Revisit briefs with EO in the future.
<shadi> +1 to draft resolution
RM: Asks to have a vote on resolution draft.
<mikeGower> +1
<corey_hinshaw> +1
<Rachael> +1
<Wilco> +.8
<alastairc> +1
<bruce_bailey> +1
<dan_bjorge> +1
<laura> +1
+1
<garcialo> +1
<Jaunita_george> +1
<alyssa_priddy> +1
<Makoto> +1
:)
<Zakim> Chuck, you wanted to ask about the 5 minutes left
<mikeGower> Thanks for support. I'll continue to work on then
<GN015> Pardon, what should I add?
RESOLUTION: Publish without the key beneficiaries, with the editorial changes suggested in the survey. Keep existing wording on "enlarging". Put in ticket to improve understanding document to include small viewports and other clarification. Revisit briefs with EO in the future.
<laura> s/separting matuiry /separating maturity /
Bruce: I can wait to end of call.
AlastairC: Visited link color topic. Most people agreed with the update. Opens to Wilco's comment on color contrast links being exempt?
<corey_hinshaw> This is for Use of Color, not Contrast
AlastairC: We weren't trying to say that. Blue vs. Purple and use of color holding people at fault if it is up to browser. Wasn't sure where that update was?
<bruce_bailey> How easy is it to misread?
Wilco: I will review again and talk to it next week.
<GN015> btw: white to blue to purple to black each 3.0:1 is mathematically impossible
Bruce: Suggestions on question 6 , I did a PR on my PR .
RM: We can resurvey it if you'd like.
Bruce: i've taken in the comments on the PR. I've created a new PR to update the old.
AlastairC: I will update the survey
<bruce_bailey> @alsaster PR is in my survey response
<garcialo> thanks for the reminder :)
<alastairc> bruce_bailey - ah, thanks
<laura> s/expiditted shedule /expedited schedule /
<bruce_bailey> https://github.com/w3c/wcag/pull/3240/files
<GN015> You're welcome!
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/separting matuiry/separating maturity/ Succeeded: s/butt nott/but not/ Succeeded: s/schdule/schedule/ Succeeded: s/disccus extention/discuss extension/ Succeeded: s/tthe /the / Succeeded: s/rasised./raised./ Succeeded: s/maturrity /maturity levels / Succeeded: s/excellorrate /accelerate / Succeeded: s/decisioin /decision / FAILED: s/converrsations /conversations / Succeeded: s/ourr policy /Our policy / Succeeded: s/matuity /maturity / Succeeded: s/matuiry /Maturity / Succeeded: s/lables./labels./ Succeeded: s/apprroving /approving / FAILED: s/lables. /labels. / Succeeded: s/agrree with simplifing /agree with simplifying the / Succeeded: s/asingle /a single / Succeeded: s/Non more /No more / Succeeded: s/ charis./ Chairs./ FAILED: s/separting matuiry /separating maturity / Succeeded: s/agreeed /agreed / Succeeded: s/ decsion/ decision/ Succeeded: s/ desicion/ decision/ Succeeded: s/ notthing on diurations/ nothing on durations?/ Succeeded: s/Whidh pare /Which part / Succeeded: s/concensus /The consensus / FAILED: s/expiditted shedule /expedited schedule / Succeeded: s/rreads/Reads/ Succeeded: s/taked/talked/ Default Present: Laura_Carlson, JustineP, shadi, dan_bjorge, Wilco, corey_hinshaw, bruce_bailey, alastairc, Jaunita_george, ChrisLoiselle, jeanne, MichaelC, Makoto, sarahhorton, kirkwood, Poornima, iankersey, mgarrish, Raf, Ben_Tillyer, maryjom, wendyreid, LoriO, Francis_Storr, .8, garcialo, GN, mbgower Present: Laura_Carlson, JustineP, shadi, dan_bjorge, Wilco, corey_hinshaw, bruce_bailey, alastairc, Jaunita_george, ChrisLoiselle, jeanne, MichaelC, Makoto, sarahhorton, kirkwood, Poornima, iankersey, mgarrish, Raf, Ben_Tillyer, maryjom, wendyreid, LoriO, Francis_Storr, .8, garcialo, GN, mbgower, GN015 Found Scribe: laura Inferring ScribeNick: laura Found Scribe: ChrisLoiselle Inferring ScribeNick: ChrisLoiselle Scribes: laura, ChrisLoiselle ScribeNicks: laura, ChrisLoiselle 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.)[End of scribe.perl diagnostic output]