(MEETING TITLE)

<alastairc> WCAG 2.2 issues [60 minutes] Survey: https://www.w3.org/2002/09/wbs/35422/wcag22-misc5/

Alastair: Survey will stay open, has 15 items associated with it.

announcements (including CSUN attendance)

<alastairc> https://www.w3.org/2002/09/wbs/35422/CSUN-Face-To-Face/

Alastair: Face to Face CSUN attendance , there are 10 people intending to be there in face to face , 6 remotely.
… please do sign up and answer if you can
… do we know timing for day?

Rachael: 8am Pacific , 11am ET through afternoon is plan, nothing definite.

<alastairc> Questions on Editor's Draft Survey: https://www.w3.org/2002/09/wbs/35422/draft-revew-Feb-23/

Alastair: Survey on editor's draft .

Rachael: Relatively short survey. The second question was answered previously but we are carrying over. Please do submit if you are able.

Closes this Thursdsay.

Alastair: Any open announcments?

MaryJo: WCAG2ICT update . We are creating guidance for WCAG 2.1 a and aa . We have our first four ready for survey. We have background section as well.
… We will be pointing out a survey for AGWG . I'm creating survey right now. We will discuss in AGWG meeting .

<AWK> +AWK

Alastair: Might be March 21st timeframe with CSUN etc. happening.

Guideline Grouping Survey Survey: https://www.w3.org/2002/09/wbs/35422/guideline-org/

<kirkwood> +1 to AWK re more time

AWK: Plea for consistency on when surveys are open until. Thursday closings are hard time wise to respond. More time is better.

<jon_avila> I find the timing of the surveys very confusing.

Chuck: We are opening on Wednesday , then week to respond on Thursday of next week.

<bruce_bailey> i confess to struggling with new pattern as well

Chuck: hopefully that works for all, as that also helps to include weekend for chairs.

AWK: appreciate the efforts on aggregating the comments.

Alastair: WCAG 2.2 issues are backlog issues. Multiple issues , those are left open and we tackle per week. WCAG 3 is more topic based and gathering of opinions.
… Different use cases , but goal is to have more time to have to respond , Thurs to Thursday window for responses.

<alastairc> https://www.w3.org/2002/09/wbs/35422/guideline-org/results

Alastair: Context was to have placeholder level content and organizing for work. Organized by topic , scope, expertise. Currently placeholder only.
… more about how we are working through them, vs. how we are going to present the content in the end

CSUN is on 13th, we don't have a meeting on Tuesday, next is on March 21st.

Color Contrast, Luminescence and Text size

Alastair: Mostly comments were from Andy S.

<Rachael> https://docs.google.com/document/d/1EsNS1z_WBt3Ey30m-At8V87jYeM65KoWSR7L3SRR3T4/edit#heading=h.sxfsael6ky53

Rachael: Andy would like to add second guideline to proposal, places in link to Google doc
… Readability and luminance contrast topic and comments may be easier in document.
… opens up to group for comments.

<Lauriat> +1 to Alastair, we'll need similar expertise, best to keep grouped.

Alastair: May be worth separating out if have enough for different sub groups . Any particular comments from group?

<Rachael> Contents use sufficient contrast and do not rely on color alone

<Rachael> Contents use sufficient contrast and do not rely on color alone

Gregg: What are we separating out?

<Rachael> Contents use sufficient contrast and do not rely on color alone

Rachael: Color alone vs. visually readable content uses sample luminance

<Rachael> Visually readable content uses ample luminance contrast

Gregg: Visually readable ... one would rely to buttons vs. text ? They should state why they are different. Running text. vs. no running text.

<Zakim> Lauriat, you wanted to +1 Alastair on context

Lauriat: Does splitting out guidance within work , that is more a question within subgroup to decide.

<GreggVan> +1

Alastair: In the document, we can leave them separated out. How we arrange the work, it would be the same subgroup. We will get back to Andy.

Rachael: I would leave the notes in the doc, I would re-word if we are to split them out. Subgroup action item.

<Rachael> +1

Rachael: Jennifer recommended putting in structure . Structure should be own subgroup ? Kind of opposite of last topic on organizing.

<ToddL> Jennifer sent her regrets via email the other day

Alastair: Jennifer not on participant list. Regrets for this meeting. For this work, we will keep in document. Subgroup can consider that topic as well.

Rachael: slightly different conversation on breaking them out. Want to avoid subgroups working on same thing in different places.

Gregg: I would agree. Making a comment on structure being consistent. Consistency around cognitive , agree separate.

Term / grouping for "safe"

Rachael: Site or app is "safe" to use. Alternative phrasing is requested. Flashing, animations, motion, etc. Need name for guidelines.

Rachael: Not dangerous was one recommendation.

<jeanne> I like "avoids known hazards"

<ToddL> I just added a comment in the doc. Suggestion: "The site or app does not cause harm"

Gregg: Working groups need to be separate. I.e. flash and computational aspects. Different expertise for other topic.

<jeanne> +1 to splitting into two groups because of different technical expertise.

<Rachael> +1 to splitting it

Jaunita: If we are talking about banking, i.e. critical errors, you have risk. For example, financial fraud, etc.

Laura: request to remove third party . We don't have consensus yet. It would be for everyone.

<Zakim> Rachael, you wanted to answer the 3rd party piece

Rachael: This pulled together the work back in the fall that was done on this topic. Warns users should still be part of what is within this topic.

<kirkwood> +1 to delete “3rd party”

Alastair: Flashing and Animations grouped together?

Todd: Guideline , the site or app does not cause harm would be one suggestion.

<jon_avila> Is there any concern that saying "warning" might make people think it's ok to use flashing content as long as they warn the user first.

Alastair: holistic term of safe vs. avoiding harm... thank you.

<kirkwood> safety & security guidelines is terminology have used

John Kirkwood: on terminology being used .

Alastair: More on subgroups to decide

Overall organization discussion

<jon_avila> I agree "safe" is different than doing no harm.

Alastair: Not being organized by principle. Jennifer wasn't convinced this was needed. Perhaps by topic, etc.

<jeanne> +1 to say that tagging will be essential and is part of the design

Alastair: editor's note on feedback , as part of this for PR for placeholder in regard to the draft structure .

<Lauriat> +1 to jeanne, beat me to noting it

Alastair: talks to it not being final, but structured by tagging vs. one particular structure in general.

Gregg: This document is for organizing outcomes. The guidelines aren't organized per se. The guidelines could still be organized in POUR principles.

<Zakim> jeanne, you wanted to say that tagging will be essential and is part of the design

Might be an interaction that the sub outcomes may not sort well if sorting guidelines.

<GreggVan> +1 to Rachael's comments

<jon_avila> I agree with the tagging approach

<alastairc> +1, I've been through re-organising the guidelines multiple times, and am pretty confident there is no "one way" that works across organisations / audiences.

Jeanne: Part of design is heavy use of tagging and flexibility of organization. We are trying to organize by topic and expertise. For a way of identifying what goes together. We aren't getting rid of POUR (principle) . Some could apply to perceivable and operable per se.

<Rachael> +1 to alastair's point

<Zakim> Rachael, you wanted to suggest alphabetical order for the placeholder level

Jeanne: Design group is working on findability and filtering of information vs. how we are working on these items.

Rachael: We do have levels, so we may not need organization . Grouping for work is important. Perhaps grouping alphabetically would be beneficial .

<Zakim> bruce_bailey, you wanted to note i marked my comment as resolved -- is that constructive to the process? Or should I let editors do that?

<GreggVan> oops I meant +1 to Jeanne's comment (also rachael now)

Bruce: Alphabetical sorting comment on organization.
… on comments, in Google doc, marking as resolved ok in document?

Rachael: Yes, that is fine.

Alastair: Jared Spool mentioned that alphabetical is arbitrary , thus true to what Bruce mentioned.

<bruce_bailey> completely arbitrary and intentionally so -- i love it

Rachael: PR is next step. Please comment in Google doc if you are able to.

Discussion about Requiring vs. Encouraging

Chuck: We know these are challenging conversations. We know they are all valid. We follow the code of ethics .
… We want to call out blanket statements and may need further research .
… we found out that framing of required vs. encouraged did not work out entirely. All are requirements for someone , somewhere.

We need to think of difficulty level of a particular method or recommendation and consider user impacts, then we map to bronze, silver and gold. I.e. needs for education and training. Healthcare. Entertainment needs, for content types.
… conversation will continue next Monday regarding mapping.

Gregg: Very good points. We talked to concept of requirable and encourage able , how does the person know that they've done it or not , passed it or not. Make it easier...how do I know if it is easy enough?

<Zakim> alastairc, you wanted to comment on trying to separate user-requirement from spec-requirement

<Chuck> https://docs.google.com/document/d/1vcRAtYtdTSgoUoY30BpSFEs9Wji3k2Q3N9Qm3vRsFVg/

Alastair: I was also member of call yesterday. We have rough notes and will refine it as we move through it .

We have a slight problem , user requirements and what we are requiring in terms of the specification. We have requirements we want included. WCAG 2 isn't a complete map of accessibility related.
… spec was on what we expect authors to do. User requirements vs. requirements themselves . Mapping those to bronze, silver and gold levels.

<GreggVan> perhaps use "user needs" and WCAG requirements

<bruce_bailey> WCAG has had similar challenge with the use of the word "guidance" and "guideline"

Do we want to have a more complete listing to include?

<Zakim> mbgower, you wanted to say often we speak of "user needs" and "standards requirements". Can we maintain those perspectives?

Alastair: Are we prepared to do that? We need to concentrate on required , due to MVP requirements of charter.

Michael: User needs vs. standards requirements may be a possibility
… my need may be more general, requirements may change and be different.

<kirkwood> agree with user needs separation

<bruce_bailey> yes, requirements of the requirements we are crafting

Alastair: Requirements of spec vs. author and user needs as well.

Gregg: Plus one on user needs. If in WCAG 3 , user needs and what we can do to meet them. Some are required , some are not. Requirable vs. encouraging (recommendations) .

<Zakim> Rachael, you wanted to say next steps

Rachael: These are two meetings that are setting up the face to face conversation. We will revise the two options and bring this back to group on 13th as a subgroup back to AGWG

Alastair: We will talk to this more in CSUN remote and Face to Face discussion

agreed: )

<Jennie> *I would really appreciate an email to the list, a week ahead of the CSUN hybrid session, with links to any documents that will be discussed.

<Rachael> Jennie, we will do our best

<Chuck> +1 Jennie

WCAG 2.2 issues [60 minutes] Survey: https://www.w3.org/2002/09/wbs/35422/wcag22-misc5/

<Jennie> *Thank you @Rachael!

Alastair: Agenda moves toward WCAG 2.2 issues

1. Suggest more structure to Intent section of 3.3.7 Understanding article #2650

Alastair: most people agreed , one suggestion with adjustment, editorial changes. Opens to Michael.

<jon_avila> Agree with Mike!

MikeG: Is there something as fully inclusive and accessible? Perhaps "more" accessible or inclusive. Perfection is concerning.

MikeG: Suggestions were more editorial in survey.

<kirkwood> +1 to MG issue on “fully accessible”

<bruce_bailey> +1 to MG edit for "more accessible" versus "fully accessible"

<GreggVan> +5 to that. we even devote a paragraph to saying nothing is ever "accessible"

Alastair: Link was to accessibility enhanced.

<GreggVan> only better or minimum

<alastairc> Line 63 - change from fully to 'more'

MikeG: talks to granularity of line 63 on issue

<bruce_bailey> https://github.com/w3c/wcag/pull/2988/files

MikeG: Other suggestions were editorial in nature.
… my hope was not to changing in meaning.

<kirkwood> ho about just getting rid of the “more” or “fully” qualifiers?

<AWK> https://www.w3.org/Guide/manual-of-style/

Gregg: if you are talking about "the web" it is capital. If website, it typically is not capitalize it. Defer to W3 definitions and editorial aspects.

<GreggVan> +1 to that

Alastair: Want to avoid massive find and replace regarding where this is mentioned.

<alastairc> draft RESOLUTION: Accept PR 2988 with adjustments from mbgower

DanB: The original issue was consistency around organization. Not sure if separate concern of what PR is resolving the issue.

<bruce_bailey> From https://www.w3.org/Guide/manual-of-style/#Terms

<bruce_bailey> Either capitalize or lower case "Web" (e.g., Web developer or web developer, Web project or web project, Web page or web page, Web application or web application

Alastair: I thought it did resolve the issues.

<bruce_bailey> Web site, web site, website : two words (capitalize or lower case "Web") or one (lower case)

DanB: I was referencing 2650 PR.

<alastairc> draft RESOLUTION: Accept PR 2988 with adjustments from mbgower, double-check that it answers issue 2650

Alastair: I may need to reference the PR and answering the questions contained

<Ben_Tillyer> +1

<mbgower> +1

<GreggVan> +1

<Wilco> +1

<ToddL> +1

<dan_bjorge> +1

<Jaunita_George> +1

<bruce_bailey> +1

<Makoto> +1

<AWK> +1

<kirkwood> +1

RESOLUTION: Accept PR 2988 with adjustments from mbgower, double-check that it answers issue 2650

RESOLUTION: Accept PR 2988 with adjustments from mbgower, double-check that it answers issue 2650

<Laura> +1

3. Example Could Be Replaced with an Example that Encourages Greater Equity #2550

<alastairc> https://github.com/w3c/wcag/pull/2753/files

Alastair: Color wheel topic and inputs around using it.

<ChrisLoiselle> thanks, Bruce!

Michael Gower: I think concern Suzanne raises in survey has been addressed.

[MG quotes color wheel excerpt]

mbgower: Per my comment in survey, I think it redundant

<alastairc> A widget where you can drag a gift to one person in a photo of a group of people also has a menu alternative where users can select the person that should receive the gift from the menu.

alastairc: Everyone agreed, so question is do we add example?
… please +1 to add example , or -1 if you think it redundant

<mbgower> -.1 especially because it's a little hard to picture/understand

<alastairc> Poll: +1 to include, -1 to not include

<Chuck> bruce_bailey: Is one of those drag and drop?

<GreggVan> +1 to have a drag and drop

<Chuck> bruce_bailey: The other's didn't sound as much.

bruce asks if earlier example is clearly drag and drop ?

<dan_bjorge> +0.5 - I think it's redundant with the existing 3rd example, but better than the existing example (ie, drop the 3rd)

bruce: slider control is not great example of drag and drop

greggv: i think we should keep both because there are so many kinds of drag-and-drop
… the example with coordinate entry seems not similar to others

<GreggVan> +1 to that kanban is jargon

dan_bjorge: i think 3rd example IS drag and drop, but its not obvious
… so I suggest replacing that one with this simpler example

alastairc: I recommend keeping that one in, as it is a common pattern...

<dan_bjorge> Also fine with keeping both if the 3rd is really a specifically common example in practice

<alastairc> A kanban implementation allows users to drag and drop items between columns, and provides an additional pop-up menu after tapping or clicking on items for moving the selected element to another kanban silo by tapping or clicking on pop-up menu entries.

alastairc: Trello is drag and drop for example , but keyboard alternative has good useabiltiy

alastairc: How about updating Kanban example ? And keeping others as well?

<Laura> +1 to Gregg

GreggVan: For interests of plain language, can this be writting without out "Kaban" and describe functionality.

<GreggVan> +1

<dan_bjorge> "task board"

<kirkwood> no

<alastairc> A task board (kanban) implementation allows users to drag and drop items between columns, and provides an additional pop-up menu after tapping or clicking on items for moving the selected element to another kanban silo by tapping or clicking on pop-up menu entries.

MikeGower suggest Kanban in parenthetical -- because it is useful for people who know the term

mbgower: i will have suggestion in PR comment

<mbgower> A taskboard that allows users to drag and drop items between columns, also provides an additional pop-up menu after tapping or clicking on items for moving the selected element to another column by tapping or clicking on pop-up menu entries.

ChrisL gives a technical definition.

alastairc: So we will include Detlevs updates and some of thees other suggestions.

<kirkwood> “drag and drop task board"

[alastair does some screen sharing with PR edits]

<kirkwood> oops

<ToddL> "signboard"

<alastairc> draft RESOLUTION: Accept PR #2753 with amendment to link to taskboard / kanban explanation.

alastairc: To Jon A, suggesting is okay but already addressed in full context.

<kirkwood> +1

<ToddL> +1

<Wilco> +1

<Ben_Tillyer> +1

<Makoto> +1

<dan_bjorge> +1

RESOLUTION: Accept PR #2753 with amendment to link to taskboard / kanban explanation.

<Laura> +1

<Raf> +1

4. Focus not obscured margin technique and working example #2746

<Jaunita_George> +1

alastairc: This is new technique because we did not have clean example previously

[alastair review comments from survey]

https://www.w3.org/2002/09/wbs/35422/wcag22-misc5/results#xq11

alastairc: From preview, I have incorporated suggestions from survey.
… still needs a little more work and suggestions to better address Wilco's suggestions.
… we might be able to trim back , deleting CSS in example

<alastairc> Updates: Ensure it works at different viewport sizes.

<alastairc> ... reduce amount of code in example (rely on the working example)

alastairc: i am checking sample code with different view ports sizes

<alastairc> ... Update test procedure to clarify the tabing-to aspect, not scrolling plus tabbing.

alastairc: Other updates to techniques?

alastairc: Okay to leave to Francis to pull and minor edits?

Wilco: Concur.

Francis Stor: There was a suggestion about useability with code highlighting...

[alastair and francis discus]

<alastairc> draft RESOLUTION: Accept PR #2746 with proposed amends to be done.

<Laura> +1

<Wilco> +1

<ToddL> +1

<kirkwood> +1

<Chuck> bruce_bailey: Make sure that you aren't counting on me to make notes Francis...

alastairc: This is still an issue for FireFox

<alastairc> Also check Firefox, not fixed element

RESOLUTION: Accept PR #2746 with proposed amends to be done.

5. What are the user's solutions of Focus Not Obscured (minimum)? #2700

https://www.w3.org/2002/09/wbs/35422/wcag22-misc5/results#xq12

alastairc: Propose essentially we accept Detlev response on GitHub thread.

mbgower: I am not sure we got the question. I was not clear if after focus on not wrt person who submitted issue.
… i am note sure if response is complete

<Jaunita_George> +1

alastairc: i will add in your comments from survey

<alastairc> https://github.com/w3c/wcag/issues/2700#issuecomment-1290835189

alastairc: Detlev reply are examples on solutions for some points raised by commenter...

<alastairc> draft RESOLUTION: Accept Detlev's response to the question, as amended.

alastairc: MikeG is more from developer perspective

<mbgower> +1

<Chuck> +1

<dan_bjorge> +1

<Laura> +1

[no objections raised]

RESOLUTION: Accept Detlev's response to the question, as amended.

<kirkwood> +1

<Makoto> +1

6. Clarification sought on "set of web pages" #2298

<ToddL> +1

https://www.w3.org/2002/09/wbs/35422/wcag22-misc5/results#xq13

https://github.com/w3c/wcag/issues/2298

alastairc: We have added a few more examples and clarified another...
… substantial comment from Wilco, recommending against change to any TR doc

alastairc: If keep to Understanding docs only , this will be 5-6 success criteria -- so a number to update

MikeG: are example in spec normative or informative ?

<dan_bjorge> From 5.1, "Introductory material, appendices, sections marked as "non-normative", diagrams, examples, and notes are informative (non-normative)."

alastairc: nominally examples are informative , but still effects translations

Wilco: Change in TR space remains problematic, not just for translations. We have to resolve for 2.1 or 2.0 as errata or not?
… not understanding rational for keeping to Understanding.

<alastairc> Poll: Include example in (1) The definiton, or (2) the five understanding documents

alastairc: Updating definition for 2.2 seems much cleaner. Does answer for 2.2 only change voting ?

GreggVan: If it is definition, then normative ?

alastairc: Examples in definition are informative.

<GreggVan> +1 to Mgower

mbgower: It is a good place to have definitions clear , as technology matures

<jon_avila> I don't have strong feelings either way.

<kirkwood> +1 to MGower

Wilco: It is not just this case only, there are endless place we might make things clearer. Adding examples as technology evolves seems unending.

alastairc: We addressed this with 2.2 on similar issue that Jon Availa raised. We have space with 2.2 to add some clarity...
… We would not anticipate errata for 2.2 just to add an example....

<Zakim> mbgower, you wanted to say changes https://github.com/w3c/wcag/pull/3008/files and to say I would like response to my suggestions https://github.com/w3c/wcag/pull/3008/files

alastairc: this is for publication. After publication is a very different case.

mbgower: Process question, are edits in GitHub constructive -- or should I stick with survey?

mbgower: explains mechanics of suggestion on pull request for suggested edits to PR
… Is that something to avoid? Should I use survey only?

<GreggVan> Good for accuracy. Color visions is not required --

alastairc: As chair (editor) the suggestion mechanic is VERY helpful.

<Zakim> GreggVan, you wanted to say Agree we don't want to do this a lot -- but we should do when WE think it is unclear or we need to clarify with our own team

alastairc: Would ask for as soon as possible, make reference to survey.
… no need to repeat PR suggestion in Survey

GreggVan: The fact that we are making examples for each other is telling that we need better examples.

<alastairc> Poll: (1) Update in the definition, or (2) add the examples to the Consistent Help SC understanding page.

alastairc: Agreed, and this example cam from jon_avila who is on the call.

<GreggVan> 1

<dan_bjorge> 1

<Ben_Tillyer> 1

<mbgower> 1

<Wilco> 2

<Jaunita_George> 1

<Chuck> 1

<kirkwood> 1

<Makoto> 1

<jon_avila> 1 but either way would work

<Laura> 1

<ToddL> 1

<mbgower> I'd prefer just 2.2

Wilco allows group consensus

defers

<Wilco> prefer errata for both

alastairc: question as to what to do for 2.1 , 2.0 ?

<alastairc> Poll: (1) Supplement defintion for 2.2 only (2), or include as errata for 2.1 and 2.2

<mbgower> prefer 1, but 2 is fine

<alastairc> Poll: (1) Supplement defintion for 2.2 only (2), or include as errata for 2.1 and 2.0

<GreggVan> 2

<jon_avila> 1 but 2 would be fine as well

<Ben_Tillyer> 2

<Makoto> 2

<ToddL> 2

GreggVan: Updating definition is going to raise red flaggs, so please characterize as "supplementing current definition"

<Rachael> 2 but 1 is fine as well

<Laura> 1

<Wilco> 2

<Jaunita_George> 2

<dan_bjorge> either fine

<Laura> no objection

alastairc: Any objections on call for doing as erratta ?

<Jaunita_George> We probably should keep guidance consistent and the errata would help us do that

alastairc: One other suggested example from MG ...

<alastairc> Any issues with the suggested update?

<kirkwood> +1 to suggested update

alastairc: Any problem with this update from MikeG?

<dan_bjorge> +1

<ToddL> +1

<mbgower> +1

<Makoto> +1

<Ben_Tillyer> +1

<Laura> +1

<Jaunita_George> +1

<Rachael> +1

RESOLUTION: Accept PR #3008 and add as errata to 2.0 and 2.1

<jon_avila> +1

<Wilco> 0

7. Dragging Movements - Carousels - Overflowed Containers #2684

mbgower: Have another words smithing

https://www.w3.org/2002/09/wbs/35422/wcag22-misc5/results#xq14

<jon_avila> Scrolling feels more like a gesture

alastairc: Concern is that scrollable containers are not in scope of dragging.

alastairc: Asks if MikeG has incorporated into his PR suggestions?

<jon_avila> Not all scrolling areas have scroll bars.

<jon_avila> Firefox will add tabindex to areas with overflow - but other browsers will not.

mbgower: I did not , as I thought that was changing PR too much

alastairc: I suggest we accept PR, as we can investigate and ammend later if needed

<alastairc> draft RESOLUTION: Accept PR 3040 and close issue 2684

<Ben_Tillyer> +1

<mbgower> +1

<ToddL> +1

<Wilco> +1

<Makoto> +1

RESOLUTION: Accept PR 3040 and close issue 2684

8. Update focus-appearance

alastairc: Minor edit from Wilco

mbgower: i have in my PR

<alastairc> draft RESOLUTION: Accept PR 3017

dan_bjorge: Distinction between WHILE keyboard focus versus when RECIEVING kb focus

mbgower: This is focus , not focus unobscured

alastairc: SC did get slightly tweaked, lets double check

mbgower: We have current requirement for focus indicator , and the SC for focus visible versus focus

<alastairc> draft RESOLUTION: Accept PR 3017

<Wilco> +1

<Laura> +1

dan_bjorge: this prose is illustrating and contrasting SC , so we should be careful

<mbgower> +1

<ToddL> +1

<Rachael> +1

<Ben_Tillyer> +1

<Makoto> +1

<kirkwood> +1

<GreggVan> +1

RESOLUTION: Accept PR 3017

9. Does Redundant Entry require the data available in the current step? #2805

https://www.w3.org/2002/09/wbs/35422/wcag22-misc5/results#xq16

alastairc: For context, earlier version of SC includes series of steps -- and that was problematic

<alastairc> Requiring people to recall information entered previously can cause them

alastairc: this PR updates Understanding to match current SC text , and having mention of steps was confusing
… survey question might have included some of that context , which address Wilco's comment in survey.

mbgower: I have provided editorial suggestion for some of this

alastairc: Comment in survey from jon_avila about in the same page -- addressed by fact that SC scoped to page

dan_bjorge: In context in this SC, can we add "in the same process" ?

alastairc: The "same process" might reference data from three screen prior -- so that is not as helpful.

<alastairc> Data which is "available to select" would need to be on the same page.

<jon_avila> I agree with the idea - thanks for the clarification

[alastair and wilco discuss less-jargon phrasing]

[mbgower explains UI option for line-by-line comment/suggestion]

<alastairc> draft RESOLUTION: Accept PR 3042

<alastairc> draft RESOLUTION: Accept PR 3042 as amended in the PR

<jon_avila> +1

<Laura> +1

mbgower: Page icon with plus symbol , very mouse centric operation , but converts your entry to suggestion which is easy to add int

<Chuck> +1

<mbgower> +1

<Wilco> +1

<kirkwood> +1

<jon_avila> Thanks all

<Makoto> +1

<mbgower> Thanks all

<Rachael> +1

alastairc: More questions for next week!
… we got through 8 of 10 hightlighted

zakim ?

https://www.w3.org/2023/02/14-ag-minutes.html is 404