<laura_> Scribe: Laura
<scribe> Scribe: Laura
ac: anyone new?
ac: I’ll take silence as a no
<alastairc> https://github.com/w3c/silver/pull/262/files
ac: update for coga TF.
... multiple ways to measure update.
... Nicaise was the first respondent.” Original wording to be a
bit easier to understand and not cumbersome . “
... pit that one aside for now.
... wilco “I take it the first version of this is the previous
one, and the second is the new one? Why did this change from
"WCAG 3.0 guidance" to "Silver guidance”?”
<Chuck> +1 to update to WCAG 3.0
<AWK> +1 to say that removal of "so that results can be verified" is a problem
ac: bruce “I would note that I
think the first paragraph should be "All WCAG 3.0
***Guidelines*** have..." (instead of "All WCAG 3.0 guidance
has..." “
... note sure if it is the same.
wilco: think that was intentional.
<Sukriti> +1 to wilco
<Sukriti> I was there too
wilco: it was intentional.
ac: yes it was intentional.
... Sukriti had a reasonable suggestion.
... make it more stand alone.
<alastairc> delete "so that more needs of people with disabilities may be included" - Sukriti
ac: delete "so that more needs of people with disabilities may be included" - Sukriti
wilco: think if we change this there may be others to change.
ac: male it more concise.
Sukriti: just a small suggestion. Not a big deal.
Detlev: could be boiled down.
ac: 1st paragraph is being
replaced by the second.
... Sarah “Change “Silver guidance” to “WCAG 3.0
guidance”.”
... yes.
... Cybele said “Agree because testing should help us move
towards the goal of greater accessibility and not be used to
curtail accessibility. "And others" should also be added to
types of disabilities, although "such as" may be ok (should be
discussed, about who is still left out).”
... not sure how it could work grammatically.
chuck: don’t think it is a big hangup.
ac: awk’s “Concerned about
removal of "so that results can be verified”"
... he is also concerned about “Also concerned about "includes
particular attention to people whose needs may better be met
with a broad testing strategy" - how does the guidance include
"particular" attention? Is it neglecting other group or is it
not particular attention, just more than what was in the
past.”
... THis seems a significant change from "multiple ways to
measure"
... spelling out what broader /ways would get us./
awk: this is requirement to say
that we are done.
... worry if top level requirement broad support. How do we
determine that we are done.
<scribe> … new language needs to say what the particulars are.
ac: it wraps together for me.
awk: could end in never ending arguments.
ac: could change the
heading.
... middle bits ok.
... greater coverage or such for last section.
detlev: "All WCAG 3.0 guidance has tests or procedures so that the results can be verified. Some of this guidance uses true/false verification. In addition, WCAG 3.0 guidance includes other methods of measuring (for example, rubrics, sliding scale, task-completion, user research with people with disabilities, and more). This approach accommodates people whose needs are better reflected by a broad testing strategy, such as people with low vision, limite[CUT]
or cognitive and learning disabilities."
scribe: prefer my text. but could live with the other.
awk: coga is proposing to support
a wider group. not sure what the gap was.
... not sure where that doesn’t happen.
ac: coga aim to have it part of
the document.
... appreciate where they want it part of the
requirements.
... suggest we take detlev’s suggestion. and some notes.
RESOLUTION: Take Detlev's proposal back, request comment from people who requested the change.
ac: next one is AG decision policy update
<alastairc> https://github.com/w3c/wcag/pull/1596/files
ac: mc’s email:
https://lists.w3.org/Archives/Public/w3c-wai-gl/2021JanMar/0057.html
... awk’s “The list of what constitutes "discussion" on line 21
doesn't include AG surveys but on line 27 it does. Does
responding to a survey count as discussion?”
awk: worth including surveys.
<alastairc> Include surveys on line 21
ac: Jonathan Agree with the
updates.
... he further stated, “Decisions such as pushing back the
publication date of WCAG 2.2 need to communicated in the email
list clear and not just in minutes. From what I can tell a
decision was made in September timeframe that we were not going
to meet the deadline for WCAG 2.2 in November. But this fact
was buried in minutes and to my knowledge not clearly
communicated on the email list to the group. Picking out
important items from the minutes can be a
challenge for some and important items need to be clearly communicated.”
ac: wasn’t a decision but an
outcome of some things that happened.
... not sure what we could add to the policy.
... Wilco wanted Something else
... he said, It seems to me that if "-1" votes on a CfC are
problematic to the group, we need to put more effort into
building consensus. There are a lot of things we can do about
that. Have surveys open for longer periods, alternate meetings,
do more async communication, etc.
... we have previously tried separate meetings without
success.
... asynchronousis better.
... Wico also said, “In my opinion, a CfC should be an
opportunity to confirm with a wider group that the decision
that was made on a call was the correct one. I think it is very
important that we allow everyone in the group to vote on a CfC
if they wish to. It is important for building support and
legitimacy of our work.”
... chair hat off - we have had a lot of discussion by various
roots.
... usually have 2 surveys and email discussions.
... when you do raise an objection here is a helpful way to
object.
... CFC is the last stage.
... it allows us to move on.
wilco: may have other
solutions.
... could approach people on an individual basis.
... this group moves very fast.
... feels harsh to say if you missed a conversation too
bad.
<JF> +1 to Wilco's thoughts
ac: we have done pre CFC’s
... people coming at the last minute.
... problematic if people come in at the last minute.
wilco: is that happening?
ac: it has happened.
... want to make some progress.
jf: want to +1 wilco.
... we have to give people enough time. changing rules last
minute feels wrong.
... we will be stifling some conversations
chuck: not sure when we could change and it not be mid stream
dm: pros and cons to lots of
things.
... 2.0 tried to avoid objections. it took a long time. 8-10
years.
... had to bend over backwards. It took a lot of time.
ac: updates we are making.
Objections need to be public.
... making it clearer what makes things better.
<kirkwood> issue go with out me
<kirkwood> issue on my end, move on
ac: we don’t just spring CFCs on people.
jk: is this an education outreach
thing?
... do we need a better schedule?
ac: open to suggestions.
... we have github issues, surveys, discussions, meeting.
jk: feel others find it complicated.
ac: feel it is breath not the
speed.
... would help Wilco could be more specific.
wilco: it is the whole thing.
chuck: not saying if you don't do it this way you are out. but you may be out.
wilco: think we should say what the process is.
gn: new policy seems to say if you were not in the meeting you are out.
<Wilco_> +1, that's how this comes across to me as well
gn: people may have other
pressures and obligations.
... it is very complex. It can be hard to be heard on the
mailing list.
... rather not exclude people.
chuck: perhaps make it not so
absolute.
... go back to MC to make it less absolute.
<jon_avila> One challenge we have is that we have worked for a year on a criteria that helps users with disabilities and then someone comes it right at end and objects and the criteria is removed and benefits to users go away because there is no time at the 11th hour to iron out any differences.
chuck: don’t want to waste mc’s time.
gn: yes that would help.
<JF> +1 to framing as "Best Practices"
wilco: make it what is expected. best practices.
ac: ja make a good point. “One challenge we have is that we have worked for a year on a criteria that helps users with disabilities and then someone comes it right at end and objects and the criteria is removed and benefits to users go away because there is no time at the 11th hour to iron out any differences.”
<kirkwood> +1 to JA
ac: CFC is very much a last step.
detlev: if it take a year it is a
waste of time.
... things can’t be held up if one or 2 people delay.
... we could grind to a halt.
<JakeAbma> +1 to Detlev
AC: Gundula had a comment. “n Michael Coopers summary there were valid points which I do not see reflected in the changes in github. "A CfC should not be used to raise additional discussion unless unavoidable. " and "and reasons the objection could not be addressed during discussion prior to the CfC.".
This could be done by adding something like <li>describes why the objection was not raised and considered during discussion leading to the CfC, if applicable</li>.”
scribe: ”Next, I am irritated by the word 'potential' in the existing text "<li>describes how the objection was raised and considered during discussion leading to the CfC, including how reactions to the potential objection were addressed;</li>". If it was raised indeed, it is no longer potential. Further, if addressed, why isn't it resolved? Shouldn't the be explained when filing an objection?”
<JF> https://www.w3.org/2020/Process-20200915/#Consensus
GN: people should be able to comment.
ac: we will have a chat with mc
tomorrow.
... trying to be clearer.
wilco: think it is the nature of the work. things come up last minute.
<kirkwood> +1
wilco: preference to keep policy as it is. Could have some guidance. Doesn’t need to be in the policy.
<JF> +1 to Wilco: there is already a process in place
ac: Does anyone object to the public piece? (crickets)
<Wilco_> scribe: Wilco
<alastairc> scribe:Wilco_
<Zakim> Chuck, you wanted to ask for scribe change
<kirkwood> Guidance for participation, schedule, and who’s affected in a clear way. (process needs not be changed)
Alastair: Will come back with another update
RESOLUTION: Update policy again, return soon
<alastairc> https://raw.githack.com/w3c/wcag/wcag22-visible-controls-update/understanding/22/visible-controls.html
Alastair: Had a discussion previously, have an update to the understanding document.
<alastairc> "For user interface components that appear on pointer hover or focus, information needed to identify that user interface components is visible without requiring pointer hover or keyboard focus, except when:"
Alastair: Had an objection that
the focus should be on the controls, not the information.
... Bruce wanted to keep the text.
... Don't understand what Bruce thought was in scope
before.
David: Language of the
understanding talked about controls that were not visible. It's
really the "hover" controls that are the concerns.
... when there was early formulation of it in understanding it
was about controls hidden any way, then it developed to "on
hover"
Alastair: Explains Bruce's
point.
... Gundala, wonder if it's confusion about how it starts off.
Could be the component itself, could be an edit button,
etc.
... A few ways you can have the information the control is
there without requiring hover or focus.
Gundula: Text suggested talks
about UIC, essentially it says UICs that appear on hover or
focus must be visible without hover or focus
... Can not identify me without me being there. Can't identify
me until I'm there.
... The name of the requirement, hidden controls or persistent
controls. This implies there is no interaction needed to see
them.
<alastairc> "Where receiving pointer hover or keyboard focus triggers user interface components to be visible, information needed to identify that user interface components are available is visible, except when:"
Alastair: Also had some discussion on the mailinglist. This was the final suggestion.
<jon_avila> I liked Alastair's suggestion on the list
Alastair: This is another alternative, trying to say the same thing in a clearer manor.
<alastairc> "Information needed to identify user interface components is visible without requiring pointer hover or keyboard focus, except when:"
Alastair: Doesn't seem like may
people want the newer formulation. It seems to be between what
we currently have and the one above from the mailing
list.
... Tried to keep it to User Interface Component
<alastairc> Option A: CUrrent text "Information needed."
<alastairc> Information needed to identify user interface components is visible without requiring pointer hover or keyboard focus, except when:
<alastairc> Option B from mailiing list:
<alastairc> Where receiving pointer hover or keyboard focus triggers user interface components to be visible, information needed to identify that user interface components are available is visible, except when:
<Sukriti> A
<sarahhorton> A
Alastair: If people could put in A or B
B
<daivd-macdonald> B puts the focus on comoonent with is better
<MelanieP> B
<JF> B
<GN015_> A
<laura_> B
<juliette_mcshane> B
<JakeAbma> B
<Detlev> B seems more explicit, so B
<jon_avila> option b
Alastair: 3 A's, 8 B's
<Raf> b
Alastair: Seems we have a
preference for B. They are trying to say the same thing. What
passes or fails is information, and the scope is made more
explicit.
... B's have it. Don't think that triggers other changes in the
document, but we can make that update.
<kirkwood> b
RESOLUTION: Accept the new text from the mailing list
<daivd-macdonald> a bit of grammar to fix in(B) "That user interface components
Alastair: Me and Rachael tried to
do the update to use UIC more consistently. It become tricky to
use UIC, in the understanding document.
... Otherwise every time you mention the success criterion you
have a 3-word acronym, which gets really wordy.
... Text would be 20% longer if you use UIC fully.
... Sarah suggested previously to say "user interface component
(controls)"
<JF> disagree, the definition *should* be in the normative SC
Alastair: I think it is just very
wordy to use UIC.
... Not proposing we remove UIC, I'm suggesting we make the
connection explicit.
<daivd-macdonald> To be honest I don't remember any conversations from 2.0 vintage where we had arguments about UIC vs controls.
John: What I'm hearing is we try to use two terms interchangeably. If we use it interchangeably it needs to be in the normative part of the spec.
Alastair: To be clear, where we have UIC, we put "(controls)" at the end so we can use UIC and controls interchangeably.
John: Why don't we add controls in the glossary? In either case this is what we mean?
<Chuck> wilco: sets up a circular defintion.
Gundula: Don't think UIC and control are interchangeable.
<alastairc> UIC: "a part of the content that is perceived by users as a single control for a distinct function"
Gundula: control is something interactive, whereas a UIC might be a box with text.
Alastair: As defined, UIC and
control are equivalent.
... Essentially the proposed change is to put "(controls)"
after the first instance of UIC, so we can leave the document
as is.
Stefan: Just want to ask if the decision was made with touch devices in mind. Was wonder what should happen on touch devices here.
Alastair: If something doesn't appear on a touch interface, the point is that there is some indicator something is there. If the site doesn't code it to be accessible with a single-pointer.
Stefan: The SCs are always
interaction channel dependant. This is an important
thing.
... For example one SC is for keyboard and others are for touch
devices.
... Clearly indicate in advance that some SC are not for touch
for example?
<alastairc> Poll, +1 to include "(controls)" in the SC text.
Alastair: I think this is a side point. Will start the poll.
-1
<Raf> +1
<JF> +1
<daivd-macdonald> 0
<Detlev> +1
<sarahhorton> +1
<JakeAbma> 0
<Sukriti> +1
<juliette_mcshane> 0
<jon_avila> 0
Alastair: It is the underlying content that is the scope of the SC.
<laura> +0
Stefan: So this is intentionally left in a weak definition state?
<Chuck> 0
<MelanieP> 0 - I think it should go with the first instance of UIC in the Understanding doc
Alastair: If you have a UIC that only appears on hover or focus, there should be a visible indicator of it
<laura> s/asynchronous is /asynchronous is /
Stevan: So this is explicitly not for mobile devices?
Alastair: Can attach a keyboard to mobile
<daivd-macdonald> I could live with interactions
<alastairc> visible interactions"
Wilco: Seems clunky to use "UIC (control)" in normative text
Alastair: Suggest visible interactions?
<Detlev> What would be the complete wording that includes "visible interactions"?
David: We sometimes compromise accuracy when making up the handles to keep it short.
<alastairc> Poll: (A) for "Visible Interactions", same text. (B) for "Visible controls", and including (controls) in the SC text.
Alastair: The complete wording we'd have the new wording which references UICs.
<JF> B
<Detlev> B
<oliverkeim> B
<Chuck> B
<JakeAbma> B
David: Suggest C, use controls in the handle, and UIC in the text.
C
<Detlev> interactions is a process between user and thing...
<daivd-macdonald> C
<MelanieP> +1 to David
<sarahhorton> B or C
<Chuck> wilco: user interface components is defined as a control
Wilco: UIC is defined as a control, not strange to use it that way.
Alastair: I find it odd that we wouldn't mention controls in the SC at all.
<MelanieP> C
<Raf> B or C
<daivd-macdonald> mildly
-0.5
<MelanieP> Seems clunky
Alastair: Anyone object to
"(controls)" in the text?
... In which case I'll drop it
RESOLUTION: No change
Alastair: Would appreciate people have a look at the understanding document.
<Chuck> ISSUE: Update to the note
<trackbot> Created ISSUE-53 - Update to the note. Please complete additional details at <https://www.w3.org/WAI/GL/track/issues/53/edit>.
Alastair: Last question was an update to the note.
Alastair: There was a question raised about visible entry point.
<Chuck> close ISSUE-53
<trackbot> Closed ISSUE-53.
David: Visible entry point was a term from one of the comments, thought it was cool.
Alastair: What we're trying to
achieve is to make it clear something like a dropdown is not
the point.
... Do get Wilco's point about multiple meanings.
<alastairc> "Controls can be available through a visible entry point such as a sub-menu."
<alastairc> "User interface components can be available through persistently visible components such as sub-menus."
<MelanieP> User interface components can be revealed through use of a visible components such as submenu buttons, edit buttons, tabs, or thumbnails of media
<alastairc> Wilco: Take out 'persintently.'
Alastair: Think that still works.
<alastairc> User interface components can be available through visible components such as sub-menus, edit buttons, tabs, or thumbnails of media.
<alastairc> User interface components can be available through other visible components such as sub-menus, edit buttons, tabs, or thumbnails of media.
wilco: needs the word "other"
<Chuck> wilco: needs the word other
Alastair: Does that seem like a good note?
David: Little sad to lose visible entry point
+1, but it needs a definition
scribe: Seems like a good word for a thing, teachable moment to introduce a new term.
Alastair: Suggest rather than introduce it through a note is introduce it in the understanding document.
<GN015_> +1, as 'visible entry point' is generic and thus future proof.
David: Could do, but fewer people would read
Alastair: If someone wants to take a task to define it
David: Can work on it
RESOLUTION: Use "User interface components can be available through other visible components such as sub-menus, edit buttons, tabs, or thumbnails of media."
Alastair: Accidentally left
"done" in question 1.
... Had some discussion, people weren't totally happy with the
solve. Suggested a massive simplification.
<alastairc> For web content with page break locators, a mechanism is available to navigate to each locator.
<alastairc> Statically paginated formats (e.g., PDF) where the user agents include a mechanism to navigate by page typically meet this success criteria by default. The user agents for the EPUB format also typically provide the navigation mechanism if a page list is included. Web browsers do not have a standard page navigation mechanism, so for HTML content with page break locators it is the author responsibility to add that mechanism.
Alastair: If people look at the
page, the note at the bottom of "intent", think we got to a
place where Matt and Avneesh were happy with it.
... Seems like this would solve the issues we had. In the
survey several people approved.
Gundula: In the current text the
norm says if there is a page locator you need a mechanism to
that. Only in the examples is it mentioned that we're talking
about page numbers and things like that
... It creates divergent in when the SC is fulfilled. It does
not follow the consistency.
Alastair: Know what you mean, but
we do have a lot of SCs that when we boil them down don't
really explain what the usual scenario is.
... As a developer, if I'm not putting in page locators, I can
ignore that one.
John: If numbering is automatic, the size of the document will also change the numbering.
<Chuck> wilco: Now that we have epub folk, I would like to know why this is not available in the user agents for epub. Why does this need to be in WCAG?
<Chuck> Matt: ready systems alreading have their own dynamic implementation, this SC is for the static implementation.
<Chuck> wilco: follow-up. should user agents do that scanning? Why is this a content author responsibility?
<Chuck> matt: There's a wide variety of ways reading systems are created. Not going to be pulling in every page it loads a document, and won't enumerate every page. There's a limitation of scanning.
<Chuck> matt: Decision was made to make this the author's responsibility to provide this list rather than getting reading systems to do this.
Alastair: If it is going through
a web browser is where the SC becomes most applicable. Even a
browser isn't going to do something with the page list.
... This SC is most relevant when an EPUB goes through the
browser.
<Chuck> wilco: If there are tools that do this automatically, the definition of "mechanism" may not be the right one. If tools exist, that IS the mechanism.
<Chuck> alastair: That will get into "accessibility supported." It's a fair point. If it's just accessibility readers, you don't need it, but if you support webview, then it would be on you.
<Chuck> alastair: to add a front end mechanism.
Matt: for epub you're providing
half the mechanism. If you don't provide it, it's not
available.
... Alastair: Got the updated SC text. Anyone still in the
defer camp?
... Anyone still have questions / concerns about the SC?
<alastairc> Poll: Accept the SC text and understanding doc for wide review?
<Chuck> +1 for wide review
<Detlev> +1
<laura_> +1
<JF> +0 (want to think on this a bit more)
<avneeshsingh> +1
<Raf> +1
<juliette_mcshane> +1
<sarahhorton> +1
<Sukriti> +1
<daivd-macdonald> +1
<JakeAbma> +1
+0
<morr4> +1
<AWK> +1
RESOLUTION: Accept new text
<GN015_> -1
<Chuck> ack +1
<daivd-macdonald> Visible Entry Point: A visible user interface component that makes other user interface components visible. Examples (bullet list): a menu button opens up sub-menus, an edit button opens up a full range of edit commands, a tab button displays a tab panel, a tile provides an entry to a buy now button, wishlist, a thumbnails of media opens a player with visible controls.
david: Have a proposed definition of visible entry point
Alastair: For next week few issues to wrap up.
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/aloses/allows/ Succeeded: s/mulitple /multiple / Succeeded: s/firtst respondant/first respondent/ Succeeded: s/paragrah /paragraph / Succeeded: s/gramatically/grammatically/ Succeeded: s/abour/about/ Succeeded: s/wya would get us//ways would get us./ Succeeded: s/futher /further / Succeeded: s/descion /decision / Succeeded: s/acincoiunase /asynchronous/ Succeeded: s/wiclo aslo /Wico also / Succeeded: s/alot /a lot / Succeeded: s/disscussions/discussions/ Succeeded: s/apporach/approach/ Succeeded: s/pave /we have / Succeeded: s/comein /coming / Succeeded: s/happenting/happening/ Succeeded: s/when whe /when we / Succeeded: s/tooks a lot /It took a lot / Succeeded: s/schdule/schedule/ Succeeded: s/disussions/discussions/ Succeeded: s/speciffic/specific/ Succeeded: s/saying iy you do’t do ti this way youn are out. /saying if you don't do it this way you are out. / Succeeded: s/presures /pressures / Succeeded: s/har d/It can be hard/ Succeeded: s/ahve /have/ Succeeded: s/tommorrow/tomorrow/ Succeeded: s/any one abject to the public peice>/Does any one abject to the public piece? (crickets)/ Succeeded: s/perfer /prefer / FAILED: s/asynchronousis /asynchronous is / Succeeded: s/rasie /raise / Succeeded: s/moeves /moves / Succeeded: s/no the speed/not the speed/ Succeeded: s/whiole /whole / Succeeded: s/wlco /Wilco / Succeeded: s/havea/have a/ Succeeded: s/neet to /need to / Succeeded: s/any one abject /anyone object / Succeeded: s/asynchronousis /asynchronous is / Succeeded: s/ready/reading/ Default Present: Detlev, Laura_Carlson, Raf, juliette_mcshane, Matt, Orr, alastairc, Chuck, mgarrish, Francis_Storr, Wilco_, MelanieP, karenherr, GN, Sukriti, JakeAbma, JF, sarahhorton, StefanS, Caryn, daivd-macdonald, kirkwood, George Present: Detlev, Laura_Carlson, Raf, juliette_mcshane, Matt, Orr, alastairc, Chuck, mgarrish, Francis_Storr, Wilco_, MelanieP, karenherr, GN015, Sukriti, JakeAbma, JF, sarahhorton, StefanS, Caryn, daivd-macdonald, kirkwood, George Regrets: Katie, BruceB Found Scribe: Laura Inferring ScribeNick: laura Found Scribe: Laura Inferring ScribeNick: laura Found Scribe: Wilco Found Scribe: Wilco_ Inferring ScribeNick: Wilco_ Scribes: Laura, Wilco, Wilco_ ScribeNicks: laura, Wilco_ 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]