<Chuck> meeting: AGWG-2022-01-18
<alastairc> scribe: Fazio
<AWK> +AWK
<scribe> scribe: Fazio
<scribe> New topics = none
<Rachael> https://github.com/w3c/silver/wiki
Rachael - transparency concerns, content findability concerns, keeping pace with necessary schedule is a concern
Project plan increasdes visibility
Rachael - Wiki page is core of the plan
Rachael - Key Points: foundational work, scoring, content creation, guidelines
Rachael - projects divided into milestones divided into stages
Rachael - milestones help for organization but aren't permanent
Rachael - organization is being documented by wiki
Rachael - each milestone has a wiki page, same basic template.
Rachael - Wiki is github linked
<Jemma> + 1 to note key decusuibs argreed on!
<Jemma> s/decisions/decesions/
Rachael - Use wiki to document key decisions.
Rachael - Stages are based on process discussed in October 2021
<Detlev> Rachael could you repost the URL
Rachael - Github issue mapping is still in process
stages are in process doc
Judy - I'm happy
<mbgower> great work!
Judy - POC info is important standard for continuity across all W3C work
JF - I'm happy to see the clarity and transparency too
JF - why is conformance and scoring separate
Rachael - it seemed like a natural grouping
Shadi - I'm happy too
<Rachael> Note: Add the email for ag-plan to all group POCs
Shadi - are their parts that need to be achieved before re-chartering?
<Zakim> bruce_bailey, you wanted to ask about Edit Mode drop down
Rachael - I don't know
Bruce - I'm happy too
Bruce - curious asbout backend
<alastairc> If anyone is confused by (or wants) the black background, that's a setting in github: https://github.com/settings/appearance
MC - slightly different than traditional wiki, all features are github standard
Gregg - I'm happy too
Gregg - It's approachable in understandable. Under guidelines (alphabetical order) I suggest sorting by POUR. It keeps things that are related together.
Gregg - re-sorting helps reduce confusion during re-naming
DM - Watershed moment. Everything is coming together better. Wiki was great idea
Janina - can we get pointers to the rules? What's different?
<AWK> GitHub wiki markup: https://docs.github.com/en/github/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax
<MichaelC> https://github.github.com/gfm/
MC -I will find a doc link. Preview exists to help
<Azlan> I'm going to have to drop off. I'm having connectivity issues. Will catch up when the minutes are shared.
<Zakim> Chuck, you wanted to comment on POUR
<Zakim> jeanne, you wanted to say that they are done in MediaWiki
Chuck - organizing by POUR is intriguing. How much do we want to attach to WCAG 2.x or a new standard? We need to consider
<alastairc> If we used categories, I'd suggest a different set of categories.
JS - syntax is done in media wiki
JS - need to choose media wiki as format
<Rachael> https://github.com/w3c/silver/wiki
<Zakim> bruce_bailey, you wanted to say that it seems to that syntax is tied to the page not the authors preference
Bruce - Syntax is page creators choice, not user-editors choice
<Zakim> Jemma, you wanted to ask how other subgroups like protocol group will be added to project plan (or protocol is not subgroup)?
Jemma - how are subgroups documented in project plan?
Rachael - organized by milestones not subgroups. Multiple groups may be involved in a milestone or multiple mile stones
Rachael - Groups that want a page can request one from Rachael and/or Jeanne
Rachael - a lot of content is already available in Silver wiki
<Jemma> Can you share "milestone page" example link or protocols page itself is the mileston page?
<Chuck> https://www.w3.org/2002/09/wbs/35422/wcag3/results
AK - difficult to say yes or no until additional conformance issues are decided
AK - Alastair response is ok, but no might be better, or not sure
<mbgower> +1 to AWK
laura - agrees with andrew and john
<JF> https://www.w3.org/WAI/GL/WCAG3/2021/how-tos/clear-words/#develop-button
JF - how to section says inline dictionaries need to be keyboard accessible. It's way too early to comment on this guideline
I agree with JF!!!!
Guideline is misdirected
<ToddL> +1 to JF
<jon_avila> I agree with Andrew as well.
<Chuck> proposed RESOLUTION: Accept AWK's response to address issue 380
Alastair - agree with Andrew. user agent tools are not sufficient currently. This content is exploratory. Issue still needs to be closed though.
Alastair - standard response is needed
JF - don't understand the point. basically responding on a hypothetical is problematic
MG - add info to dev technique page, that dev tech alone won't be sufficient
<mbgower> That seems like a good stock response for many things
<mbgower> "progresses"?
<Chuck> proposed RESOLUTION: Accept amended response to address issue 380, and tag as discussed
JF - Guideline might not even make the cut. So using the term "matures" doesn't make sense. Too many issues with it
JF - putting it in for the sake of being able to revise is a problem
Alastair - levels of maturity are part of the guideline approval process
<Jemma> +1 to alastair
JF - Mike Gower's term progresses is a better statement
Chuck - me too
<JF> +.5
<Chuck> proposed RESOLUTION: Accept amended response to address issue 380, and tag as discussed
<mbgower> I guess "progress"?
<Jemma> +1
<Ryladog> +1
<AWK> yes, "pregress"
<AWK> "progress"
<Chuck> proposed RESOLUTION: Accept amended response to address issue 380, and tag with input-for-future-version
<bruce_bailey> comma after progresses (before we)?
<sarahhorton_> +1
<Chuck> +1
<bruce_bailey> +1
<ToddL> +1
<kirkwood> +1
<Rachael> +1
<JF> +.5
<mbgower> +1 with grammatical tweaks
<alastairc> +1
<AWK> +1, but without Bruce's comma :)
<jeanne> +1
<Detlev> +1
<laura> +.5
<Lauriat> +1
thx for the typing break
<Raf> +1
<Rachael> Draft text for resolution: Thank you for your comment. The Working Group has concerns that current implementations may not fully meet user needs, and as the WCAG 3.0 conformance model and this method progress we will work to clarify whether or not this will be sufficient. We are closing this issue but are adding a label (input-for-future-version) to ensure the group considers your point as we move forward and look at techniques.
<Chuck> proposed RESOLUTION: Accept amended response to address issue 380, and tag with input-for-future-version
RESOLUTION: Accept amended response to address issue 380, and tag with input-for-future-version
<bruce_bailey> s/s/
<bruce_bailey> https://www.w3.org/2002/09/wbs/35422/wcag3/results#xq3
Alastair - How does alt text and accessible name fit in wcag 3?
<Chuck> I will process queue once I have gone through the responses that request "something else"
<Jemma> +q to ask the context of the issue to wilco
text alternative seems to be preferred by more people
get ready for scribe change btw
AK - nothing to add
Laura - agree with Rachael
<Zakim> JF, you wanted to comment on Leonie's response
JF - terminology depends on your role.
<Jemma> I am sort of agree with Leonie and wilco's point but concerned about how users will easily understand the concept of accessible name.
<alastairc> accname applies beyond images though
<Zakim> Jemma, you wanted to ask the context of the issue to wilco
<Wilco> Context: https://www.w3.org/TR/wcag-3.0/#text-alternatives
<JF> +1 to Jemma
<bruce_bailey> +1 to JF suggestion for parenthetical -- i.e., accessible name in the DOM
JF - Jemma - accessible name maybe difficult to understand
Jemma - who do I contact to raise issue
Janina - we need to get this right. Possibility for misunderstanding. Need a global standard for this topic
Janina - big difference from accessible name and info summary, but both are text alternatives
<Zakim> mbgower, you wanted to say they're not synonymous
<GN015> +1 to Mike
<bruce_bailey> +1 to MG that that Accessible Name is synonym for alt text
<alastairc> New suggested response: https://github.com/w3c/silver/issues/169#issuecomment-1015619337
MG - text alternative and accessible name are not synonimous
I spelled that wron :(
wrong
<bruce_bailey> scribe: bruce_bailey
Wilco: alt text might be super set of accessible name,
<Jemma> Jemma agree with the "accessible name" concept because it can cover more but I see the challenge how this radical change will be accepted to not techcial users.
Wilco: suggest definition list or add terms or glossary
<Fazio> Wilco - defintion needed to make difference clear between text alternative and accessible name
Wilco: also , it might be that wcag3 not require text alternatives -- because it outcome based
<Zakim> Rachael, you wanted to ask if we should rework this or pass it back to the subgroup?
Wilco: so if the outcome is that end user gets information, might not mention alternative in outcome per se
<Zakim> Chuck, you wanted to say that John's suggestion seems to get us closer
Rachael: sounds to me like feedback might need to go back to sub group
chuck: i think i agree we need to see where we should go
<Fazio> scribe change please
Alastair reads his reply from github issue
<Rachael> Option 1) Send feedback back to the group. We think "text alternative" is the better terminology. Consider adding definitions that distinguish between accessible name and text alternatives. Option 2) New suggested response: https://github.com/w3c/silver/issues/169#issuecomment-1015619337
<alastairc> https://github.com/w3c/silver/issues/169#issuecomment-1015619337
<Chuck> https://github.com/w3c/silver/issues/169#issuecomment-1015619337
chuck gives straw poll
alastair: is short, group should continue to refine turn
<Rachael> 2
<Chuck> 2
chuck straw poll
<mbgower> 2
<AWK> 2
<jeanne> either is fine
<alastairc> 2
<Raf> 2
<ToddL> 2
<JF> 2
<Detlev> don't know
<kirkwood> 2
<Rachael> subgroup
chuck: clarifies who gets work
<Chuck> proposed RESOLUTION: Accept Alastair's response to address issue 169 and send back to the team working on textual alternatives for additional review
<Rachael> +1
<Rachael> +1 to mg text alternative
MG: advocate for text alternative over textual alternative (since the latter is new)
<Chuck> +1
<JF> +1 with "text alternatives"
straw poll on proposed resolution
<Rachael> +1 if changed to text alternatives
<ToddL> +1
<kirkwood> +1
<jeanne> +1
<janina> +1
<Francis_Storr> +1
<laura> +1
<Raf> +1
RESOLUTION: Accept Alastair's response to address issue 169 and send back to the team working on text alternatives for additional review
<mbgower> +1 with preference for no "textual"
<JakeAbma_> +1
<mbgower> been updated already :)
JF: but want text alternative over textual alternative
janina: might ask group to consider
<Chuck> proposed RESOLUTION: Accept Alastair's response to address issue 169 and send back to the team working on text alternatives for additional review
<laura> +1 to preference for no "textual”. It is simpler.
<janina> +1 to GV. That was my concern precisely
gregg: this is not going to final language, we might consider textual just because it sounds good, but it is not plain language because it is not a real word
RESOLUTION: Accept Alastair's response to address issue 169 and send back to the team working on text alternatives for additional review
<janina> Suggest we not sacrifice precision on the altar of plain language
Alastair: this a response providing sub group with information, this will be coming back to AG WG...
<Jemma> +1 to GV and further more we are trying to minimize the confusion rather than moving onto "accessible name".
Alastair: better to tackle wordsmitting then
https://www.w3.org/2002/09/wbs/35422/wcag3/results#xq5
https://github.com/w3c/silver/issues/257
Chuck reads from survey
This guideline should state up front that a "meaningful" text alternative is required, rather just a text alternative...
scribe: We will keep your points in our mind.
6 agree, 6 something else
Chuck: reads from survey replies
Bruce from survey..escriptive Identification -- which is decidedly *not* an equivalent text alternative -- is (sometimes) not only sufficient but the best practice.
Tink from survey:I do not agree with this response. I think it's important to include an adjective in the guideline itself, though I would use "appropriate" instead of "meaningful", for the reasons stated in the proposed response.
Alastair: My concern was between the guidline text and page
It does appear that the issue-poster was asking for an update to the guideline text, not the title.
Detlev (from survey): I think it is currenty difficult to solve this for Silver since the granularity of guidelines overall is not clear yet....
A draft of all guidelines and how they divide the cake would be needed for this. I suggest to postpone answering.
JF: I don't agree that focus is on title [explains]
MG (from survey): I would like to advocate that the existence of a text alternative be one requirement, and that the quality of the text alternative be another requirement. Not only Is the first much easier to confirm through automation, but the existence of the alt is an implementation check, while the quality of the alt is a design check.
AWK (from survey): A nice short guideline is desirable, but "Guideline: Provide text alternative for non-text content." could benefit from the addition of equivalent: "Guideline: Provide equivalent text alternative for non-text content."
Larua Carlson: I agree with suggestion from AWG and MG.
Chuck: People seem to be agreeing with AWK and MG, but not sure where that leaves the response.
MG: Previous discussion was more towards to stock response ... but want more feedback from group ...
<Rachael> the best way to capture additional things woudl be to add an issue and tie it to the milestone
MG: but for future work we need a consensus respones
chuck summarizes and mike agree
<alastairc> Suggested poll: Should the guideline include an additional adjective such as meaningful/equivelent/appropriate? Y/N
<mbgower> N
chuck, this might help us tie work to outline we reviewed at top of call...
scribe: i dont feel like we are exactly close to that at the moment
<alastairc> "Provide text alternative for non-text content."
<Chuck> poll: Should the guideline include an additional adjective such as meaningful/equivelent/appropriate? Y/N
Alastair: It seems to me we should be able to tie this response closer the the guideline as in...
and return back to subgroup, maybe address in the next draft
scribe: so just make that suggestion to subgroup?
<JF> a HUGE +1 to @mgower
<janina> +1 to Mike
Mike Gower: Current approach, with machine assessment and 1.1.1 and need for quality, we need to tackle this gap with wcag3
<AWK> +1 to Mbgower
scribe: so i would really like for us to get closer to quality with wcag3 guideline
<Rachael> I don't think we know quite yet but I think adding that as an issue woudl be useful
<mbgower> I don't know :)
Alastair: so is quality this guideline or a new and different one?
JF: I agree with MG response, and passing feedback to text alternatives subgroup...
<Zakim> Rachael, you wanted to asnwer
seems unanswered.
<mbgower> opening an issue
<Chuck> proposed RESOLUTION: Return the issue to the team working on the response, and consider an adjective, and consider separating requirements.
Rachael: It is worthwhile we are addressing this, and we have similar aspect with other guidelines
chuck proposes resolution, reflecting what we are hearing
three things in proposed resolution,
<Chuck> +1
<janina> +1
<Rachael> +1
<laura> +1
<jeanne> +1
<JF> +1
RESOLUTION: Return the issue to the team working on the response, and consider an adjective, and consider separating requirements.
https://www.w3.org/2002/09/wbs/35422/wcag3/results#xq9
Chuck reads from survey.
From ITI: ...it will be difficult for policy makers to understand what conformance levels can be reasonably expected for technologies to attain that can be included in regulations. More clarity in the specific proposals is needed to give a more detailed response to the question.
See issue: https://github.com/w3c/silver/issues/457
4 agrees, two something elses
JF: ITI issue is not complexity
but need for complexity.
... also reference to "group voting" is not correct, its is
just that AG WG has not gotten consensus
Laura Carlson: also agree with deferring on response
AWK: the way question is phrased,
ITI is asking for flexible conformance model...
... so this answer to question prompted, not ITI per se
<alastairc> +1, they aren't requesting a specific change, they are stating a wish to have 1 conformance model.
Chuck: If AWK interpretation is correct, is response as-is?
AWK agrees that response is okay in that regard
Chuck ask if JF agrees with AWK reading of ITI comment?
<alastairc> They said "There should be one model for conformance, based on rating and scoped by documenting the sampling, processes, and any other testing performed with an easy way to calculate the conformance level."
<laura> +1 to jf
<janina> +1 to JF
JF: Agree w/ how characterized ITI comment, but our proposed response is still off.
<janina> We might say we're trying to minimize complexity while contemplating flexibility
<laura> we need a stock reply for these.
Alastair: Proposed response to complexity is further down in there comment. I am not sure what more we can do with comment.
<alastairc> Thank you for your ideas. The Silver Task Force agrees with you that we do not want to make the conformance too complicated. We are closing this issue but are adding a label input-for-refinement to ensure the group considers your point as we move forward.
JF: Agree with most of response, but would just remove comment in middle about complexity.
Alastair proposed (shorter) response.
<Chuck> proposed RESOLUTION: Accept amended responses to address issue 457
Chuck reads, and proposes ammended response for straw poll.
<laura> suggest changing move forward to progress
RESOLUTION: Accept amended responses to address issue 457, and tag issue as input-for-refinement
<janina> It's still addressing complexity, though
JF: Alastair response still emphasis for complexity rather than flexibility.
<Jemma> "If it is too complicated, it will be difficult for policy makers to understand what conformance levels can be reasonably expected for technologies to attain that can be included in regulations. More clarity in the specific proposals is needed to give a more detailed response to the question."
<janina> They want flexibility without complexity
Alastair: ITI comment concludes
with concern for complexity.
... Balance is needed, as more flexibility likely to mean more
complexity.
<Chuck> Thank you for your ideas. The Silver Task Force agrees with you that we want to make the conformance more flexible and not too complicated. We are closing this issue but are adding a label input-for-refinement to ensure the group considers your point as we move forward.
Janina: We are working hard to make that balance.
<jeanne> jeanne: They are responding to the a SotD question on flexibility. Their comments are about complexity.
Chuck reads.
<janina> +1 to Chuck
<JF> +1
Alastair: agree that ITI had concern for complexity
<Chuck> +1
<alastairc> +0.5 and move on
<Rachael> +.5 I can live with it
<JF> +1
<jeanne> +1 to move on
<Jemma> +1
<janina> +1
<Chuck> proposed RESOLUTION: Accept amended responses to address issue 457, and tag issue as input-for-refinement
RESOLUTION: Accept amended responses to address issue 457, and tag issue as input-for-refinement
chuck that is 3 issues
Alastair: given time left today, we will focus a little bit...
<alastairc> https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-enhanced2/results#xq32
Alastair: please see update
<alastairc> https://docs.google.com/document/d/1aW5BHq0hzKlOmU8wrB0OLipVmcg-SfT5MqU1BhNzqYs/edit
Alastair: also have discussion document
What do we use for basis of size? Outlines, other focus indicators...
What are they measured against?
This issue was focus of Friday call, and include feedback from Wilco.
<alastairc> "Note: In HTML the size of a component is measured up to and including the CSS border."
Component term implies perceived size, but elements like "button" is not enough
we came up with a new note, the html css border aligns with target size
<Jemma> s/componet term/user interface component/
scribe: this approach gives a concrete target
<Zakim> JF, you wanted to suggest The Silver Task Force agrees with you that we want to make the conformance model flexible.
Chuck: That recent work does focus on component (per survey) but this has an additional change.
<alastairc> SC: "When a component receives keyboard focus, an area of the focus indicator meets the following"
Alastair: yes, this is recent not
enough to be in a PR proposal
... Friday we talked about "perceptual size" but also get at
discrete measurement
Wilco: i have other concern for this SC, but not being able to measure accurately was my main concern...
so problem area reduces. As written, this might be limited to markup languages.
<Chuck> proposed RESOLUTION: Carry on with the current approach, focused on 'component'. Accept yet to be created PR that amends the first sentence of the SC to "When a component receives keyboard focus, an area of the focus indicator meets the following…"
Alastair: We also had conversation about bounding box as fall-back measurement.
chuck reads proposed resoultion.
Alastair: CFC soon, and CFC will include note.
Wilco: As Melony mentioned, Chrome will soon have user setting to expose focus. Is that impact this?
Alastair: We discussed recently, but conclude implementation (in Chrome) has significant limitations.
Wilco: Is that a normative change though?
Alastair: No, because user-agent solution is not enough.
<alastairc> Wilco, see https://www.w3.org/WAI/WCAG22/Understanding/focus-appearance-minimum.html line starting "The default focus indicators..."
Gundaula: Are we deciding on final wording now?
<alastairc> Note: In HTML the size of a component is measured up to and including the CSS border.
Alastair: Not, replacing note and adusting opening phrasing.
Gundula: Seems out of sync with some other proposed SC phrasing.
Alastair: We have another survey itme on that detail.
<Chuck> proposed RESOLUTION: Carry on with the current approach, focused on 'component'. Accept yet to be created PR that amends the first sentence of the SC to "When a component receives keyboard focus, an area of the focus indicator meets the following…" and update note
<mbgower> https://www.w3.org/WAI/WCAG21/Understanding/resize-text.html
Mike Gower: We have a long history for resize text, and when UA is enough. That phrasing is part of the Understanding document, not normative text.
Wilco: I would like to see PR before straw poll.
<alastairc> https://docs.google.com/document/d/1aW5BHq0hzKlOmU8wrB0OLipVmcg-SfT5MqU1BhNzqYs/edit#
Alsastair: change is in above doc, with yellow highlight
<Jemma> trying to understand creating PR makes what difference....
Chuck and Alistair agree they have phrasing correct.
<alastairc> proposed RESOLUTION: Carry on with the current approach, focused on 'component', tweaking the SC text to make clearer the basis for size
Alastair: looking to get feedback on most recent approach
<Jemma> +1
<Chuck> +1
<alastairc> +1
<Wilco> -.5
<mbgower> +1
<GN015> +1
<Rachael> +1
<Detlev> +1
RESOLUTION: Carry on with the current approach, focused on 'component', tweaking the SC text to make clearer the basis for size.
<GN015> I do not agree to base on the CSS border.
<JF> bye all
<ToddL> +1
Wilco and Gundula have concerns
<Jemma> html section is the note.
Gundala: proposed css measuring is novel
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) FAILED: s/descusibs/decesions/ Succeeded: s/descusibs/decisions/ Succeeded: s/I'm happy/I'm happy to see the clarity and transparency/ Succeeded: s/Syntax is owners choice not user/Syntax is page creators choice, not user-editors choice/ Succeeded: s/version [08:45] <bruce_bailey> comma after progresses (before we)?/version/ Succeeded: s/[08:45] <bruce_bailey> comma after progresses (before we)?// Succeeded: s/accepted/accepted to/ Succeeded: s/Alastair reads his reply from survey/Alastair reads his reply from github issue/ Succeeded: s/on textual alternatives for additional review/on text alternatives for additional review/ Succeeded: s/three things in PR./three things in proposed resolution,/ Succeeded: s/liver/live/ FAILED: s/componet term/user interface component/ Succeeded: s/concrete targe/concrete target/ Succeeded: s/That phrasing is not part of this SC/That phrasing is part of the Understanding document, not normative text/ Default Present: alastairc, shadi, Azlan, janina, JakeAbma, Rachael, bruce_bailey, SuzanneTaylor, sarahhorton, Fazio, Jen_G, jeanne, Lauriat, AWK, JF, garrison, kirkwood, Raf, Detlev, MelanieP, Jemma, david-macdonald, GreggVan, Laura_Carlson, Nicaise, Wilco, stevelee, Katie_Haritos-Shea, jon_avila, ToddL, .5, Francis_Storr, mbgower, GN Present: alastairc, shadi, Azlan, janina, JakeAbma, Rachael, bruce_bailey, SuzanneTaylor, sarahhorton, Fazio, Jen_G, jeanne, Lauriat, AWK, JF, garrison, kirkwood, Raf, Detlev, MelanieP, Jemma, david-macdonald, GreggVan, Laura_Carlson, Nicaise, Wilco, stevelee, Katie_Haritos-Shea, jon_avila, ToddL, .5, Francis_Storr, mbgower, GN, GN015 Regrets: Jaunita George, Jennie Delisi, Rain Michaels Found Scribe: Fazio Inferring ScribeNick: Fazio Found Scribe: Fazio Inferring ScribeNick: Fazio Found Scribe: bruce_bailey Inferring ScribeNick: bruce_bailey Scribes: Fazio, bruce_bailey ScribeNicks: Fazio, bruce_bailey 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]