Accessibility Guidelines Working Group Teleconference -- 26 Mar 2019

<alastairc> present?

<alastairc> 3. TPAC 2019 (https://www.w3.org/2002/09/wbs/35422/AGWG_TPAC_2019/)

<alastairc> WCAG 2.2 SC acceptance criteria and WCAG 2.2 SC readiness discussion

<AWK> +AWK

<Detlev> i can go first

<alastairc> scribe: Detlev

<scribe> scribe: Detlev

ACT Approval (https://www.w3.org/2002/09/wbs/35422/ACT-RF_CR/results)

alastairc: ACT was in survey, was discussed

alastairc; 13 people approved resources, for publication of note

AWK: 14 approved, one raised issues in github

alastairc: Are there any other questions?
... If not, issues CfC will be put out

CSUN debrief

alastairc: hands over to AWK for debrief

AWK: Minutes have been posted, some from may 11 still missing but will be added
... lots of good discussions, first focussing on Silver requirements

<JF> agneda?

AWK: will return to remaining requirements next week (Shawn and Jeanne not present now)
... also discussions about Charter related to Silver - there is a lot more to do on Silver, WCAG 2.2 will heppen because timeline for Silver is still quite far out
... for Silver we will include ATAG and UAAG which will extend the time line

Ryladog: Scope of Silver up to now did nit include ATAG and UAAG and any new technologies so this was decided to have included

AWK: There was discussion of new Techs but it was unclear if Silver would squarel yaddress these

<Ryladog> Scope of Silver was expected to include UAAG and ATAG requ, but that was missing from what was presented at CSUN meeting

AWK: spent some time on Technique sand Understanding docs, but more time was spent with Silver TF and discussions of Charter
... any additions?

<JF> +1 to Alastair

alastairc: As to Ryladog's question, it wa sseen as included in scope but not in the initial publication

David: The Silver team intended to get something ready by 2020, would then address new techniques

<JF> +1 to David's recollection

David: Judy warned that Siver might be seen as a rewrapped WCAG 2, so better do something different
... There is no deadline yet for Silver

JF: Agrees with David's perception - focus on 2.2 would focus more on testable statements - ACT TF is focussing of working on testable statements / rule sets
... These rules should be able to move into the Silver framework

AWK: Noticeable that progress has happened: ACT, Silver, new work on 2.2 - still a lot need sto be done, need priorities and eyes on the big picture

<Ryladog> +1 to JF

JF: Big take-away that the really hard issue is the conformance model for Silver
... increased emphaisis on user testing and what that means for the conformance model - the methodology for that is a thorny issue

alastairc: That needs a good answer before content is written in a serious way

David: compares it to building the Canadian railway - how to clear the Rocky Mountains, had studie sbeforehand to set strategy

mgover: WCAG 2.1 needs still a lot of work, just reminding

alastairc: Some stuff still from 2.0, one big backlog

mbgower: There is still a lack of guidance for the new SCs in 2.1

<Rachael> +1 to face to face meetings.

Ryladog: Meeting in person was useful, many interesting things learned

JF: Had an idea related to a charter discussion - there was a huge need for divide & conquer, Mike mentioned 'packaging issues' for 2.1 - would it be valuable to create a new TF called "Technical Requirements" TF to guide the process?
... with focus on packaging, interrelationships of rule sets

alastairc: would that continue the work of ACT TF?

JF: it would be related, but addtional - would look at integrating ATAG and UAAG, looking at working list of SCs left on the table etc.
... so we could continue to publish rules for the rule set

alastairc: Puts it down as discussion point - you could come up with many rules, the overall question is how it relates to meeting a guideline

Shadi: In the ACT community group / TF started with SCs, the interesting thing was defining the test cases, so more a bottom-up development

JF: One issue was the amount of work for the AGWG - so it might help parcelling out more technical work

Issues survey https://www.w3.org/2002/09/wbs/35422/technique-approvals9/results |

alastairc: will discuss with AWK and MichaelC

TPAC 2019 (https://www.w3.org/2002/09/wbs/35422/AGWG_TPAC_2019/)

alastairc: next TPAC will be in Japan, in September
... there is a survey eliciting attendance options, please respond

<Zakim> bruce_bailey, you wanted to request monday / friday (!) for WG meetings

JF: Silver meeting is a AGWG meeting

Bruce: suggests Mo/Fr for AGWG meetings

MichaelC: possible but may not be smart

Ryladog: Tues/Thurs is days for AC meetings so you miss half a day

JF: allocation was likely down to room planning, 2 day blocks

alastairc: will use survey to plan

<bruce_bailey> thank you

Issues survey https://www.w3.org/2002/09/wbs/35422/technique-approvals9/results |

WCAG 2.2 SC acceptance criteria and WCAG 2.2 SC readiness discussion

alastairc: This is for WC 2.2

<alastairc> Working process: https://www.w3.org/WAI/GL/wiki/WCAG_2.2_working_process

alastairc: We were looking at that 6 weeks ago - process came out of last TPAC
... has been iterated in discussion with TF facilitators
... there is an initial list of SCs (18) (link on page referenced above)
... Structure:What is SC trying to achieve, then draw up list of people working on the SC, one of them should be familiar with writing WCAG SCs
... Then we will prioritise SCs, order them (which ones come first)
... go through a review process in telcos over couple of weeks, then decide whether SCs can progress or put in the backlog
... Process relies on people being willing to put in initial work on SCs
... amy questions about that?

<alastairc> Acceptance criteria: https://www.w3.org/WAI/GL/wiki/WCAG_2.2_Success_criterion_acceptance_requirements

alastairc: Other aspect is the acceptance criteria
... is based on 2.1 version of acceptance requirements

<alastairc> Diff version: https://www.w3.org/WAI/GL/wiki/index.php?title=WCAG_2.2_Success_criterion_acceptance_requirements&type=revision&diff=10158&oldid=10103

alastairc: there are additions: "consistent result by different testers"
... There was discussion of time needed for testing on COGA list
... (talks through doc referenced above)

<Ryladog> +1 to Glenda - NOT Time Limit on Testing

Glenda: Not comfortable with "take a few minutes per page" - time limitation should be removed. Having that as requirement, some of th ethings that we now have would not have happened

alastairc: trying to avoid the discussion had on 2.1 where some SCs did it make it

Glenda: For more more complex sites the time limit is not realistic
... consensus may that somethong cannot get in if it takes hours to complete

alastairc: The aim was to define the reasonableness of SCs in terms of time requirements

Glenda: can we have a straw poll to see how long things take testing?

<JF> Reasonable time to test is directly dependent on the tester - their skills, any tool s they have, an specific disability that an evaluator may have

<Zakim> JF, you wanted to ask about "web sites" language

JF: Dependent on individual tester so agrees that threre should not be a time limit - is it pages - that model is becoming antiquated, thinking of screens rather than pages
... so that may be covered in change of language
... so the web page definition should be extended, page concept getting more difficult

<Zakim> bruce_bailey, you wanted to mention disconnect between tests being site oriented but testing time be few minutes per PAGE

Bruce: few minutesper page or SC incidence might be OK but it depends on the page length / complexity

<Glenda> +1 to what Bruce said :)

Ryladog: Why do we have this discussion? People with disabilities will often take longer

<bruce_bailey> “take a few minutes per page” should be something like “take a few minutes per instance or test”

Ryladog: there should be not a time estimate, seems out of scope for what we are doing

<bruce_bailey> bounding by time limit for a page is not feasible since the size of pages is not bounded

<jon_avila> Our goals should be solve problems for people with disabilities not catering our tests only for that are easy to test. Testing for Flash thresholds is very timing consuming -- would we drop that?

<alastairc> Suggesiton: "Be feasibly testable through automated or manual processes, and any tools required to test it are available prior to Candidate Recommendation stage."

Ryladog: Not sure we can change the language, would be a completely different paradigm
... time limit on testing is absurd

<bruce_bailey> example: testing a *logo* for sufficient contrast in a few minutes is feasible

<bruce_bailey> example: testing a *page* for sufficient color contrast could be *hours*

Shadi: The measure on timing should include not just complexity but the purpose of testing - is it looking at Pass/fail, does it focus on improving the usability

<Chuck> scribe: Chuck

dm: Some context around whole page, may help brainstorm. When we first talked about wcag, we were concerned about a "page", and we came up with "web units". got quickly shot down.
... "horsepower" between cars and horses had new meaning. We came up with "web page", definition of it could include many screens in page. At URL level.
... When wcag em, idea of sampling, "... you can't say that!". We didn't have a methodology. EM formalized it. Good work by that team. Public accepted it. No complaints from any source.
... Showed me that if we did something reasonable, could be passed over, we may have flexibility in expanding something out or making clarifications or do something around that.
... That's some info to see if we can do something with it.

<Zakim> AWK, you wanted to suggest that we indicate "an automated or manual process conducted by an individual"

ac: Bruces comment about remembering web units dying long slow painful death.

awk: I see the challenge of assigning a time frame because of variations in familiarity/abilities/tools. Are we trying to say: Can be feasibly tested through a manual or automated process by an individual?
... Are we trying to say "by an individual"?

<shadi> [[also manual processes have different *purposes* IMO]]

ac: That might also be a good thing to include. I don't think it was the intention was to talk about usability testing (may be a false assumption). I don't want to pick on any sc we worked on in 2.1.
... There were arguments about how unfeasible some of the criteria could be. I didn't want to go through that discussion again. For setting a bar or yardstick for us to look at to determine if we can agree or not.

<alastairc> Be feasibly testable through automated or manual processes, and any tools required to test it are available prior to Candidate Recommendation stage.

ac: and why not. Will paste in...
... We might want to seperate into 2 bullets. If we don't have the time aspect. We could add in "conduct by individual".

<Glenda> I’m satsified with “feasibly testable”

<alastairc> "Be feasibly testable through automated or manual processes by an individual, and any tools required to test it are available prior to Candidate Recommendation stage."

Katie: There's this wierd thing in the future that lots more can be tested by non human. Text may not have long-gevity

awk: I don't think we want it to say "we reject" because of what may happen in the future. We want it to be out of sync for a short of time as possible.

ac: Glenda posted in... Does anyone have issues with that phrasing? <pasted in>

shadi: I think the notion of purpose, is it just to spot even if for manual process? There's still different purposes why you are testing, impacts effort.

ac: It does. Feasible is probably a vague enough word.

awk: Feels tricky. If testing was onerous but was the only way to make sure users were able to get to the content, we would need to be more flexible. Where-as if it's something that's a good idea...

<shadi> [["making sure people can access the content" is a purpose IMO]]

awk: but not viewed as impactful, it may be that our collective tolerance for onerous it is varies. Ultimately there is a subjective aspect: People reviewing the spec use when doing the review.
... I don't know if we can do better than "feasibly testible". We can't time box it, other things we can't do. For good reason.

katie: Why isn't "testable" ok?
... If you make a requirement, has to be testable.

ac: From previous discussions, if a new sc took longer to test on average the all of the others, would create a problem...

katie: No, should not be part of what we do. What may take a long time today may not take a long time down the road.

ac: But if we publish it and it takes twice as long to test....

<Glenda> I can’t find my unmute button

katie: I understand that, but requirements are that way. You either follow it or you don't. I don't think it's relevant to the work we do. It just has to be testable.

<Glenda> so I will type

<Glenda> I think onorous is a problem

katie: These requirements are for the outcomes, not to make it easier to do testing. These are user requirements for people with disabilities.

<Glenda> And my thought is I like “feasible”. And if we want a time limit…say it can’t be longer than double of what we already do.

<Glenda> (go with a percentage of what we already do for time) but hey..I’m happy with feasible.

ac: Should we... let's get mike up.

<Zakim> mbgower, you wanted to say that feasibility has to enter into this at some point. If something can be tested by an individual after a year of effort, it may be testable but it

mike: Feasibility of testing has to factor in at some point in time, if it takes a year to test, not a feasible method of testing. Whether we specify a time or not there has to be a notion of feasibility.
... Can we get away with "feasible" and not qualifying it?

<Zakim> JF, you wanted to say that it takes 3 hours to ensure an audio description of a 3 hour movie is correct...

ac: chair hat off. In my line of work, I help companies understand how to do accessibility efficiently. If you don't do that, they won't do the work.

<mbgower> note that what we have is an example of feasible, not a definition

jf: This discussion happened on coga. Reqs on audio description is that it's accurate. To make sure it's accurate on a movie, takes 3 hours. I'm concerned that time is even on the table.

<jon_avila> +1 to John, Katie, and Glenda -- testing for flashing in a movie could take hours as well -- would the group drop that?

jf: If we introduce "feasible", what is "feasible"? If it's a squishy word, it's meaningless. Maybe to me but not Mike. Who's right?

Mike: ME!!!!

ac: The question would come up is if the group accepts a sc, and some of the reasons for not accepting it is because of how difficult it is to test. I know "feasible" is a squishy word. that might be helpful.

<AWK> 3 hours to test a 3 hour video is reasonable as it is relative to the effort of producing the content

ac: If you have a 3 hour movie, that's a pretty high production budget. 3 hours to test a simple text page, that's not reasonable because overall budget was much smaller.

<AWK> And testing live captioning for an ongoing stream takes an unknown amount of time

<alastairc> q/

<mbgower> I think it is good to include the idea of feasibility. We definitely apply it as part of our assessmnent

ac: "Feasible" is squishy, but is that helpful for us?

awk: If not, how do we define it? What do we put in that is reflective of the desire for reasonableness, non-onerousness. What level of accessibility is achieved.

jf: Others may be more focused. In section 508 there is "undue burdon", where they define the lines. If lines are crossed, it's an "undue burden". Maybe katie or bruce has additional thoughts.

<jon_avila> in CVAA they have a term achievable. If you claim non-achievable then you have to take into account the reasons of why such as overall resources, etc.

ac: that's a concept that's also in the EU regulations.

katie: We are a standard, regulations will use a standard. I don't think we should go that rout.

ac: They do use wcag 2.1 as a basline. Determining what content author is responsibile for.

jf: "undue burden" about what is reasonable. I'm not saying we take it whole cloth, but the language has been used before.

katie: "Cost", and it's a great way to get out of everything.

<AWK> Undue burden:"Undue burden means significant difficulty or expense" https://www.ada.gov/reachingout/l2factors.html

dm: In terms of legal-ness, these are requirements (a req doc is what we are talking about) "reasonableness" is not a bad word. We use it in lots of places.

<JF> FWI, "the amount of time" is, in many way "the cost of testing", where time = money

dm: I think we need to have something in there. I agree that if we make the wcag take 2x or 3x long to do, it won't be the same standard, all the framework, legal entities, consensus, would be they have to start over.
... We try to do that with audio description in 2.0. Some just exempted it. Luckily as Katie said, price has come down in 10 years. Maybe that will happen in the future.

<jon_avila> we have a slippery slope then as you have to look at all SC as a collective and multiple medium time consuming tasks combined add up to a lot.

dm: If we are doing 2 year cycles, we need to be more focused on the more immediate future.

<Zakim> mbgower, you wanted to say "how do we test that?" was a frequent phrase when we discuss whether an SC is acheivable in 2.1

mike: Bearing in mind that we are trying to define acceptance requirements for something. Definitely in the discussions I've been involved in with 2.1 sc's the degree of feasible came up every time.
... I'm completely fine taking the example. "Feasibly testible" is more honest. Whether or not it meets that bar. We discuss in the context of that sc what the group thinks is feasible.
... We don't have to define "feasible" any more than we have to include it in our process.

<alastairc> Any update to: "Be feasibly testable through automated or manual processes, and any tools required to test it are available prior to Candidate Recommendation stage."

Chuck: You guys are inventing a lot of new words that are hard to type.

awk: I added in "by individual".

ac: Refreshing

<alastairc> "Be feasibly testable through automated or manual processes by an individual, and any tools required to test it are available prior to Candidate Recommendation stage."

bruce: "by an individual" as opposed to "by an automated process"?

<Ryladog> I can live with Alastairs language

<jon_avila> I would say something that requires AI to test would now not be reasonable since most people don't have those AI tools now

mike: How does that differ from "manual process"?

<Glenda> recommend changing “by individual” to “by an individual evaluator”

awk: Is it a manual process to invite 7 people in a room and evaluate their reactions to something?

<KimD> @AC - aren't we also breaking into 2 sentences?: Be feasibly testable through automated or manual processes by an individual. Any tools required to test it are available prior to Candidate Recommendation stage.

ac: Glenda's clarification may help with that.
... No one's commented on second half. It could be a second sentence or separate bullet, but they are both on the topic of testing.

bruce: do you want to say "not only be testable through user testing" or that "user testing not be required for evaluating sc"? That's drawing bright line in sand. That's what I'm hearing.

ac: How to include usability testing is a big topic in silver. Never been a requirement in WCAG 2.x.

bruce: True.

<jon_avila> the idea is that 8 out of 10 experts testing should get the same results

ac: Thought it was obvious from another aspect, may have been just a ....

<Zakim> AWK, you wanted to say that perhaps we can remove "feasibly" and add "Not require testing that are believed to require very large manual efforts."

awk: I suggest... based on what people were saying, I updated #2.
... ...and any tools. I suggest we remove "feasibly", and add what I put in here...

<bruce_bailey> +1 to what AWK is saying

awk: We can bring it up, will cause discussion. Our intention is that we keep the amount of testing "reasonable".

<KimD> +1 to AWK's suggestion

ac: Does anyone disagree with Andrew's suggestion?

<Detlev> +1 I am easy, let's move on

ac: I'm happy with that approach.
... That's bullet point 2 out of the way. Any comments on the others? There weren't that many additions to the actual requirements.
... We have an extra "should requirement".
... The rest of that is similar to how the page was previously.
... Feels like this will be something we put into a survey or cfc. Think survey is best.

Issues survey https://www.w3.org/2002/09/wbs/35422/technique-approvals9/results |

ac: Everyone happy with the process requirements? I'll put up for official approval, and move on.

awk: I would like to point out that is different from before, the third set of bullets. <reading> Designed to avoid some of the problems we had with 2.1. We put things in, took things out, not everyone was happy at each step.
... It has a collection of things that keeps it grounded in reality. when we get to CR and implementation, we are not looking for implementation of all items, ... which is much more manageable. We won't be a year out saying
... We need techniques, we need understanding. The idea is that the wg could agree on.... won't show up in editors draft until other pieces are in place.

ac: should help

awk: Doesn't help with quantity.

ac: results of the questionaire. Mostly issues.

awk: Can we take up item 6, which will be 2 minutes?

scribe sign ups for future dates

awk: <reviewing open dates for the excited crowd)

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

Chuck: scribing is fun!

<conversation about scribing and guilt.... :-))

dm signed up for 9th.

ac: anybody for 2nd of april?
... Jakes in for 2nd.

dm: I'll take 2nd with Jake.

awk: I'm updating as we go.

ac: clashing on updating wiki is nice problem to have
... Everyone else, please review page and pick a date.
... Back to results from questionaire.

awk: Would you prefer if we ask you to scribe on this day?

<bruce_bailey> thanks chuck for scribing

<Detlev> Does "5. Two independent implementations on web pages that actively meet the Success Criterion are available." rule out N.A. (remember we had trouble finding active examples for things like 2.5.4 Motion actuation)n

<bruce_bailey> * it is also hard for me to know much in advance if I am situated for scribing

mikec: It would be good to share the responsibility.

ac: At least next week's covered. In survey...
... We had some unanimous. Relatively safe.
... We are on topic of the survey.

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

Issues survey https://www.w3.org/2002/09/wbs/35422/technique-approvals9/results |

ac: We've got clarification for "label and name interpretation". Everyone who looked at it accepted it as proposed. Thanks to Mike for work on understanding docs.
... We also had a typo in understanding ... where "not" was missing. That was item 3.
... Item 4 was applicability of text spacing.
... Item 5 I think everyone agreed that wording for 3.1.2 "specifying language" ... the requirement for correctness comes from the logic of the statement. Those ones seemed fairly clear cut.

<bruce_bailey> happy to accept

ac: Is everyone ok to accept all these? 1,3,4 and 5.

<Zakim> bruce_bailey, you wanted to shout out to Mike G on math example for lable in name

<alastairc> q/

<MarcJohlic> +1

bruce: Happy to accept. Thanks Mike for doing great job. It's now great.

<JakeAbma> +1

ac: Excelent.

Mike <being humble>

RESOLUTION: Accept items 1 3 4 and 5 as proposed due to unanimous concent.

<alastairc> https://github.com/w3c/wcag/issues/593#issuecomment-471223953

ac: The 2 which didn't. Topic "clarification on user components for label and name", issue 593.
... Laura ... wondering if that was a mistake, but Laura is not here on the call to discuss.
... in which case I'm not sure what Laura's changes would have been.
... Did anybody else have a comment on that?

katie: On #5?

ac: #2, issue 593.
... Where you can have multiple labels per input I think.
... Andrew's proposed response...
... To me that is clear.
... Any objections to that response (link above)?

RESOLUTION: Accept proposed response to issue 593.

ac: The last item, topic H42 missing appropriate hierarchal level condition was accepted apart from david's comments about discussions during wcag 2 about adding heading level accuracy.
... wondering whether we might check to ... david?

dm: A comment that... I remember that there were big discussions about hierarchal headings. My understanding was that the compromise position was that headings are required (looks like, should be)
... Level of heading doesn't need to be accurate. That's my understanding of where we came to when we wrote this sc. We did throw bones to... we have some "should's" in there.
... My understanding was that h-levels did not have to be accurate.

katie: Accurate is a different story than... "accurate to the content". Appropriate nesting has also never been a requirement. We did not agree on "hierarchal".

awk: In noting that's what we had for aria one, it felt like the same for h42. I think it's still ok that we ask the author to look at headings and determine accurate heading level.

dm: If author decides that content should have only h2, then "ok". wcag 2.0 doesn't make the determination. Author decides, we do expect symantics are aligned with that.

awk: kind of a "do nothing" check. Based on honor system.
... In this case these 2 techniques are synced up, and we inspire author to think about heading levels.

jf: Whenever we use h2, h3, h4, it's short hand for role and aria. One of the problems we had in the past is when the use case was blogging platforms, when you put content together from multiple sources.

<AWK> https://www.w3.org/TR/WCAG20-TECHS/ARIA12.html

jf: Pulling stuff with different heading levels. The ability to change it around was really complicated. Hierarchy piece is really nice to have but impossible to enforce.

awk: You suggesting that it shouldn't be there or it's ok to be there?

<alastairc> The core question from the commenter: https://github.com/w3c/wcag/issues/655#issuecomment-474107172

jf: It's ok, but falls to honor system. Despite best intentions, you may not be able to preserve hierarchy, but if you preserve heading, that's good. It's more an honor system thing.

ac: Pasting in core question from comment.

<alastairc> "We are currently updating the government web accessibility testing methodology. Until now this testing methodology require to use correct hierarchical nesting so we need to have some sort of official position of the working group on this subject to be able to decide to drop it or not."

ac: They have hierarchy headings at the moment. Q is if they should keep that.

katie: They can make it a goal?

awk: no position from wg.

ac: That's what I'm trying to get a sense of. Do we agree it's a "should" but not an absolute requirement from guidelines?

jf: "Strongly worded" should. Best practice. But not a failure.

ac: David, you happy with that?

dm: Kind of "nudge nudge wink wink". Imagine in court... "did you meet wcag"? "To the letter". But you SHOULD have put in hierarchal levels.
... You are flagging failures if heading structure doesn't make sense.

glenda: Requirement for failure if heading structure is complete scrambled eggs. If hierarchy is in place but there are levels skipped, we pass that (though not best practice).

ac: Not strict, but if you can draw some line between how it's presented or structured and it makes sense....

dm: This is a little bit about "alt text". We started out with a pure decoration... back in the day, coming out of the gate, definitioin of pure decoration was that it had no information
... We are probably seeing a little bit of that here too. There's a gradual understanding and acceptance.

ac: In terms of issue raised, h2 lines up with aria. Any objections to that?

<JF> no objection

dm: I can live with that. Purest shudders, but ok.

RESOLUTION: Accept pull request 664.

ac: That brings us to end of agenda.

awk: If we don't have proposed response, and if we have 5 minutes, can we write one?
... "thank you for the comment, we have added to h42 to align with aria 12"

<JF> +1

<alastairc> +1

ac: That seems like a reasonable wg response to me.
... any objections?
... No objections. Any other q or comments?
... We have silver requirements on agenda next week. And one technique from 2 members.

trackbot, end meeting

- DRAFT -

Accessibility Guidelines Working Group Teleconference

26 Mar 2019

Attendees

Contents

ACT Approval (https://www.w3.org/2002/09/wbs/35422/ACT-RF_CR/results)

CSUN debrief

Issues survey https://www.w3.org/2002/09/wbs/35422/technique-approvals9/results |

TPAC 2019 (https://www.w3.org/2002/09/wbs/35422/AGWG_TPAC_2019/)

Issues survey https://www.w3.org/2002/09/wbs/35422/technique-approvals9/results |

WCAG 2.2 SC acceptance criteria and WCAG 2.2 SC readiness discussion

Issues survey https://www.w3.org/2002/09/wbs/35422/technique-approvals9/results |

scribe sign ups for future dates

Issues survey https://www.w3.org/2002/09/wbs/35422/technique-approvals9/results |

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output