<JakeAbma> scribe: JakeAbma
RM: topics not from the chairs are welcome!
<Rachael> group-ag-chairs@w3.org
<Zakim> JF, you wanted to address that
RM: please add a small summary
JF: +1 for topic requests
RM: chair hat off, most of the time we run out of time already, there needs to be a balance
<alastairc> Introductions and announcements? cap at 5 min?
<JF> +1 to that Alastair
<Rachael> Straw poll: Intro and announcements portion and capping at 5 minutes
<laura> +1
<Detlev> +1 if needed, fine. If not, proceed to next
+1
<JF> +1
<morr4> +1 (echo Detlev)
<Raf> +1
<Sukriti> +`
<Sukriti> +1
<StefanS> +1
<sarahhorton> +1
<JF> (I concur with Detlev)
RESOLUTION: Adjust meeting to add introducation and announcements, no more than 5 minutes
<Rachael> Jake: I am wondering about Silver and the involvement of the broader working group. A lot going on. Decisions are not possible, not enough people working on it. We decided to use part of this meeting for silver. I want to know how we want to deal with it as a group.
<Zakim> JF, you wanted to ask for an agenda item "Life after WCAG 2.2" (where do we go from here?)
JF: what will happen to the group
after WCAG 2.2
... working groups approach, work on XR, etc.
DF: there are a lot of mix and match done in the past for WCAG 2.x and 3.0, we might want / need to see how to proceed
RM: finishing up content usable,
survey by end of the week
... you'll get more than a week, till March 23th
<Rachael> https://raw.githack.com/w3c/coga/consistency_checks/content-usable/index.html
<Rachael> change "the chairs may decide the draft decision" to "the chairs, with consensus of the Working Group, may decide the draft decision"
<Zakim> alastairc, you wanted to mention the doc context
AC: don't think that change is in the update, but there's already a part in the text about overall agreemenet
<JF> https://www.w3.org/2020/Process-20200915/#Consensus
AC: Wilco might not have seen it in the DIFF
<Rachael> Objections from people who raised their concerns to the group during discussions may be given more consideration than objections from people who had opportunity and chose to not participate in those discussions
<Rachael> However, once the chairs issue a Call for Consensus (CfC), objections should not be raised unless the individual strongly believes the decision is the wrong one in spite of discussion, and the individual cannot "live with" the decision. Compromise is an essential part of group decisions. This requires individuals to participate actively in modes of discussion, but "live with" points they consider suboptimal once reaching CfC.
<JF> from the W3C's Process Document: "Dissenters cannot stop a group’s work simply by saying that they cannot live with a decision."
<alastairc> https://www.w3.org/WAI/GL/decision-policy
<JF> Last Minute comments have value too
RM: do we want to take it back and re-word?
JF: Gregg van der Heiden sent a mail after closing, but it was a very valuable insight, we should not sam the door
<Zakim> MichaelC, you wanted to say need to address last minute comments that should have been first minute comments
<Zakim> JF, you wanted to offset Michael's comment with the concern with monoculture
MC: we don't to discard last minute comments, but we really encourage to send early to be not disruptive
<alastairc> E.g. GV's comments on the FPWD are, even late, part of the discussion WAY before the CFC for any publication
JF: we're a small group, and the external comments are important
MC: it's not about externals, it's about internal processes
RM: what to do to have a balance John?
JF: not sure, maybe case by
case
... don't rule it out
<Zakim> alastairc, you wanted to say that if other group members agree with the 'late' objections, that becomes a different thing
AC: if there a logical flaw in a SC right before publishing, we evaluate that one, but if it's not actually related than that is another story
<JF> I note to Mikes' current comment that there is also a Formal Objection process
<Rachael> straw poll: 1) Adopt Mgower's suggested text 2) Use text suggested in survey 3) take it back and rework again
MG: remove some bullets, and re-enforce the process
<alastairc> 2, or 3, I think we still need some time-weighting aspect to encourage participatoin
<Rachael> 3
<mbgower> fine with 1 or 2
<mbgower> or 3 :)
<Detlev> Can live with both 1 and 2
<MichaelC> 3
<david-macdonald> +1
<JF> 0, 1, or 2
<juliette_mcshane> 0
<sarahhorton> 3
<MichaelC> Can´t parse the suggestion live
<laura> 3
<Raf> 0
<Sukriti> 3
<david-macdonald> umuting
<mbgower> thanks for taking this on!
RESOLUTION: Rework this content and bring back.
AWK: still don't really care
MO: can live with Consistent Help
<Rachael> straw poll: Change the name to "Consistent Help"
<mbgower> +1
<morr4> +1
<david-macdonald> +1
+1
<Rachael> +1
<GN015> +1
<juliette_mcshane> +1
<KarenHerr> +1
<alastairc> +1
<laura> +1
<sarahhorton> +1
<Nicaise> +1
<AWK> 0
<JF> +1
<Sukriti> +1
<Detlev> 0
<MelanieP> +1
RESOLUTION: Change name to Consistent Help
MG: I advocate swizzling the text to
MG: proposed text: For each web page within a set of web pages that provides one or more of following ways of finding help, access to those ways of finding help is included in the same relative order on each page:
<Rachael> For each web page within a set of web pages that provides one or more of following ways of finding help, access to those ways of finding help is included in the same relative order on each page: -Human contact details; -Human contact mechanism; -Self-help option; -A fully automated contact mechanism.
<Rachael> From "Access to those ways of finding help is included in the same relative order on each page." to "A method is included in the same relative order on each page to access the help resources."
<alastairc> +1 to "A method is included" approach, it tackles the issue with what you do on the help pages as well.
<Rachael> AWK proposed text: For each web page within a set of web pages that provides one or more of following ways of finding help, a method is included in the same relative order on each page to access the help resources: -Human contact details; -Human contact mechanism; -Self-help option; -A fully automated contact mechanism.
<JF> "... at *least* one"?
AWK: help might be in another context for different pages, do you need to have one or every way needs to meet this SC?
RM: intent from COGA was all need to be in same relative order
<JF> +1 - help can also be contextual
AWK: different pages with different tasks, might have / need context sensitive help in different locations.
RM: if the contextual help is already in the main help, is that sufficient?
<JF> +1 to DMD
DmD: global help and contextual help should be clear for this SC, and if not present already, must be addressed
<Zakim> mbgower, you wanted to say I don't see context-based help being in scope
MG: I don't see contextual help in this SC, it can be handled in the Understanding
<david-macdonald> exception: Task based and contextual help which is specific to the current task or page
JF: not sure if this is clear enough, assuming is not enough that people understand
<mbgower> From start of Intent of Understanding doc: "The intent of this success criterion is to ensure users can find help for completing tasks on a Web site. This is distinct from interface-level help, such as contextual help, features like spell checkers, and instructional text in a form."
<david-macdonald> Current text inunderstanding "The intent of this success criterion is to ensure users can find help for completing tasks on a Web site. This is distinct from interface-level help, such as contextual help, features like spell checkers, and instructional text in a form."
AWK: agree that to be clear in normative text would be preferable
<Zakim> alastairc, you wanted to say that it impacts content pages where you include a link to help
<alastairc> For each web page within a set of web pages that provides one or more of following ways of finding help, a method is included in the same relative order on each page to access the help:
<alastairc> - Human contact details;
<alastairc> - Human contact mechanism;
<alastairc> - Self-help option;
<alastairc> - A fully automated contact mechanism.
AC: not so concerned by contextual help, but I do like the suggestion of AWK
RM: can we add exception for contextual help?
<alastairc> I think the text above would allow for contextual help without an exception
<david-macdonald> exception: Task based and contextual help which is specific to the current task or page
<mbgower> could that be a note?
<AWK> +1 for AC's suggestion.
<JF> +1 to *A* method
<Rachael> For each web page within a set of web pages that provides one or more of following ways of finding help, a method is included in the same relative order on each page to access the help:
<mbgower> +1
<AWK> +1
<stevelee_> +1
<laura> +1
<Rachael> strawpoll: +1 to Alastair's rewording, 0, -1 if something else
<morr4> +1
<Rachael> +1
<Wilco> +1
<david-macdonald> +1
<Sukriti> +1
<Raf> +1
<alastairc> +1 (noting it's combing AWK's and michaelg's)
<JF> "a means to access that help"
<GN015> -1
<AWK> Edit to back half of AC's: access to the help is included in the same relative order on each page:
_1
-1
<AWK> +1
<mbgower> That is a consequence of my rejig, David :(
<AWK> Edit to back half of AC's: access to at least one form of help is included in the same relative order on each page:
<AWK> For each web page within a set of web pages that provides one or more of following ways of finding help, access to at least one form of help is included in the same relative order on each page:
<Sukriti> scribe:Sukriti
<mbgower> +1 that is better aligned with older versions of this SC
<JF> +1 to AWK's proposal
awk: put in an edit above so it's still requiring consistent location but doesn't mean every instance needs to be in the same location
<david-macdonald> we should ensure we link "same relative order" to the definition https://www.w3.org/TR/WCAG21/#dfn-same-relative-order
steve: finding and requesting
help not the same
... doesn't have to be on every page but a link to it
does
... what Andrew said is closer to that idea
<AWK> Jake, here it is: For each web page within a set of web pages that provides one or more of following ways of finding help, access to at least one form of help is included in the same relative order on each page
Jake: The relative order and method is unclear
<mbgower> +1 to say latest wording is better aligned
Gundula: New wording addresses concern
<JakeAbma> +1 to AWK proposal
Rachael: As long as I have the method, it doesn't matter what order it's in. Is that correct?
awk: the goal is to have a way of
help
... everywhere. Is one of them sufficient or is one way
enough
Rachael: contextual help question still unaddressed
<Zakim> mbgower, you wanted to say latest wording is better aligned
<mbgower> https://www.w3.org/WAI/WCAG22/Understanding/findable-help.html
mg: method worked well for me. Is very aligned with currently published wording
<alastairc> JF- method has gone
<Zakim> JF, you wanted to say I'm struggling with the term "method"
mg: after rewording web page/ application related text
jf: looking at this text that mg
just posted, I like that
... don't like the word method
<Rachael> Proposed wording: For each web page within a set of web pages that provides one or more of following ways of finding help, access to at least one form of help is included in the same relative order on each page
jf: the ability to find and get help easily is the goal
<mbgower> +1
<stevelee_> +1
<alastairc> +1
<Rachael> Straw poll: +1 proposed wording 12:06, 0, -1
<jon_avila> We just need to make sure that this can be a link to then get help -that the help doesn't need to directly be on each page.
<david-macdonald> +1
<JakeAbma> +1
+1
<GN015> +0.5
<Detlev> +1
<laura> +1
<juliette_mcshane> +1
<JF> +1 with "Understanding" text that it is similar to the idea of consistent navigation'
<jon_avila> +.5
<MelanieP> +1
<AWK> +1
<Wilco> 0, this is quite a change, would appreciate if we didn't finalise
Rachael: the word "access to" covers link re: jon's concern
<Raf> +1
RESOLUTION: Accept proposed wording: For each web page within a set of web pages that provides one or more of following ways of finding help, access to at least one form of help is included in the same relative order on each page
<Rachael> Findable Help - Goal of Criterion Ambiguous #1435
<alastairc> https://www.w3.org/2002/09/wbs/35422/wcag22-findable-help-updates/results#xq10
<alastairc> Draft response: https://github.com/w3c/wcag/issues/1435#issuecomment-790980650
Rachael: is it requiring help be required, or it be available in the same relative order?
Gundula: the understanding document wording might need to be adjusted
<mbgower> Web site was used in the prior version as well, then new comments use it again.
Gundula: locating the way of
finding help
... second point about website
... might be very large
... should it say set of web pages here as well
<mbgower> yep
Gundula: third point. success criteria editorial update
<Rachael> Changing web site to web pages or set of web pages and pluralizing Success Critieria
<Zakim> JF, you wanted to discuss "set of web pages" - should it be expanded to include other environments ('apps', XR, etc.)
jf: too restrictive when we say
set of web pages
... what about xr and apps
Rachael: wcag 3 and ICT
<alastairc> We are working in 2.x, we have to use the definitions we have.
jf: worried we're creating sc won't be future proof
<mbgower> Rachael, also watch out for consistency "Web site" versus "websites"
Alastair: at this stage, need to work within the definitions set for wcag 2.x
<Rachael> Draft resolution: Accept response and pull request with discussed revisions
+1
<sarahhorton> +1
<mbgower> +1
<Detlev> +1
<morr4> +1
<Raf> +1
<JF> +.5
<JakeAbma> +1
<GN015> +1
<StefanS> +1
<laura> +1
<david-macdonald> +1
RESOLUTION: Accept response and pull request with discussed revisions
<Rachael> https://github.com/w3c/wcag/issues/1448#issuecomment-770913639
<Rachael> Suggestion: I think the response should state up top that changes to the SC normative text have been made since the issue was opened, that address some of the concerns, and the ticket owner should review.
<Rachael> Draft RESOLUTION: Accept the response along with text from mgower
<JF> +1
<mbgower> +1
<Rachael> +1
<sarahhorton> +1
<morr4> +1
<Wilco> +1
+1
<GN015> +1
<JakeAbma> +1
<MelanieP> +1
<david-macdonald> +1
<laura> +1
<Detlev> +1
RESOLUTION: Accept the response along with text from mgower
<Raf> +1
<Rachael> https://github.com/w3c/wcag/pull/1667/files
wilco: seems unnecessary to me. Spacing already covered in the definition target
<Zakim> mbgower, you wanted to say I'm still worried
wilco: explaining in understanding document is more than enough
mg: I wanted people to imagine a
calendar input entry
... widget has a month calendar with every date a focusable
control
... at what point is it going to be clear to a developer
... whether it is an input
... hard to say when something is a target that needs to meet a
requirement
davidM: a serialized region definition. Visual distinction between the different value selection points. eg. color picker
Detlev: For the calendar widget, conforming alternative version as a text input field
<david-macdonald> Serialized region: The containing component allows values to be chosen from a serialized region.
Detlev: in most implementation
<jon_avila> An input field is not equivalent as it doesn't provide context of day of week, etc.
<david-macdonald> Dfn of Serialized region A region of a component that allows for values to be selected sequentially based on position in the region (serialized) and where there is no explicit visual separation or division between the focusable target areas of the region.
<mbgower> But do you think a calendar IS a continuous region? I don't
Detlev: which is why wouldn't need an exception for that case
jon: alternative doesn't seem equivalent
Rachael: two questions - what
exactly is a continuous region. Whether equivalent version is
enough
... understanding document is going to need to address it
mg: don't think calendars should
be in scope
... as a continuous region
... it's a set of points, each of which should have 24X24
Rachael: does anyone think it should be exempt
<GN015> +1 to Detlev
detlev: not sure how big the
calendar would get
... the entire continuous region is one pointer
Rachael: what should be exempt, can we think of examples
alastair: range selector. Slider
wouldn't be exempt but the individual values. That could be 1
px in color pickers for example
... where you have that scenario, it is one target but the
actual value you select is tiny
... maybe best off having a note
<mbgower> Maybe we can include them under "essential" and list them in the Understanding document?
<Detlev> I put a paragraph about continuous regions in my second PR
<alastairc> how big would a "gradient color picker" be if all the values were 24x24px?
davidm: serialized definition would solve it for me
wilco: context dependent
alastair: maybe we can include them in essential and add a note in the understanding document
<mbgower> I'm not super happy with any of this! Maybe David's will get us there?
davidm: looking at the dfn again, what is a pointer action
<Detlev> we are adressing target SIZE not action!
Gundula: slider or color picker,
the thing I need to touch to work with it should be large
enough
... not the actual value
Detlev: the slider itself would
have to be 24X24
... different ways of selecting a value, if you have an
alternative
... should be okay
<Zakim> mbgower, you wanted to say that choosing a specific color from a palette or a value from a slider CAN be important
mg: concern is that I would like to get specific value from the slider
<alastairc> Suggested note: Targets which allow for values to be selected spatially based on position within the target are considered one target for the purpose of the success criterion. Examples of these components include sliders with granular values, colour pickers displaying a gradient of colours, or editable documents where you position the cursor.
mg: where do we draw the line
Alastair: maybe add a note
<Detlev> +1 to that text
<mbgower> I can live with Alastair's wording. Just concerned
<Rachael> strawpoll: 1) adopt suggested note 2) move to understanding 3) other
<Wilco> 1
<Detlev> 1
<johnkirkwood> 1
<david-macdonald> can live with 1
<JF> 1
<KarenHerr> 1
<sarahhorton> 1
<Rachael> 1
<GN015> 2
1
<laura> 1
<MelanieP> 1
<jon_avila> 1
<AWK> 1
<morr4> 1
<mbgower> 1 (maybe ask for input, if there is another WD?)
<jon_avila> I'd note in some context like a calendar you can make a different selection without a focus or context change - while other things like buttons cause context changes. So there is often a way to undue or repeat the action more easily.
alastair: can add another note asking for feedback
jonA: cancel an action after you
do it. With some controls when you click the wrong thing, it
can have serious consequences. In the calendar case, you can
try again
... they are not equal in terms of what happens when you pick
the wrong value
... point of consideration in explaining our rationale
Wilco: the explanation is that you still need keyboard accessibility, which addresses the precise value concern
Rachael: are we comfortable with the wording?
davidM: in the note, putting in visual distinction point
mg: "that", not "which"
<david-macdonald> friendly amendment to note. Targets which allow for values to be selected spatially based on position within the target where there is no explicit visual separation or division between the different value areas are considered one target for the purpose of the success criterion. Examples of these components include sliders with granular values, colour pickers displaying a gradient of colours, or editable documents where you position [CUT]
awk: in the second sentence, it touched on these components - sounds strange
<Rachael> Targets that allow for values to be selected spatially based on position within the target where there is no explicit visual separation or division between the different value areas are considered one target for the purpose of the success criterion. Examples of these components include sliders with granular values, colour pickers displaying a gradient of colours, or editable documents where you position.
<alastairc> Note: Targets that allow for values to be selected spatially based on position within the target are considered one target for the purpose of the success criterion. Examples include sliders with granular values, colour pickers displaying a gradient of colours, or editable documents where you position the cursor.
<Rachael> Targets that allow for values to be selected spatially based on position within the target where there is no explicit visual separation or division between the different value areas are considered one target for the purpose of the success criterion. Examples include sliders with granular values, color pickers displaying a gradient of colours, or editable documents where you position.
<AWK> +AWK
Gundula: editable documents and cursors
<alastairc> Note: Targets that allow for values to be selected spatially based on position within the target are considered one target for the purpose of the success criterion. Examples include sliders with granular values, color pickers displaying a gradient of colors, or editable areas where you position the cursor.
<david-macdonald> * alastairc It seems so to me. otherwise a date picker might qualify
alastair: re: add the visual aspect of it - probably should keep in general
<david-macdonald> can live with that
<Rachael> Draft resolution: Accept adding a note instead of an exception. Wording above.
<Detlev> +1
+1
<sarahhorton> +1
<david-macdonald> +1
<Rachael> +1
<alastairc> +1
<Wilco> +1
<mbgower> capitalize Success Criterion
<mbgower> +1
<GN015> +0.5
RESOLUTION: Accept adding a note instead of an exception. Wording above.
<Rachael> https://github.com/w3c/wcag/pull/1666/files
<JF> I'm with Mike - support is not the right term I don't think
<Rachael> Draft RESOLUTION: Do not include exception for equivalent functions
<Detlev> +1
<sarahhorton> +1
<Wilco> +1
<morr4> +1
<mbgower> 0
+1
<jon_avila> +0
<alastairc> +1, make a note for the understanding doc...
<laura> +1
<GN015> -0.1 clarify in understanding
RESOLUTION: Do not include an exception for equialent functions but address in understanding
<mbgower> +1
<JF> +1 to alastair
RESOLUTION: Do not include an exception for equialent functions but address in understanding
<Rachael> Rename the new SC to Target Size (Minimum); Rename 2.5.5 Target Size (Enhanced)
<Zakim> alastairc, you wanted to speak to Andrew's comment
<Detlev> :)
<Rachael> Draft RESOLUTION: Accept name change
<alastairc> +1
RESOLUTION: Rename the new SC to Target Size (Minimum); Rename 2.5.5 Target Size (Enhanced)
<Wilco> +1
<Rachael> +1
<sarahhorton> +1
<Detlev> +1
<mbgower> +1
<JF> +1
<johnkirkwood> +1
<morr4> +1
<GN015> +1
<Francis_Storr> +1
+1
<KarenHerr> +1
<MelanieP> +1
I got too excited there
RESOLUTION: Rename the new SC to Target Size (Minimum); Rename 2.5.5 Target Size (Enhanced)
<alastairc> EU folks, it's an hour early next week...
<johnkirkwood> ;)
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/?me normative text// Succeeded: s/Corruent/Current/ Default Present: JakeAbma, Rachael, alastairc, MichaelC, Fazio, Raf, Sukriti, JF, stevelee_, Detlev, Laura_Carlson, Matt, Orr, sarahhorton, GN, StefanS, `, Caryn, Nicaise, MelanieP, KarenHerr, mbgower, Wilco, david-macdonald, jon_avila, .5, kirkwood, AWK, Francis_Storr, johnkirkwood Present: JakeAbma, Rachael, alastairc, MichaelC, Fazio, Raf, Sukriti, JF, stevelee_, Detlev, Laura_Carlson, Matt Orr, sarahhorton, GN015, StefanS, Caryn, Nicaise, MelanieP, KarenHerr, mbgower, Wilco, david-macdonald, jon_avila, kirkwood, Francis_Storr, johnkirkwood Regrets: Charles H, Ben T, Rain M, Andrew K, Chris L, Jemma, Chuck A Found Scribe: JakeAbma Inferring ScribeNick: JakeAbma Found Scribe: Sukriti Inferring ScribeNick: Sukriti Scribes: JakeAbma, Sukriti ScribeNicks: JakeAbma, Sukriti 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]