Accessibility Guidelines Working Group Teleconference -- 23 Oct 2018

<alastairc> zakim clear agenda

<alastairc> zakim close item 1

<AWK> https://www.w3.org/WAI/GL/wiki/Meetings/TPAC_2018

<Zakim> bruce_bailey, you wanted to ask about 2.5.4

TF updates

<gowerm> scribe: gowerm

AWK: We don't have Jim here from LV or Lisa from COGA, but Alastair is. So, Kathy, Alastair, do you want to talk about challenges? Do you have clarity on what TFs are supposed to be doing?

Alastair: LV is easier to start with. They are trying to contribute to techniques. in terms of active work, it has died down a bit.
... I would appreciate something to focus on.
... I asked about 2.2 and most things they've deferred to Silver
... COGA has lots of work they're trying to do at the moment. Documents such as gap analysis and policy-maker guidance. They've made something like high quality success requirements., e.g., 'you should use spacing in appropriate ways'
... That's a 100 page document.

JF: Is there something that could be pulled into 2.2
... At one point there was a catch the bus or wait 10 years perspective.
... Is there something?

Alastair: Web authentication comes to mind.

<Rachael> +1 JF

<alastairc> https://w3c.github.io/coga/content-usable/

Rachael were there others?

Rachael: I think there were 4 or 5. I'd have to look them up.

<alastairc> https://w3c.github.io/coga/content-usable/

<david-macdonald> http://tinyurl.com/jmo9st4

David: I have a list of SCs that didn't make it

Alastair: We don't need to tackle that right now. They've produced the document I've just pasted it. It does need more review but is shaping up.
... For Lisa's benefit, we're just talking through COGA's work of the last few months.

<alastairc> https://raw.githack.com/w3c/coga/master/requirements/index.html#introduction

Lisa: I'm here about 20 minutes or half an hour.

Alastair: I just gave a quick overview of the 3 documents COGA is working on. The quesiton was, from the WG perspective, how is the TF going?

Lisa: We're interested in recruiting.
... People got very disillusioned, but I think it's important we publish. People can see benefit even if it's not what they were hoping for.
... I'd like to have a face to face in the new year.
... We promised people there'd be guidance available.
... Getting some guidance that people can follow, and being able to show that to people... There are people who want to contribute.
... People make content for this audience and they want some guidance. They don't necessarily need legislative stuff. They just want to know what to do.
... A gap analysis... We got some negative feedback that people found it very confusing.
... We thought we'd separate them out. There will be w3c info but we thought we'd also provide for developers who aren't familiar with that jargon.
... We think if we publish stuff, that's really helpful.
... We're not working on requirements so much.

AWK: We have a queue

Jeff: Before Lisa goes into talking about what SCs might be ready, I wanted to encourage chairs to have a clear path on what has to be done, when.
... In terms of supplemental guidance. In terms of 2.2. I believe the COGA group found the time pressures difficult last time. Now that the pressure is a bit less, I'd like to know what the plan is to get some COGA stuff done.

Rachael: We had a number deferred, and many have value. We'd need to go back and see wants still capture user needs. Lisa are you still open to reviewing the deferrred SCs for 2.2?

Lisa: I think we are willing to do that.
... Because we've been pointing out how much that didn't get done... Some folks put in effort to try to get it in... I think we want a process that is also inclusive.
... We want to give people from COGA a chance to get in on the call.
... We want to bear in mind the benefits of the user.
... We want to get in authentication
... But we also want to get understandable language. I'd like to have a conversation on how to get that into requirements.
... If we get one in of the difficult but really important ones, I think that will go a long way to reframing

JF: I wanna do a wrapper and also reconfirm some of the things that have been said.
... I was one of the people who pushed for a regular update of the standard.
... We had these TFs that came forward who wanted it all and wanted it now.
... We had to leave a lot of things on the table that caused consternation in some quarters.
... I think we need to go back and pull some of those things that were left behind... It was always in my mind that as soon as 2.1 was done, we got to 2.2. A regular cadence and publishing cycle.
... I feel strongly that that should still be the case.

Lisa: I want to get back to the extention model.

<JF> -1 to returning to an extension model

Lisa: What is appropriate for a dot release.
... If we write extensions for COGA, then legislators can decide where to include it. Make it easy and simple.
... Let the policy makers struggle with how to adopt it. Let's make content and how to make it usable and not work on making laws.

AWK: So I think this gets us well into the next normative work section. I do want to focus on what the TFs are doing or not doing.
... Lisa can you mute when you're not tlaking?
... Thanks. What I"m hearing from this discussion here is that one of the things we want to get that will help us with 2.2 or Silver is clarity from the TFs are what items they feel are ready for the next round of work.
... that will involve looking at what was deferred and carrying out an assessment of what could make it into the next round.

Kathy: The Mobile TF has lost a lot of momentum.
... We'd need new participants. We are down to Detlve, me Kim and a few others.

Detlev: Jake and Marc

AWK: We're going to shift gears, because the ACT folks are here.

JF: I do want to be on the record of opposing an extension model.
... My concerns around ghettoization remain what they were two years ago.
... Have we thought about setting up new task forces?
... I'm thinking AR/VR. Are there any needs in that space. And IOT. Voice input and interaction. I think there's a lot of furtile ground out there.
... I'm loathe to use the word 'incubation' but I thought I'd toss that out.

AWK: We don't need to wait for a new charter to make new TFs.
... We don't want our main purpose to be to make TFs. Before we make more, I think for an AR/VR we'd want to follow the same model.

<Zakim> JF, you wanted to ask about future task forces

AWK: The question is what do we want form the TF groups we have currently. Kathy says they need a reboot. COGA is working on documents that are similar to supplemental guidance. LV is working on techniques.
... We need to be clear of what we expect from the TFs, and what is realistic.
... That's where I find myself wondering what the best structure is. For the sake of clarity for TFs, maybe it's to define user requirements.

Kathy: You don't think drafting SCs? It's one thing to have the user requirements. It's another to draft SCs.

AWK: I'm asking the group what their role should be.

JF: I think I'd like to hear what the TFs think the next SCs should be.
... We distilled the need for personalization down to something we could use as an SC. I like the model that the TF brought material to the WG which was then chiselled down to polished rocks.

Kathy: What's helpful for the TF is to stay ahead of the working group.
... If we can be getting the user requirements and doing the research and prepping for 2.2...

<JF> +1 to Kathy

Kathy: Then the WG can be doing techniques. The TFs looks at the next thing.

Detlev: My perspective is that work should be going into shoring up 2.1 by finalizing techniques. I'm reluctant to spend time thinking about new SCs when we are still dealing with these 2.1 ones. Things come up when doing techniques.
... That can help inform what we need to do next. I'm not sure we have to be pushed to find new SCs. My feeling is we should take a step back and make 2.1 a good thing.

David: I'm looking through the SCs as possible candidates.
... Under our current requirements, I think we made some really good decisions.
... We increased WCAG by 33%.
... The implications of our new SCs are huge. If we want to see it adopted well, we wanna have the same level of quality in 2.1 as 2.0. I want to echo Detlev.
... Let's try to make 2.1 all it can be.
... There may be a 2.2 out of that -- a cleanup of 2.1. It may be clean ups of wording.
... I think the next big move is: do we want to decide if the principles firming up in silver are tenable to the group?
... I think those two things are what we should pursue.
... There are a few that may be candidates.

Kathy: The focus of some of the SCs got changed. I think there's some benefit to go back and see what got left behind. We had real time constraints. Many got pared down quite a bit.

JF: That's what I was saying earlier.
... There was a promise that stuff that didn't make it wasn't going to languish. Technology is moving at a brisk pace. I appreciate the balance between quality and timeline, but new stuff is needed.
... As new technologies are emerging...

AWK: Chair hat off, but not terribly so... The gap analysis is something that was a key tool in the first process.
... It probably should be updated. It shouldn't be a big lift to get updated. From the gap analysis comes a few things. We do have a commitment to work on supplemental guidance.
... If we can set the parameters around what that needs to look like... hopefully not 300 pages. A natural outgrowth of that process should give us a list of things that are closest to being ready.
... If we focused TFs around gap analysis and making SC proposals, that would be a nice constrained focus.
... I do hear what Detlev and David said about techniques.
... By the end of the year I'd like to have techniques in place for all the SCs. If we can focus the WG -- and the TFs can be part of that...
... The gap analysis will help us understand if we need a 2.2.

Kathy: Can we clarify the work flow? It seems like work is being down in the WG. We need to have process in place.

AWK: We've improved the process for technique reviews.

<alastairc> scribe:alastairc

<JF> scribe: JF

Detlev: concerns over some of the emergent Techniques, concerned that the speed is impacting quality

<david-macdonald_> scribe: david-macdonald

AWK: some suggestions that we have crisper requirements before something is included: requirements, techniques, the whole package

Detlev: believe that a TF has a first review, but the skills of the people in the larger WG may be somewhat lacking

<david-macdonald_> Detlev: the skills and the number of people attending the working group were not ideal for assessing the quality of the techniques. There is no experts on the group with the vice sensory experience. Sometimes it's better to put a big working group because it is a higher chance of somebody will be able to provide valuable information that we would not get in the small groups

<david-macdonald_> I want to put down the work that we've done but sometimes I think the better if we had technical experts

Better that our requirements get out to the larger group earlier, to get wider review if we had presented ideas earlier

KHS: agree with David and Detlev that we're not done with 2.1. We need to get everything completed

we still have some issues. We need to complete the existing set

but I also like the idea of continuing a gap analysis, and then doing a better job that things don't get dropped at the last minute

<david-macdonald_> Katie: I agree with David and Detlev that we are not done 2.1. Let's completed so that we can help people understand what these things mean. So we need to be able to complete this make sure we have it right. Let's go to a gap analysis also into a solid job of not letting things drop because we only have three minutes left.

<david-macdonald_> test

scribe?

<david-macdonald_> scribe: david-macdonald_

AWK: move on to the ACT come back to this later

Shadi: let's write the testing rules first and then build the techniques off of that

JF: would it be parallel to do the techniques and the testing rules

<JF> +1 to shadi

Shadi: writing testing rules is very complicated and specific.

AWK: If we had some sort of a rules framework could be easier is free to move forward

ACT TF

AWK: we'd originally scheduled the ACT for 9 AM so let's move to that

WILCO:

<Wilco> https://w3c.github.io/wcag-act/act-rules-format.html

We are going to show accessibility conformance testing rules format 1.0

Wilco: brief description of the document. We are figuring out a way to harmonize accessibility testing as a lot of people do accessibility testing a lot of people are disagreeing on what WCAG actually means

They're all much of reasons for that but what we set up to do is to harmonize some of that work. Where doing that in a number of steps

The ACT rules format is designed to give a set of requirements on how to write your rules for testing accessibility. There are lots of automated testing tools there are a lot of test procedures compare so you can think of something like the test of testing program with precise testing procedures. Finding a way to document that in a way that we can all use we can all understand and that with this format is meant to do.

As we've been working on this for about two years now if we go through the document there are quite a number of changes since last time I spoke to you. So basically the scope here breaks down what technologies or writing rules for. Lots of organizations have internal requirements best practices use these requirements so it's not just WCAG as long as it applies to the eighth technologies and you ACT rules format should be able to work it's not[CUT]

There are atomic rules which are very specific pass fail.

There are composition rules where you could past success criterion by doing one or two things so they are two separate.Dominic rules in the comments a rule check that you have one of these two if there are options on how to meet a success criterion

The rule structure. In section 4 we have act rule structure. Title, unique identifier, rule description, rule type,(atomic or composite) accessibility requirements. So are we getting success criterion I can be satisfied. Etc.

The applicability is where it really happens this tells you within a page whatever thing you testing the development attributes or components you might be looking for. These are things we want to say something about.

Then there are expectations which are statements which should be true about the applicable elements

Then we have examples. Section 7.2 is why were not going into CR. Accessibility requirements mapping. This is the last snag we ran into. How do you describe this list. Should it be freeform or discrete. In WCAG it's fairly straightforward. The success criterion are satisfied or not satisfied. But there are scenarios for silver where you might have scoring and whether or not we want to take that on is still?.

Katie: you want to build and the ability to scale, why not leave that wait till later and we can amend that when the time comes.

Kathy: and none of those silver principles have been agreed upon yet

Michael G. Is there a partial category also?

WILCO: most of the time partial passing of a rule means you need further testing for the success criterion

Kathy: have you thought about machine learning in this because it is not necessarily a pass or fail?

<Detlev> -q

wilco: when you get machine learning is always a probability that you will always be able to make a pass with this probability. That's not strictly part of the format itself. But rules are written to be hundred percent accurate.

That flexibility is not there.

JF: I just wanted to confirm or continue on the point that Mike made. The rules are at the nuclear level of performance is at the page level. I could have 10 images on the page I'm partially conforming if I have 10 images where nine of the images have all text

For rules what we decided to use was pass fail not applicable

Who rules map to success criterion which can be satisfied or not satisfied. Another step up this is a conforming or is it nonconforming. So you can conform with not all of the success. Satisfied if you have a conforming alternative. There is a layering in their.

JF: the reason I ask is that in the night it states that VPat document. Meets with exceptions or partial conformance. Is there some sort of a mapping there and how these rules would fit into that ecosystem?

They have this notion of partial conformance. They may be feeling elements but might still be a conforming page but at this level it's pass or fail at the element component level and how you aggregate those results and allow some sort of partial solution that's not directly part of this framework of this rule is for men.

WILCO: that's something that we definitely kept in mind

Detlev: is there a tangible benefit in actually looking at this will format before we put out a draft of techniques.

Wilco: the techniques are slightly different than what the rules

Shadi I from what I'm seeing in writing rules were getting into very detailed specific in trying to understand what was actually meant by the success criterion. And we do recognize that some things are not well defined. For since we have not defined what standard keys are. :

What elements to the me in HTML that fallen scope or develop test cases for that this comes from a common understanding then we can identify holes in the success criterion through this process. For instance we could include some of these definitions in 2.2 and so it's a benefit for us to be doing this work

WILCO: techniques are written for common authors and testing wills are very specific for testing and so there may not be a complete overlap.

Shadi: I agree with you on a mapping level that a failure to rule is closer than they are to the techniques the positive passing techniques. But I think the writing the rules of the growing in this very bottom level that we agree on what the success criterion means it can help us write documentation around it both the positive aspects in the failures

<Zakim> gowerm, you wanted to say we should have a process for documenting missing definitions

MichaelG: without even getting to the level of writing the rules I've notice as I've been doing some techniques reviewing that we have some things that are not defined in SCs. And to me that is a problem and so we need to get those cleaned up.

I'm wondering if we can perhaps there's a decision point that can lead to a test.

MaryJO: it's important that we have a test that we can definitively pass or fail

Wilco: one of the things we've not done because we just were not sure whether you could determine something which is how do you know if video is live. There is a distinction between streamed video and live video so some rules are easier to test.
... aspects under test. This tells you a list of technologies or capabilities that you need in order to perform a particular test. A lot of tests we do need access to the Dam or styling so that you know whether to expose to assistive technologies. There may be rules that you may have access to the plain HTML . Or access to the audio output. By defining this things we make it clear what capabilities you need if you going to do some sort of [CUT]

Katie: does that include access to a platform settings.

Wilco: if there's anything you need to know in order to perform the test then that would be in the aspects.
... applicability must be objective, though there are subjective parts such as the alternate text passing or failing.

We want the atomic rules to be plain language so they be understood there were some iterations that were very hard to understand so we changed at that

Will call has been walking us through the ACT document. Which explains all of what has been in these minutes.

<Detlev> q

s/will call/wilco

Detlev: if I was to take this format and writing techniques, how would I do it. If I want to write a technique on say hover how would I apply the test framework to do that

Shadi: let's taken opposite direction... Write a technique... If we agree that this is not a good way of checking the requirements it would make her ready with techniques a lot easier.

Detlev: at the end of all we need is a group is to provide the supplementary guidance on how to apply the guidelines in practice (understanding and techniques). So are we are providing the supporting documentation on that.

Wilco: one of the undefined questions right now is how do we provide rules to the AG? Were up to about 30 rules at this point that we felt from previous work. But how those rules can be used by AG right now is something that were still wondering.

AWK: the rules oriented around techniques that we have or they are organized around topics that the techniques also have to be organized around

<Wilco> https://auto-wcag.github.io/auto-wcag/rules/SC3-3-2-form-field-has-name.html

Wilco: the link above goes to work that's being done in the AUTOWCAG community group rather than the ACT group

AWK: it seems like there are some things in these tests which I do disagree with. How do we VET those.

Wilco: we want to take some of the work in the community group and make it a W3C resource.

AWK: what is your timeline right now?

Wilco: we are very close to it. I expect will have a draft approved by the task force probably next week. At that point we will share it with AG.

AWK: is there an internationalization review?

Shadi: if there are any questions about internationalization, please feel free to raise them.

Wilco: while thing to have two implementations of the rule before we submitted to the AG. But once words the are we can look at that.

Detlev: what are the implementations?

<Zakim> gowerm, you wanted to say are you doing any discussions with the Aria Practices Guidelines?

Wilco: that would be somebody using the rule in their system for instance in an automated checker or some sort of a QA process

Michael: I was talking to Matt King yesterday and you may want to coordinate with him becausethey would like to be involved in vetting things

AWK: thank you good work
... in terms of the task forces, mobile, COGA, LVTF etc. we have to organize and figure out what is the output and timelines. Will to get the techniques this afternoon.

JF: you relook at other taskforces also responsibilities

AWK: a coffee break

<alastairc> agenda

Next Normative Work

<Rachael> scribe: Rachael

AWK: EO is planning on coming in at 12:30. Break at 1. They are working on understanding documents.
... Discussion now to talk about what's next.

Regular cadence of normative updates. We want to avoid 10 years between updates. Then we get into time periods. Lisa raised idea of switching back to using extension model.

Silver came in yesterday and they will be joining us. What are peoples thoughts on this?

<Zakim> gowerm, you wanted to say that we need to get the techniques done.

WCAG 2.2 or whether its realistic to say 1 year, 2 years we'll do 2.2 or should we switch to silver? And we still have things on 2.1 to finish.

gowerm: Implementation of 2.1 is important. We need the techniques. We can't write the rules without those. It would be good to have 1-2 techniques for each criteria. Then start 2.2

personal opinion.

<AWK> Current charter: https://www.w3.org/2017/01/ag-charter

<AWK> Ends 31 October 2019

JF: Also personal opinion. Between now and our current charter, we need more techniques. I mentioned investigating new task forces. Do we want to re-energize existing task forces?

Then when we recharter a year from now, we include the next dot version of WCAG. We made a promise of a regular publishing cadence. We went back and said not to worry because there would be another round.

AWK: Link to current charter is above.

We will work on charter next summer.

Kathy: I agree with continuing 2.1 techniques. A lot of points this morning on the need to flush this out. The SC changed and we need to finalize these. Because Silver is at the point of a framework and working on conformance, we need to give input.

We need to be engaged to avoid backtracking.

<gowerm> Good point on silver feedback

A lot of great ideas on silver but we need to reflect on challenges that we've experienced and ensure Silver can overcome them. Then we can focus on 2.2

Ryladog: We need to make it clear for people using our tools. I do like the gap analysis and working that up. I think we need to engage with Silver as part of our regular process. Attend each others meetings.

<Detlev> q

The issues with conformance requirements is something we should be involved in. The new model is an important point. I think we should be working towards combining. Lets focus on the next version.

next version = silver

patricklauke: I think its important to get our house in order. The community at large are trying to grapple with the new SCs without techniques and some holes in understanding documents.

Adding SCs would be detrimental. There are things that fell by the wayside in 2.1 but I think they did so because the testability requirements of 2.1 was a stumbling block. Silver may resolve this. Provides a more nuanced approach.

I would concentrate on getting 2.1 done and then move towards Silver. Possibly skipping 2.2. If we compromise, we end up with a bad spec. In some cases in 2.1, we ended up with a less clear end result than it could have been.

<Zakim> JF, you wanted to comment about Silver versus new SC (2.2)

tink: Regarding the extension models, I am strongly opposed to it. Getting 2.1 finished is important. I love the approach Silver is taking but I think it will be a paradigm shift for the community so I wonder about the timetable. If there are good 2.2 candidate success criteria, I think we should address those. We shouldn't fall into the trap of thinking everyone needs to do everything. We have 120 people in this WG, we should be able to divide and conquer./

JF: This isn't a binary choice. We can work on both. We may want to address broader issues but Shadi made the point about testing. Can we integrate some of the testing items? If we only have 3 SC ready for 2.2, that's OK. Technology keeps moving forward.

Maybe we should consider a 2.2 taskforce

Maybe we can get a few more ready for a 2 year time frame, where we are confident that they are good for developers. I think focusing on Silver risks a long delay.

We were trying to do too much in 18 months. Started with 30 and got to 17. If we have a regular publishing cadence, we can just focus on the ones that are ready. Not binary. Lots of efforts.

<patrickhlauke> as side note i'd say: it's dangerous being beholden to a "we WILL publish something at a regular cadence" if then the result is we rush/crowbar things in to meet the publication deadline, rather than when it's "done". also, publication could be perhaps "publication of updated understanding/techniques/non-normative material", rather than "we made new SCs"

Focus on a regular publishing schedule.

david-macdonald: In agreement about 2.1. We need to get that right. John's point about a 2.2 taskforce is an interesting idea.

2.2 is likely a minor update with a bit of cleanup with a few new SC. I am concerned about the proliferation of success criteria. We have a 30% increase. That is a large change. If we add another 3-5 that's another 5-10%. I would like to see our core work be bringing Silver into center.

<patrickhlauke> +1 to david macdonald's point about how WCAG grew. this *scares* (or at least puts off) companies in the real world from adoption

I think a taskforce can examine and then come back. If there is something useful to put out, we do but otherwise focus on Silver. I am concerned about Silver growing in silo.

<patrickhlauke> we're still struggling to get companies to adhere to, or even consider, WCAG 2.0. piling more SCs on won't make them more amenable to implementing it

I'd like to bring Silver and the core AG group together. I want to hear new fresh ideas and contribute experience.

Bring silver into main, 2.2 to taskforce and see what comes up. Clean up 2.1

JF: Do you support regular publishing cadence?

david-macdonald: I have no strong opinion on cadence but I am concerned about an ever growing standard. Silver would allow more flexibility to create a better version not just a bigger version.

<JF> +1 to Wilco

Wilco: When this group was working on 2.1, the taskforces brought the SC to the group their work got broken down by too many cooks in the kitchen. Design by committee has issues. I like the idea of a 2.2 taskforce to work on proposal. And a silver taskforce. Then AG can focus on reviewing. I think that is a stronger process.

I also worry that we have huge expectations of silver. I think we need to be mindful. Silver will still be testable. Still comes down to passing or not. However that new system works, there will still be a bar. I don't see that hugely different than 2.1.

Silver needs measurable properties. I think we can do a lot of that work already. We need better metrics for COGA. Those needs to be solved regardless of 2.2 or Silver.

Adding the issue of measurement on top of the new structure makes Silver more difficult. May want to break it down.

Kathy: We are all talking about having different task forces. We don't all have to be doing the same thing (mobile, coga, etc). Mobile could be working with Silver about challenges. Different task forces are at different stages.

I think we should think about what the priorities of the task forces should be. Doesn't need to be the same thing.

In the US market, there has been a huge shift to focus onto the most important things. The number of requirements has led corporations and legal to focus on what they consider the critical items. We need to prioritize.

<patrickhlauke> +1 to Kathy. as i said above: companies even balk at doing WCAG 2.0. piling more SCs on won't make them "moar accessible"

Ryladog: I think we have a limited number of people at the table. We have 10 at the table, calls are around 8.

AWK: consistently around 20 active on our calls.

Ryladog: Splitting ourselves too thin is a mistake. Silver has done its task force work. They want to make the accessibility guidelines less painful and provide different ways of measuring.

Those ideas need to mix in with the what it will take to really create the new structure.

<Zakim> JF, you wanted to comment on proliferation of SC

We as a group have to focus on Silver. That is what we need to be working on. Quality is more important to me than cadence.

JF: Regarding making the SC bigger, the world has also gotten bigger. We have more requirements because the ecosystem is bigger. Regarding Silver, its a framework. What we put inside is what is measurable. There is a need for a more testable standard.

The other W3C groups publish more regularly. Despite the legislative aspect, we should be following a similar approach.

patricklauke: The difference with the SC, is that we are approaching it from the opposite side. CSS adds features that allow people to do something. We add criteria that tell people what not to do.

<alastairc> plus they can deprecate things...

We have different drivers.

Regarding the regular cadence. Did we commit to publishing new material or is it that we keep all non-normative documents up to date. That didn't happen with 2.0. I consider those updates regular cadence.

That is why we split into normative and non-normative. We could publish 2.1.1 with errata and an update and expanded understanding documents.

We saw yesterday that we are having misunderstandings. Imagine what is happening in the rest of the community.

Regarding too many cooks, we have also found that when task forces work independently there are overlaps. Example: reflow vs orientation. We were solving related problems that could have been combined if worked on collaboratively.

Balance task forces with ensuring we are not solving the same problems.

AWK: I agree there are different drivers for CSS vs WCAG but I focus on whether we need criteria, vs whether we add criteria. If we identify a need, then we shouldn't focus on the number.

<JF> +1 to AWK

We need to balance the needs against a lot of other questions. I don't want to get too worried about the overall number. But I understand that it's difficult to get companies to commit to 2.1 because its work.

Focus on creating a spec of accessibility requirements. Regarding 2.1.1 containing errata, we publish those without a new iteration. I think we need to identify likely candidates for 2.2. We need to know more.

That will also make it easier to charter for 2.2 if we can specify what we are putting into the spec.

<Zakim> gowerm, you wanted to say one thing we get with Silver is a greater willingness to not be fully backward compatible

<patrickhlauke> +1 backwards compatibility was a hindrance to effectively writing 2.1 SCs that were add-ons/complemented/expanded the scope of existing 2.0 SCs

gowerm: For 2.1, we left 2.0 alone. With Silver, we get a willingness to not be backward compatible. That was a challenge with 2.1. Some of the taskforces wanted changes. I think some of the ways to fix existing issues is to move to Silver.

<patrickhlauke> to AWKs point: can we only recharter IF we promise a new version of WCAG? what about rechartering with "ongoing maintenance/update to techniques and understanding based on industry need / new technologies / etc"?

WRT, regular publishing, having an intention to publish every 18 months or so provides a motivation to meet a schedule. It is effective to stick with a publishing schedule since it shows evidence of work going on. The working group is an important sanity check for the task forces.

We should integrate task force work into main working group in a regular way.

<AWK> @patrick we already have that

david-macdonald: A business consulting guru once said an idea group size to get something done is about 5-7. That is about how many we have really active. I don't think of us as a big group. More like little pockets of availability. We work because we rotate.

Kathy: If we are going to look at 2.2, one of the big challenge we had with 2.1 is that the task forces worked independently. In 2.1, we never looked at user requirements across task forces as a whole.

Once the user requirements are defined, then the task forces can work on them. Get more regular feedback from the group by stepping back and understanding. That would also potentially help the working group.

Also looking at what is doable.

<Detlev> +1 to Kathy's proposal

Slight process change to help us move forward in 2.2 and avoid some of the challenges in 2.1.

+1 to Kathy's proposal

AWK: I felt like we did that some.

<Judy> guests+ Judy

Kathy: We were at different points so we ended up starting at the success criteria level. It wasn't that the working group didn't want to do it, but we were all at different places. So if we do 2.2, we should step back.

<Zakim> JF, you wanted to note that some companies are coming to us with the desire to achieve 2.1 today - counterbalance kathy's earlier comment.

JF: Regarding Kathy's comment about legal saying only to do the critical, at Dequeu we have people coming to us asking us how to do 2.1. We have people across the spectrum.

WRT to 2.1, part of the issues we had was due to volume. If we reduce the volume, we should also improve the process.

Kathy: Clarify, some organizations are looking at 2.1 but because of the volume, they are focusing on some items and others are dropping off. I think other versions will have a similar problem, but I think we should focus on A and AA.

<Zakim> alastairc, you wanted to ask who would want to join a hypothetical 2.2 workforce?

JF: While we need to pay attention to regulations, we are not regulators. I believe its our mandate to provide testable accessibility guidance for developers.

Kathy: I agree its not our purpose but it is being used at the regulatory level.

Alastair: Hypothetical question: If we took Silver as a more involved process in the group, who would work on 2.2?

<gowerm> John and I also put up our hands

AWK: I don't know if there is a conclusion.

Alaistar: Everyone agrees that we need to complete 2.1.

AWK: No question there. We've been working on keeping the techniques up to date for the last 10 years and these are important aspects of what we work on.

JF: Can we commit to publishing an update in our next charter?

Michael: We could charter that way but I think Silver would need to be added as its own category. We could charter to do Silver and WCAG 2.2 and higher if needed.

We need a clear plan for the advisory committee.

It is not too early to think about our next Charter. The most optimistic time to get a charter through is 6 months and I am not feeling great about that. We should be thinking charter now.

<AWK> Need to Start working on Charter at CSUN or sooner

Judy: I agree the charter needs to be specific. These are of great interest to membership so expect them to be examined carefully. I am curious if there is a general sense if 2.2 were to happen would at least need to do certain things. For instance, when 2.1 there was pushback on using coverage for low vision and mobile. Is there a belief that there are needs for low vision and cognitive?

There was also a parallel process with Europe but they were also running ahead of us. Would any of their content fit into a 2.2? Also in China they are debating how to harmonize with W3C so there also may be things coming from that.

At W3C, we here from others outside the working group about what they would like to see in 2.2 so I hope you will have a wide review process for 2.2. Cast the net broadly rather than a conversation in the room only.

<JF> +1 to Judy's last point (and the others too)

<Zakim> Patrick, you wanted to add a side note about "mobile" terminology/distinction (if we're rechartering can we refocus TFs)

Katie: Regarding testing, the new model in Silver allows for more flexibility. We might have issues with remaining SC that would work better in Silver. I think our focus needs to be on Silver. We shouldn't work on 2.2 at the expense of Silver.

Patrick: If we are rechartering, the categorization between mobile and desktop is very fluid. I think it would be good to move away from that. Look at it more in terms of technology. Touch screen or sensor specific guidance.

<Zakim> AWK, you wanted to speak to need for detail on Silver conformance model and to ask whether we can even get a new charter without a rec-track deliverable

You can say that on mobile devices, these are the topics you have to address and then address them as the technology.

AWK: I think we have a mobile taskforce but when we talk about it in 2.1, I think we talk about small screens, touch screens, and sensors.

I worry about putting too many eggs in a basket that we don't have yet. We know we need and want Silver but don't know what it is yet. We need more detail around the Silver conformance model.

<patrickhlauke> to clarify, it was more about the slightly unnatural *internal* naming/distinction, which just perpetuates the misunderstanding (internally within the WG, but possibly also in terms of ontology/categorisation with advice etc) that for instance touch/small screen is "just" a mobile problem

Regarding rechartering, with the chartering processes at W3C if Silver is 3 years out and we say we want to focus on Silver and not 2.2, can we even get a charter?

<Ryladog> If working on 2.2 on non-cognitive, non-low-vision issues, at the expense of delaying Silver that - a spec that may have greater hope to fulfil those needs, I think 2.2 would be a mistake

Michael: As long as we are publishing drafts, if we say our intended timeframe up front, we should be able to get it chartered.

Silver has had a good bit of incubation. We have a good bit to show. The editors draft, after some cleanup, would be a referenced draft in the charter. To say its still going to take longer than 3 years is a case we can possibly make.

Judy: I think that there were multiple reasons that items didn't make it into 2.1 other than testability. I am concerned about waiting to get more SC for COGA and low vision until Silver. I hope the working group looks at getting them in earlier.

Not using the word mobile for a decade or so while we were addressing mobile hindered adoption. We need to use the word in the spec in some places to ensure it isn't ignored. From a technical standpoint, I agree but from an uptake standpoint the word mobile is helpful.

We developed a cross reference mapping that everyone ignored. Feedback was that they wanted something that said mobile guidelines.

<Zakim> JF, you wanted to comment on "testing" in Silver versus "conformance"

Keeping the word mobile may help the work here does to get adopted.

<patrickhlauke> ( i look forward to the guidelines for touch-enabled two-in-one laptops ;) )

JF: There is a world of difference between testability and conformance. The silver conformance model is moving away from all or nothing. That is a benefit but in either scenario, we need testable criteria that allows conformance. Adding new criteria is important.

I think we need to look at how much we can add to the testable content.

david-macdonald: Are we covering low vision need? Are covering cognitive? The answer is no. We still aren't covering the blind community completely. The most we'll ever do is to take the existing research and see what is emerging and codify it.

<patrickhlauke> +1 to david. we don't have complete coverage for blind/other communities either. goes to point that WCAG != all of accessibility, despite best efforts.

Right now we don't assistive technology in the cognitive space. We are hoping the new criteria help change this.

I don't think we will be able to get more coverage under the current framework.

<patrickhlauke> technology moves forward, but do users have access to it? being mindful not to make guidelines that require latest/greatest hardware etc

I don't think of us as cutting edge. I think of us codifying emerging approaches through our standards.

<JF> +1 to David's use f the term "codify"

There may be a few things we can do in 2.2

Ryladog: The interaction models will continue to get richer and we need to stay on top of those things. We need to be thinking about more than just mobile. Speech interaction models, vibration interaction. We will always have exciting work. If we keep going in too many directions, it will be harder for us.

<Zakim> Ryladog, you wanted to discuss pervasive + mobile

There may be areas that are more mature in Silver. We may be able to publish a WCAG 3 in silver and then work on 3.1, 3.2, 3.3.

Kathy: I think the area is so complex, we will never be able to articulate large scale coverage.

Judy: I don't think anyone here was assuming 100% coverage. There were conversations in 2.1 where the proportional difference of mobile was considered much higher than the provisions for cognitive. That is still very low compared to what users need.

We've been warned to avoid the term coverage for COGA and low vision. That wasn't true for mobile but that may have been an omision. But there is no assumption of 100%. We'd like to get the amount of provisions up.

Kathy: One of the challenges of 2.1 was that we were in task forces. We need to look at this from a user needs point of view rather than a low vision or coga one. Things that originated in a task force often crossed over.

<Zakim> AWK, you wanted to discuss next steps

AWK: We have 11 minutes to figure this out. What are our next steps to drive towards these decisions?

Some ties back to the task forces. Everyone agrees #1 priority is finalizing 2.1.

That will involve task forces as well. We also need a better sense of possible content for 2.2 or Silver.

The supplementary guidance documents that we will work on at the end of 2.1 will help us to understand what is missing for user needs.

An external call to gather feedback about what external stakeholders feel are missing from 2.1 would be helpful. A key piece is having the requirements document for Silver.

If we don't hone in on those, we will keep having speculative conversations.

Key points: Finalize 2.1, supplementary documents, external input on improvements, continued engagement on silver about requirements

Ryladog: Was your point that silver can address COGA better because of the different grading system?

Are we waiting on the Silver task force to do that for us? Are we part of that process?

AWK: Part of our area is to help with that process.

We need to make sure that what Silver is about is part of that process.

<JF> scribe: JF

<Rachael> AWK: We want to avoid us telling them they haven't addressed the key concerns. The working group needs to be behind the requirements.

<patrickhlauke> suggestion: if you/we are concerned about "what silver brings back to us" ... can i suggest you may want to work with/join Silver?

Discussion around who will be fitting the new and existing stuff into the new framework of Silver

KHS: this will be a huge amount of work

<patrickhlauke> +1 to what AWK said: avoid "us vs them" language

AWK: this is exactly what the Silver TF mentioned yesterday - they have multiple models that they are looking at

<tink> +1 to Patrick's point above.

MG: wanted to ensure we also have clarity on Task forces: waht are they workng on, process, etc

AWK: yes

Alastair: if suplemental guidance focused on user needs, tht would lead to Silver adoption easier

AWK: yes, but that would still point back to SC, that exist, of those that are missing

Alastair: bridge between suplemental info, versus what we have in WCAG 2.x now

we need to have that user-needs piece ready for Silver when they need it

AWK: see those as things that are needed, but cannot (for multiple reasons) cannot be made into SC at the current time of publishing

but as technology changes, we can "pluck" those user-needs into SC

or we may have to say (for example) we lack a spec to produce a testable requirement

KW: what about Patrick's comment: what are the challenges around (mobile-like) concerns. Can we have supplemental guidance there?

AWK: rather than having one big thing, we have a collection of smaller, focused user-requirements?
... guests are now arriving - do we have any agreement on next focus and drafting discussions around charter in 5 months

MC: feels March may be too late to start on Draft Charter

KW: we need to finalize what we want to achieve, then we can work on Charter

AWK: agreed, but we still don't have that list

EO Visit

AWK: welcomes EO to the meeting room

Intros around the room

AWK: as publication of 2.1 happened, we had conversations with EO around our Understanding documents

EO agreed to help make our docs moreunderstandable

Brent: a team from the EO WG was focused on the revision of the Understanding Docs, with a focus on the 2.1 new SC

We have been revieiwing the documents and when we find points of concern, we log them in GitHub

then we have a small team that reviews and re-writes a draft, which goes back to the larger group, and revises, etc. (Rinse and repeat)

Brent: we've been working on that, but it's been slow progress

intend to revisit and re-charge it. There are two people driving this (Chris and ____)

Goal is to get a revision collection and diff file(s), and then submit to this WG for review and publish (hand-off)

Brent: we've tried to focus on "groups" (i.e. LV and 5 SC)

Process questions around how to hand off to the AG WG

Brent: hope to have the 5 LV SC Understandings "done" shortly

AWK: as far as process, forward to AG Chairs
... as far as techniques, we're doing a lot of piece work, so getting each Understanding revision individually or as a group is a wash

slight advantage of getting all 5 at once is that we can move quickly as required

if you submit them one at time, we can iterate at a managable process

Brent: there is one for example that we've noticed a need for Headings in the document

but then another document did have headings, so in our new draft, if we've introduced headings is that OK?

Also a question about scope

AWK: when you say headings, you mean sub-headings?

Brent: yes, but we found that some documents had better sub-heading structure, so...

AWK: we'll want to look at the diff and a goal of consistency with current documents

KW: one thing that may be helpful is to send you proposed changes ahead before all the work of re-writing

so if you have a list of things you want to edit, consult with the TFs first to ensure there are no concerns

wordsmithing may have unforeseen consequences

AWK: you 're asking for a highlighted version of what you want/plan to do before doing it all

KW: yes, want to ensure that wordsmithing doesn't change intent or goal

so staying engaged (as required) before final edit will likely result in a better outcome

Brent: we did give careful and clear direction that we don't change meaning or intent - being careful to preserve that

but agree that consultation will be important

<Detlev> -q

KW: recall that doing the work in the Mobile TF, that sometimes a minor change, even in one work, may have a significant impact

Shadi: sounds like it may be easier that instead of making the AG Chairs the contact points, that instead it be the TF chairs

<Zakim> gowerm, you wanted to say I think especially for the first ones, sending singlely makes sense. Iterate so you are spending more time on what we think is useful

AWK: sure, fine with that - send to Alastair the TF cochair instead of Alastair the WG TF

MG: thinks sending them out individually may speed the process

Brent: we can do that

MG: we had discussed incorporating personas but also the short descriptions (bulleted highlevel)

haven't seen that, so want to remind to look for

MG: haven't contriubted anything back, but have done some work on it internally at IBM - useful to have the personna bits and short descriptions

AWK: MG had the short descriptions, and Glenda had the Personnas?

MG: Correct

Brent: have discussed with Glenda about the Personnas piece, but not sure where it sits today

not sure about the shorter descriptions

<gowerm> https://www.ibm.com/blogs/age-and-ability/2018/02/08/simplifying-new-wcag-2-1-guidelines/

MG: have worked on this before - can share

<Detlev> -q

Brent: vaguely recalls

MG to share with Brent

Brent: we were making good progress, but then hit a road-bump

but we plan on returning to this ASAP

Brent: but is there a deadline?

AWK: we've not set an explicit deadline, but we've been discussing and generally feel end of this year
... if it is helpful for us to set a deadline, we could, but...

DMD: what about getting EO involved in Techniques?

Brent: we've discussed previously - concern that the EO group lacks the Technical skill set

Amanda: +1 - we lack the skillset

AWK: thanks EO for the update, and appreciates the help. Agree to use TF facilitators to be the primary points of contact for feedback loop

Brent: agrees that going to the TF's makes sense

AWK: breaks for lunch

<Rachael> /me I'm signing off on webex and will try to call in later. If I do not, I hope everyone has a good week and safe travels.

<alastairc> Techniques doc: https://docs.google.com/spreadsheets/d/15idlBl1qQTNr2SIi4Drzk1Q1vnWAi5L26GCCv6mjD2g/edit#gid=0

<patrickhlauke> scribe patrickhlauke

<AWK> Scribe: PatrickLauke

<patrickhlauke> alastair: finishing our discussion

<AWK> Scribe: patrickhlauke

if we were setting target: finalize 2.1 from now - does Jan 1st sound optimistic?

AWK: should be able to do something, but how big is the bundle?

gowernm: we could have a milestone achieved

maryjom: we could have understanding docs

awk: it's less critical, as we have content in all of them, it's in better shape than techniques

gowerm: there's stuff in the understanding docs that is not up to par

propose working with EO (?)

alastair: need to define what supplementary guidance docs are

awk: won't have those done by jan 1st

supplementary guidance doesn't have to be called that. techniques and understanding are SUPPORTING documents

what distinguishes supporting from supplementary - this (supplementary) is additional content, examples, research

alastair: 1 tech per criteria for 2.1; supporting docs; supplementary guidance; external input on imrpovements for "next", 2.2 or silver

gowerm: as we don't have UAWG, do we want user agents to look at 2.1? is everything for UAs in 2.1/supporting docs?

awk: if UAs wanted changes to 2.1, they wouldn't be able to go into 2.1 now

alastair: i could envisage user agents finding 2.1 useful; but can't see how authoring tools guidance would be covered

jakeabma: design sprint last year with makoto; but for design sprints to work we need to be more regular

detlev: intend to take more part in silver calls/understand better what they are doing. like idea of reshaping. can report back to WG

awk: defining format and content for supplementary guidance should be feasible for jan 1st

goverm: we likely can only tackle first few tasks (supporting docs)

awk: we should be able to tackle 1 tech per week; develop a technique; not review, accept, etc one
... for techniques, we need to define task force engagement on that

if we start 14 techniques here, there's still some left. what we may learn from that is that even for those we need specific guidance

techniques may start here, but will need TF input, or to decide a TF needs to tackle them

alastair: in terms of going for 2.2, going to come out of external input and supplementary guidance process

awk: what's not just up to Jan for task forces is to do gap analysis. what user needs are relative to what's currently covered and what's outstanding. out of that supplementary guidance (what's not covered), which may still not cover user needs as there may be no guidance. out of that we can decide what can be actionable and turned into new SCs

mobile, coga, vision, could be ar/vr - we don't have any relevant guidance on that so far

davidmacdonald: (paraphrasing) what's the status of this supplementary docs? it won't be normative

awk: it will help people see where the gaps are, what they can work on/research

(in response to kathy) it should be high priority for groups to identify where they feel the gaps are

and the "what do we do next" part comes out of this / the user needs that aren't met

kathy: that list may change

awk: which is why time to update list is just before you recharter

Ryladog: concerned about the amount of work, particular in context of restructuring happening in parallel for silver. can't see work in parallel being successful

can't just accept whatever structure is given to us. they (silver TF) aren't just giving us a structure and we have to fit our content in there.

if silver IS going to be the next vesion, we (whole WG) have to work on it. can't just give 1/3 of time to silver, if all they (silver TF) are doing is providing us with a framework

davidmacdonald: i feel similarly that i want to get 2.1 done and then spend quality time with silver

awk: core question is what's the purpose (for silver); no point discussing whether to go for 2.2 or silver if we haven't defined what silver solves

we can take opportunity of silver to take things that haven't been met by 2.1 (gap list) and do it with/in silver. but that turns a long project into a very long project?

jake: is silver providing framework and we have to work in this framework; or are we not looking at our current SC just in a new framework? or are we reworking/merging/massaging current SCs to better fit/take advantage of better structure

maybe we need to forget framework altogether and think of a new way to organise criteria

awk: e.g. if you thought 1.3.1 is too complex, you could instead have lots of different methods to achieve a particular guideline so no direct 1 to 1 mapping

alstairc: even if we just use 2.1 SCs, it will need to be adapted to fit into silver framework

now is perhaps not right time for whole WG to jump in. they're currently experimenting to see if framework can accommodate SCs as they are now with adaptation. we don't want to now also rewrite SCs at same time/restructure them

davidmacdonald: got impression that currently silver TF are working under assumption that methods can't be testable

SteveLee: methods will still be measurable though

davidmacdonald: the new aproach seems far from our current approach of writing SCs

kathy: if we do mapping from 2.1 to silver, we're not using the new framework properly

but there hasn't been enough time to take step back and properly evaluate how to work in the new model

you have to stop and think in terms of new framework. not just 1 to 1, but thinking about how to reorganise/combine/merge/rejigger user needs

alastairc: you try doing that on one (re homework silver TF gave us) and see where the pain points are

goverm: q1 2019 will we have same discussions? based on more details we get from silver TF by then

we'll need more than a day to discuss this, what can be achieved in next charter

don't think that even though they want to give existing 2.1 conforming sites "bronze", it's not going to be a mapping. more of a grandfathering

<Zakim> gowerm, you wanted to say can we have EO do some kind of survey to determine some of the gap analysis and need for supplemental guidance?

davidmacdonald: how about we get as much as possible done on 2.1 for Jan. then pause. concentrate on recharter. look at what the status is on silver. spend time with them. dedicated time. merge cultures. and then see how that can inform our plan for next charter. 2.2 / silver.

gowerm: can EO help?

awk: not what they would do. they'd be happy to look over what we have.
... switching to discussing supplementary docs: focus taskforces on unmet user needs. The main WG will finish the techniques for 2.1 and the TFs focus on defining the unmet user needs and opportunities for SCs that don't yet exist.

kathy: that's more than just looking at "what didn't get in to 2.1". it goes right back to initial gap analyses / user needs

jakeabma: there's more than just technical advice / techniques. more higher-level guidance / guides. another approach to look at accessibility (not just "atomic" technical rules, but "composed" rules that look at larger processes/pages/user flows)

that's not currently in WCAG

patrick: isn't this stuff that EO documents - e.g. WAI tutorials (for carousel, menus, etc)

alastairc: something that silver had yesterday was links to design patterns

<Zakim> gowerm, you wanted to say are we ever going to do a heavy scrutinization of wcag 2.x?

gowerm: are we ever going to stop, look at wcag 2.x, and do heavy duty scrutiny of what does and doesn't work

alastairc: we did in early stages of 2.1 when we looked at backwards compatibility. but not a lot people would have agreed to ditch

gowerm: not so much ditch, but surely things that people wanted to rework/remodel/reorganise

alastairc: but since silver will be new framework, we'll redo everything anyway, so no need to do the scrutiny again since everything will be ditched

gowerm: do we have clarity about what the aims of our 3.x are?

awk: that's what our review of requirements will bring up

alastair: plenty to do until january. decision point about 2.2 or silver.

we have other bits like WCAG2ICT...

kathy: so supplementary guidance Q1 2019

alastairc: based on task forces' gap analysis done until January

davidmacdonald: without new framework not a lot we can do with cognitive

gowerm: want to challenge that. mary jo, was the blockage based on framework, was there nothing that could have been done

alastairc: from my conversations, apart from authorization, there was nothing that wouldn't be supplementary documentation

(some further discussion on cognitive SCs and process)

awk: one of the problems with COGA was perhaps that it was seen as all or nothing

things were changed, removed, replaced

possible to get a piece of some of the dropped/rejected/abandoned SCs to be salvaged, but on their own these pieces may not have been sufficiently fleshed out as fully formed SCs

kathy: it was a push to "jsut get something in". part of the process. coga had more of a challenge / less of experience with the process/techniques

maryjom: carve out little bits, more important problems, and tackle those more organically

alastairc: may be best taking step back to design requirements / user needs, without going directly for SCs

kathy: what we didn't do fully was looking at user needs and then address them with SCs

patrick: (just noting that - without going into too much detail - there had been some perceived animosity between COGA TF members and technical people on the main WG; but often when somebody with technical knowledge and process knowledge suggested that something was just not possible to write as technique / technically possible due to lack of mature APIs/technologies, that was taken as being difficult/a blocker. and that people did try to help COG[CUT]

alastairc: volunteers to provide more support to COGA

kathy: somebody to sit down with original user needs, create user needs list, take that back to WG as whole

awk sure

(kathy, davidmacdonald, patrick, alastairc bringing Steve Lee up to speed on some of the pain points COGA experienced with getting SCs in)

patrick: some of the SCs came in with specific technical solution already in mind, which then made them vulnerable to be shot down when technology was not deemed mature / widespread / feasible enough by more technically-minded WG members

kathy: going back to one step earlier to user needs would help more. going by user needs and proposing other/alternative SCs

<JakeAbma> scribe: JakeAbma

<alastairc> off topic cog doc: https://w3c.github.io/coga/gap-analysis/#web-security-and-privacy-technologies

<steve> presnt+ steve

DF: role tooltip needs to be related with other techniques

<gowerm> https://www.w3.org/TR/wai-aria-practices-1.2/#tooltip

<gowerm> Failure of 1.4.12 due to an inability to dismiss the additional content without moving pointer hover or keyboard focus

<Kathy> https://rawgit.com/w3c/wcag/tech-ensuring-single-pointer/techniques/general/ensuring-single-pointer.html

<Kathy> https://www.w3.org/WAI/GL/wiki/Wcag21-techniques#2.5.1_Pointer_Gestures

<gowerm> Activating a control and allowing abort using the up-Event in HTML, iOS and Android

<gowerm> Allowing abort on a control that is activated on the up event

<gowerm> Failure of 2.5.2 due to a control being activated on the down-event

<gowerm> due to an action being completed on the down-event

<AWK> https://docs.google.com/spreadsheets/d/15idlBl1qQTNr2SIi4Drzk1Q1vnWAi5L26GCCv6mjD2g/edit#gid=0

<gowerm> Providing controls to operate all functionality without complex or path-based gestures

<gowerm> Providing controls to operate all functionality without complex gestures

<alastairc> Github link for our repository: https://github.com/w3c/wcag

<AWK> https://www.w3.org/wiki/TPAC/2018/SessionIdeas

https://www.w3.org/wiki/TPAC/2018

<alastairc> Plenary day session ideas: https://www.w3.org/wiki/TPAC/2018/SessionIdeas

<laura> Bye.

<alastairc> bye!

<alastairc> trackbot end meeting

- DRAFT -

Accessibility Guidelines Working Group Teleconference

23 Oct 2018

Attendees

Contents

TF updates

ACT TF

Next Normative Work

EO Visit

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output