<Chuck> meeting: AGWG-2023-01-24

<Chuck> https://www.w3.org/WAI/GL/wiki/Maturity_Labeling_Process

<ChrisLoiselle> unable to scribe today.

<alastairc> scribe:Sheri_BH

<Jay_Mullen> +present

Pull Request from Test Types Subgroup https://www.w3.org/2002/09/wbs/35422/PR_Test_Types/

Alastair shared his screen and reviewed the changes in the pull request for agenda item number one

<Chuck> Based on a comment from Bruce Bailey in the responses, here is a link to our Maturity Labeling Process: https://www.w3.org/WAI/GL/wiki/Maturity_Labeling_Process

6 people voted yes, 3 people suggested updates, there were no objections

<AWK> +AWK

Gregg's suggested changes were largely editorial and terminology related

gregg's changes - use quantitative instead of computational to go with qualitative

expand the examples under qualitative

Gregg provided more examples of conditional tests

<kirkwood> +1 to Gregg to point of quantitative instead of computational

<Jennie_Delisi> Aside: small editorial issue - extra space between "properties exist" in line 303

Gregg suggested "test" alone wasn't enough, it needed to be "reliably test"

<Chuck> Based on a comment from Bruce Bailey in the responses, here is a link to our Maturity Labeling Process: https://www.w3.org/WAI/GL/wiki/Maturity_Labeling_Process

Alastair then reviewed the remaining comments which were all fairly minor and editorial

<alastairc> https://www.w3.org/WAI/GL/wiki/Maturity_Labeling_Process

Alastair: next stage after experimental is developmental

<Chuck> We will get to queue when we finish reviewing comments

Jaunita: Suggested to add more explanation around why computational was used

<bruce_bailey_> thanks for the clarification

<Chuck> PR 666

Jaunita: simplified the language in this section, removed stuff that complicated the content that wasn't absolutely necessary

Alastair: we will keep iterating, it doesn't have to be perfect, there is one more stage before it goes in to the public working draft

<Chuck> proposed RESOLUTION: Amended PR 666 and merge as exploratory

<Chuck> proposed RESOLUTION: Amend PR 666 and merge as exploratory

<Wilco> +1

+1

<bruce_bailey_> +1

<Chuck> +1

<jeanne> +1

<ToddL> +1

<Ben_Tillyer> +1

<Makoto> +1

<sarahhorton> +1

<laura> +1

<Jennie_Delisi> +1

<joweismantel> +1

<iankersey> +1

<ShawnT> +1

<JenStrickland> +1

<Poornima> +1

<Jay_Mullen> +1

<Lauriat> +1

<kirkwood> +1

RESOLUTION: Amend PR 666 and merge as exploratory

<GreggVan> +1

Design and IA Update https://www.w3.org/2002/09/wbs/35422/agwg-wcag3-design/

<bruce_bailey_> https://wilcofiers.github.io/wcag3-docs-wireframes/

Wilco: reviewed agenda item 2 which was raised at TPAC
... The first Nav layer is Get started
... Activities has a second layer, the rest don't

Sheri's comment - that previous line might be wrong, Methods also appeared to have a second layer

Alistair: there was a lot of feedback in the survey for agenda item 2

<Chuck> https://www.w3.org/2002/09/wbs/35422/agwg-wcag3-design/results

Alastair: the subgroup should review the feedback. It did feel simpler than what we currently have

Alastair asked people who had navigation comments to get into the queue

<bruce_bailey_> +1 to sentence case over all caps

Jennie: use sentence case and not all caps in the header navigation
... visual indicators for the links

Gregg: Methods should be plural
... Getting started page was quite good. Helps people orient themselves before they dive into more detail
... Activities might not be the best choice of word. Stages might be better?

<Jennie_Delisi> * Thanks jeanne. Reviewing the subheadings in Making Content Usable can be one way to quickly review to verify some of the aspects are included.

<Wilco> @Gregg, please note that the text is dummy content

Gregg: some of the stuff on Activities is general advice, not specific

Alastair: It's placeholder content
... content is not final version, we want to focus on the navigation only right now

<kirkwood> +1 to Gregg

Gregg: found the items under methods disorienting
... If I'm looking for something can I search just within a single tab

<maryjom> +1 to the jarring aspect of clicking on See more and going to another area - Methods.

Gregg: there needs to be a search mechanism to satisfy "two ways" we are violating our own guideline on this one

<Ben_Tillyer> +1 to search being a necessity

Alastair: work in progress

<jeanne> +1 to searching. Good catch. That was always intended to be in the design

Ian: we need to break the content up, his concern was the tab panel construction, magnification becomes problematic
... tab panel construction doesn't zoom well
... maybe accordions instead?
... likes the breakdown and the breadcrumbs
... doesn't like the secondary navigation for Method and Activities

<Zakim> bruce_bailey_, you wanted to mention that three levels of nav, not just two

Bruce: Looks great, is very excited. Understood that the Activities tab was placeholder content.

<Zakim> Chuck, you wanted to say I believe we are going farther into content than intended, and we want to focus on navigation. and to say and layout

Chuck: focus on navigation rather than the content for feedback at this time

<bruce_bailey_> i think mine was navigation feedback

<JenStrickland> +1 to sentence case v ALL CAPS

<kirkwood> +1 this is cognitive accessibility feedback! great hearing everyone talking about this

MaryJo: found methods a little bit jarring, did find the see more link

<JenStrickland> interactive / links should look interactive / links

MaryJo: we may want to consider rearranging the tab items
... we will need to define what level of content goes into each, so there is limited repeated information

Gregg: the disorienting thing is when I clicked on something and didn't end up where I expected

Laura: nice work, would help if you highlighted you are here

<maryjom> +1 I had mentioned that in my survey response

<jeanne> Llaura, that is part of the design and we haven't done that yet

<Chuck> proposed POLL: This improves upon the navigation and layout

<kirkwood> +1 to highlight it

<Wilco> +1 that was in the design wire frames, didn't manage to get that into the HTML version

<Chuck> Sheri_BH: Somebody mentioned about issues with zooming. As a magnification user, I see reflow may be an issue because of nesting. I'm wondering if we explored using a mega menu instead of tabs and links.

<bruce_bailey_> just noting here (since I missed this in survey) that Activities first impression was that it was a progress bar: plan > design > develop > edit > test

Alastair: survey comments gave the design committee enough to think about

Wilco: Working on designs next, will come up with a next iteration

<JenStrickland> it appears to be an HTML wireframe at the moment.

Wilco: did not consider mega menu, will bring it up

<JenStrickland> you can resize the browser to show the other viewports

Assertions https://www.w3.org/2002/09/wbs/35422/assertions-jan-12/

Alastair: no resolution, goes back to design subgroup
... moving to the third agenda item which is assertions

<alastairc> https://docs.google.com/document/d/10Rl3YJhc4kTyaQwBoQYFp-YvFRK_TdBKkA3kLQKHYwk/edit#heading=h.k1n0svmeyc0

alastair: no clear answer for "what is a procedure"
... all the way from WCAG maintains procedures to organizations maintain procedures

Gregg: concern is if procedures are left to the org to define, it will get an inconsistent level of review from org to org
... that will result in vague procedures
... it will also reward companies that do more smaller things

Alastair: though that Example outcome evaluation procedure had some interesting features and wants to continue to explore it

whoops that was Jeanne not Alastair

Jeanne: it had a lot of good ideas, especially for smaller orgs

<bruce_bailey_> +1 for the coga example oriented for smaller org

<Zakim> Chuck, you wanted to say time check

Bruce: will scribe the second half of the meeting

<Jennie_Delisi> +1 to the duet!!!

<Ben_Tillyer> * please scribe it

<mbgower> +1

<ToddL> +1 and when is the album being released?

<laura> +1

<JenStrickland> +1

<bruce_bailey_> scribe+ bruce_bailey_

<bruce_bailey_> chuck: support for moving in this direction...

<Chuck> Chuck: We were evenly split on what is a procedure, but there is support for moving this forward. Is the group ok to move forward even though we don't have consensus on what is a procedure?

<bruce_bailey_> alastairc: we understand have approval to carry on but need concrete examples

<bruce_bailey_> Chuck: self evident from conversation, so no need for straw poll

<bruce_bailey_> ... we need to figure out how to focus and clarify question.

<bruce_bailey_> alastairc: need more concrete examples, maybe know off top and bottom options

<bruce_bailey_> ... three in middle seem like fair game

<Chuck> +1 to going with the middle 3

<alastairc> draft RESOLUTION: Accept the new Assertions content, acknowledging that the "what is a procedure" needs further definition.

<bruce_bailey_> GreggV: i understand top option is high level of effort , but not having it under consideration is premature

<jeanne> I agree it is premature to take it off the list. I don't think it is necessary to throw it out first

<bruce_bailey_> ... should we say "do 80%" without qualification undermines ability to compare procedures across organizations...

<laura> +1 to Gregg

<bruce_bailey_> ... if we eliminate option one , we might be prematurely limiting themselves

<Wilco> +1

<jeanne> +1

<alastairc> draft RESOLUTION: Accept the new Assertions content as exploratory, acknowledging that the "what is a procedure" needs further definition.

<Chuck> +1

<Ben_Tillyer> +1

<Makoto> +1

<ShawnT> +1

+1

<ToddL> +1

<Poornima> +1

<Jennie_Delisi> +1

<sarahhorton> +1

<iankersey> +1

<JenStrickland> +1

<Raf> +1

RESOLUTION: Accept the new Assertions content as exploratory, acknowledging that the "what is a procedure" needs further definition.

WCAG 2.2 issues https://www.w3.org/2002/09/wbs/35422/wcag22-misc3/

<bruce_bailey_> [switching chairs]

<bruce_bailey_> Moving to 2.2 issues resolutions

Question 1 - 2.5.8: Are all slider variants excluded or only sliders that look and are operated like sliders #2713

<bruce_bailey_> https://www.w3.org/2002/09/wbs/35422/wcag22-misc3/results

<bruce_bailey_> Chuck: Seven outstanding questions.

<bruce_bailey_> GitHub issue 2713 about sliders

<bruce_bailey_> PR has update

<bruce_bailey_> survey 9 agrees , 3 something else

<bruce_bailey_> Wilco (from survey): "continuous" is subjective

<bruce_bailey_> ... we should exempt all sliders. There are other SC (2.1.1) which capture accessibilty.

<bruce_bailey_> [chuck reads stephan's comment]

<bruce_bailey_> alastairc: this is for Target Size minimum (new sc for 2.2)

<ToddL> +1 with Wilco's comments

<Wilco> Then it'd never fail?

<bruce_bailey_> ... agree that "continuous" or not is tricky , but we might use metrics from other sc for granularity

<bruce_bailey_> alastairc: Wilco has exemption as proposed might never fail

<Chuck> bruce_bailey_: I want to know if we decided a slider is different than a scroll bar?

<bruce_bailey_> mikegower: i thought note was making everything a slider ? ...

<bruce_bailey_> ... if slider has

<Zakim> alastairc, you wanted to comment on scroll bars being user-agent feature

<bruce_bailey_> ... if slider jumps, then we have target size addressed

<Zakim> alastairc, you wanted to also say that having in the note is excepting it...

<bruce_bailey_> alastairc: bruces comment was that we could make reference to UI platform feature as exemption

<bruce_bailey_> ... current PR consistent with mike gowers concern

<Jem> If ARIA APG slider example is problematic and the focus of the issue, I would like to let you know that APG TF is working on updating it.

<bruce_bailey_> GreggVan: Why are exempting sliders ? There will be UI pieces of slider which meet target size (ends if nothing else).

<bruce_bailey_> mikegower: we have had blurry conversation about sliders as indivual elements and target size and new dragging SC requirement...

<bruce_bailey_> ... so putting plus or minus at ends should not be necessary for this SC because it is about target size...

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

<Zakim> alastairc, you wanted to say that we are removing the text "with granular values".

<bruce_bailey_> ... if the +/- is the UI then thats a different UI under consideration

<bruce_bailey_> Wilco: I may have conflated my survey comment with concern for "sliders with granular value" in list of exceptions...

<bruce_bailey_> ... so my concern has been address and I retract my -1 vote

<Jem> The semantic of slider from ARIA is that "slider role

<Jem> An input where the user selects a value from within a given range.

<Jem> A slider represents the current value and range of possible values via the size of the slider and position of the thumb. It is typically possible to add or subtract to the value by using directional keys such as arrow keys."

<bruce_bailey_> GreggVan: we still need requirement that size is important because there is a minimum target , just clicking anywhere along a line does not help some who has difficulty with small targets...

<bruce_bailey_> ... the person cannot be any more accurate. This exception does not seem consistent with our overall philosophy.

<Zakim> alastairc, you wanted to comment on the principle of this SC

<ToddL> That was me that +1 Wilco and I have changed my vote as well

<bruce_bailey_> Chuck: Wilco concern has been addressed, so I like to hear from others who agreed with him in survey.

<bruce_bailey_> alastairc: This related to discussion about do we require every letter in a word be spaced out to meet? Of course not, so sliders with continuous values are similar quandry...

<bruce_bailey_> ... would not be reasonable to add +/- buttons when scroll bar UI is well addressed.

<Chuck> thanks Jemma!

<bruce_bailey_> mikegower: I would point out that the distict UI components of sliders have target size requirement, so gap in current phrasing is narrow

<bruce_bailey_> Wilco: I will submit a separate issue because I think we might have gap where star rating (for example) are really a slider.

<bruce_bailey_> Meleanie Phipp asks for clarification of exception.

<alastairc> OK, looks like we can resolve this...

<bruce_bailey_> alastairc clarifies that otherwise we have to define "granular".

<bruce_bailey_> Todd Libby: From this discussion, I withdraw my concern.

<AWK> /me you can't consider a page as a user interface component in most cases.

<bruce_bailey_> GreggVan: I still have concern that exception is too broad if we are just setting target size of whole UI for slider as a whole...

<bruce_bailey_> ... why not exempt the whole page? Seems we are assuming power user does not have under other circumstances.

<bruce_bailey_> alastairc: We know it is not perfect, but as with other examples user can tap into close and get closer and closer

<bruce_bailey_> Wilco: Where are arrows in mobile? This is why I think there is a gap.

<bruce_bailey_> ... could also happen with color picker -- have to hope that there is access feature or keyboard accessiblity

<alastairc> it's a gap regardless of this PR...

<bruce_bailey_> MikeGower: This gets us to the conversation for complex control. What is going to be a requirement for a slider?

<bruce_bailey_> ... As it is now, developer can make pretty small UI but there may or may not be granular control

<bruce_bailey_> ... default approach is adding button on each side of slider

<bruce_bailey_> ... we would expect user to have option for word processor document and the like

<Detlev> +1 to Michael

<Zakim> bruce_bailey_, you wanted to mention platform features

<bruce_bailey_> ...if we are just making problem space smaller , that is okay

<Wilco> +1 Mike, yes there's a gap. That doesn't mean it needs fixing

<Chuck> bruce_bailey_: It's not as well documented as it could be. With current iOS, scroll bars are invisibile. Terrible for this SC. Are asking dev to make up for this? absolutely not!

<Ben_Tillyer> Don't 1.4.4, 1.4.10 etc mitigate this 'gap' when pages can be increased in size users can zoom in, effectively increase the hit size of these points on a slider? (To use the touchscreen mobile example)

<Chuck> bruce_bailey_: Apple has ways to change the default behavior. They have work-arounds in their platform to address this issue with scroll bars.

<Zakim> alastairc, you wanted to say that a volume slider would have to be 2400px tall if not included.

<bruce_bailey_> alastairc: if we consider the bits within a slider to make target size, that woudl 2400 px height -- i except that there is gap in some circumstances

<bruce_bailey_> ... we are just removing three words from that bit of text

<Chuck> propose: RESOLUTION: Accept PR 2718 to address issue 2713.

<bruce_bailey_> ... this discussion has been about a different topic.

<Chuck> +1

<Wilco> +.5

<GreggVan> 0

<alastairc> +1

<Ben_Tillyer> +1

<bruce_bailey_> Chuck: More votes please?

<Detlev> +1

<joweismantel> +1

<ShawnT> +1

<Makoto> +1

<ToddL> +.5

<GN015> +1

RESOLUTION: Accept PR 2718 to address issue 2713.

<bruce_bailey_> Chuck: Before next question, point of order.

<bruce_bailey_> Please do not paint in Zoom

Question 2 - 2.4.12 Focus not Obscured (Minimum) and user opened / controlled content #2751

<ToddL> Is it under the "Whiteboard" option?

<bruce_bailey_> Chuck: next q

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

<bruce_bailey_> https://www.w3.org/2002/09/wbs/35422/wcag22-misc3/results#xq10

<bruce_bailey_> Chuck reads from survey.

<bruce_bailey_> David MacDonald: Perhaps we should allow obscuring dialogs, etc. to pass even if they obscure the focus indicator, as long as there is a setting that passes or if they are movable?

<bruce_bailey_> Chuck, moving to something else comments.

<bruce_bailey_> Rachael wrote: As written, this might include content that opens or expands when the keyboard focus lands on a component and obscures the component that continues to have keyboard focus. I would expect that to fail situation to fail.

<bruce_bailey_> mbgower: i am seeing some UI challenges with this...

<bruce_bailey_> ... we almost have by for unexpected user behavior, so I think we need to keep under consideration

<bruce_bailey_> GreggV from survey: moving windows is not a sufficient approach

<Zakim> alastairc, you wanted to ask for suggestions

<bruce_bailey_> Gundala: Comment in survey is clear (less typo) but still needs work.

<bruce_bailey_> alastairc: There are lots of scenerios which we are trying to work through to minimize gaps.

<bruce_bailey_> ... But if something opens when user gives focus, that is is covers.

<bruce_bailey_> ... If something like a drawing app, and user moves panels around , that is more than author could be expected to control.

<mbgower> it's not, IMO

<bruce_bailey_> ... are there other categories of gams?

<bruce_bailey_> Wilco: My concern is that nuance is only in Understanding and not plain from SC text. Seems like a secrete exception.

<bruce_bailey_> Melanie Philipp: Please see my examples in survey, for example Chat Bot might cover part of the page...

<GN015> when opening a chat box or similar, it should receive focus.

<bruce_bailey_> ... but you opened it, so you can close it. Those scenarios are not problematic and should not be fails of the SC. It is not obvious that we have those in exceptions.

<bruce_bailey_> mbgower: I have seen example with modals on the side, users can move it, so we think that have covered. LinkedIn example is different...

<Zakim> alastairc, you wanted to say perhaps we talk about the mechanisms for manually or automatically closing things to prevent fails?

<bruce_bailey_> ... pane expands pretty widely and focus can go behind this component which the user did open, but focus not getting fixed within pane can be very confusing.

<bruce_bailey_> alastairc: Would it helpful to focus on mechanism for closing?

<bruce_bailey_> ... With drop down that one tabs past and through , while drop down stays open , that is a bug and a problem...

<Zakim> GreggVan, you wanted to say -- can we allow content to cover if it can be moved out of the way by mouse or keyboard?

<bruce_bailey_> ... but Melanie's example where user deliberately opens and has ability to deliberately close is not problematic.

<bruce_bailey_> GreggVan: Can we permit content to cover is moveable by mouse or keyboard?

<bruce_bailey_> alastairc: It would have to be keyboard, but that might be a conseration.

<bruce_bailey_> mbgower: I get point Melanie is making, but if there are a bunch of movable panes, there is still the potential for lots of difficulty.

<bruce_bailey_> Gundala: Question if box opens, then tabs off while box stays open, if focus goes behind box -- that is problematic for keyboard user.

<bruce_bailey_> Wilco: Can we do a variant on author created content?

<Ben_Tillyer> +1 to wilcos idea

<bruce_bailey_> ... If overlap happens from user initiated action, can that be an exception?

<Zakim> mbgower, you wanted to say it puts the onus on the user

<bruce_bailey_> GreggVan: Gundalla is correct, so I withdrawal my previous concern. I do have concern that there is a gap. We have exception for cookies for example.

<bruce_bailey_> ... seems to me there should be a way to require author to keep focus above other areas.

<GreggVan> +1 to that

<bruce_bailey_> mbgower: An author has basically two options, to reflow or pop-up window...

<Zakim> Chuck, you wanted to say how to move forward on this issue

<Zakim> alastairc, you wanted to suggest shift from "initial position" to whether it is user-inititated.

<bruce_bailey_> ...if author always reflows, that address one SC but can create addition problems.

<Wilco> +1

<Chuck> +1

<mbgower> -1 it doesn't cover a menu not collapsing

<bruce_bailey_> alastairc: Present language uses initial state, but what if trigger is automatic or something under user control?

<mbgower> (as an example)

<bruce_bailey_> ... We can bring that back next time.

<bruce_bailey_> Mike: not if it does not cover a menu not collapsing.

<bruce_bailey_> alastairc: by user configurable, I was not thinking user clicking on menu.

<bruce_bailey_> mbgower: Consider mega-menu. Is that much different than sticky footer?

<bruce_bailey_> ... I do not think we can solve on this call.

<bruce_bailey_> Chuck: I heard general concept and proposal to come back to group.

<Zakim> Chuck, you wanted to say what I think is being proposed

<alastairc> Topic for friday?

<bruce_bailey_> Wilco: I appreciate M Gower concern for side panel, i think it will be very tricky and time consuming to narrow down the language....

<bruce_bailey_> ... We are in CR so I have concern for level of effort with work needed for normative language.

<Zakim> Chuck, you wanted to formally suggest continuing review on Friday

<Zakim> alastairc, you wanted to say we'll pick it up on friday WCAG meeting.

<bruce_bailey_> GreggVan: Can phrasing about focus moving from object be a way to narrow the exception? That takes care of common issues like menus, since they have focus and give up focus.

<Wilco> Nope, notes aren't normative in WCAG

<bruce_bailey_> alastairc: I think this is a good topic to discuss on our Friday meeting. Adding a note might not be enough.

<mbgower> I would like to draw a clear distinction between "moving content" and "opening content"

<bruce_bailey_> alastairc: I have made some notes.

<bruce_bailey_> table discussion for now

Question 3 - Success Criterion 2.5.7 Dragging Movements (Level AA) #2705

<bruce_bailey_> https://www.w3.org/2002/09/wbs/35422/wcag22-misc3/results#xq16

<bruce_bailey_> https://github.com/w3c/wcag/issues/2705

<bruce_bailey_> https://github.com/w3c/wcag/issues/2705#issuecomment-1339197674

<bruce_bailey_> Chuck, will take Agree with adjustment first.

<bruce_bailey_> [reads Gundaula comment from survey.]

<bruce_bailey_> Chuck note Ian agreed with adjustment, but we don't have text in survey.

<bruce_bailey_> Chuck reads GreggV's something else comment from survey.

<alastairc> Gregg, which bit were you reffering to for "this discussed"?

<bruce_bailey_> GreggV: If user cannot drag, that is a problem many, many places and not a page specific problem for author to solve...

<bruce_bailey_> ... user will have AT or work-around from platform, such as long press. We assume end-users have screen reading software...

<bruce_bailey_> ... why are we not assuming end-user has way to drag?

<Zakim> mbgower, you wanted to say some of Gregg's comments are similar to priors by me; while the Understanding doc addresses much, I still feel like research is thin

<bruce_bailey_> Wilco: If press-and-hold solved by UI then this SC would not be a fail.

<Wilco> Maybe we should ask Google to an option for this into their browser? Since they asked :-)

<bruce_bailey_> mbgower: The space we are talking about, i feel like we can beef this up.

<bruce_bailey_> Chuck: We had suggestion from survey for browers to add feature?

<bruce_bailey_> alastairc: The type of AT we are trying to facilite with this SC do not assume sophisticated switch access. So trying to facilitate more mundane use of trackball style pointing deveices.

<Zakim> mbgower, you wanted to say I can address Gundula

<bruce_bailey_> alastairc: Gundala asked about compatibility with on-screen keyboards. Those keyboard are not usually a solution.

<alastairc> ah, that's better, thank you Mike

<bruce_bailey_> mbgower: Providing an input is not considered a keyboard-only affordance for end users.

<Chuck> proposed RESOLUTION: Accept PR 2828 and response to address issue 2705.

<mbgower> +1

<Ben_Tillyer> -1

<bruce_bailey_> Chuck: We only had three survey responses, but I want to get a sense of folks on call now.

<alastairc> You'd be accepting the response: https://github.com/w3c/wcag/issues/2705#issuecomment-1339197674 and the PR https://github.com/w3c/wcag/pull/2828

<Wilco> 0, sorry didn't get to it

<Detlev> +1

<ShawnT> 0

<Makoto> 0

<Ben_Tillyer> I'll switch mine to 0 from -1, was -1 because I didn't know enough

<ToddL> 0

<laura> 0

<bruce_bailey_> Chuck just asking for impression from todays conversation.

<GN015> -0.5 while I understand why the paragraph on text input is there, I still think it confuses the reader and distracts from the core of the SC.

<alastairc> GN015 - can you suggest an update?

<bruce_bailey_> Chuck: confirming that we need to revisit.

<bruce_bailey_> alastairc: please look at survey, it is still open

<bruce_bailey_> ... we will discuss Friday backlog call.

<bruce_bailey_> ... it is in AG calendar

<alastairc> https://www.w3.org/WAI/GL/wiki/Main_Page

<GN015> alastairc - I suggest to drop that paragraph.

<alastairc> https://www.w3.org/groups/wg/ag/calendar

<bruce_bailey_> ... this link is a bit of newer resource and updated today

<bruce_bailey_> ... we were missing some activities from w3c AG calendar but is recently updated

<alastairc> RRSAgent make minutes

<bruce_bailey_> chuck: Friday meeting is more a working call, popular forum for open conversation

<mbgower> https://github.com/w3c/wcag2ict/issues/6

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/problesm/problems/
Default Present: alastairc, Lauriat, JenStrickland, ChrisLoiselle, shadi, jeanne, MichaelC, ShawnT, JustineP, Glenda, Sheri_BH, Jennie_Delisi, mikayla, iankersey, mbgower, kirkwood, present, Chuck, Ben_Tillyer, bruce_bailey, Jay_Mullen, sarahhorton, Poornima, Laura_Carlson, jaunitageorge, AWK, Detlev, ToddL, Raf, Makoto, GreggVan, Francis_Storr, Jem, .5, joweismantel
Present: alastairc, Lauriat, JenStrickland, ChrisLoiselle, shadi, jeanne, MichaelC, ShawnT, JustineP, Glenda, Sheri_BH, Jennie_Delisi, mikayla, iankersey, mbgower, kirkwood, present, Chuck, Ben_Tillyer, bruce_bailey, Jay_Mullen, sarahhorton, Poornima, Laura_Carlson, jaunitageorge, AWK, Detlev, ToddL, Raf, Makoto, GreggVan, Francis_Storr, Jem, .5, joweismantel
Found Scribe: Sheri_BH
Inferring ScribeNick: Sheri_BH

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: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


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.)