WCAG FtF -- 20 Sep 2016

<AWK_> +AWK

<alastairc> +alastairc

<Lauriat> https://www.w3.org/WAI/GL/wiki/Designing_Silver

<vneesha> prestnt+ Avneesh

<AWK_> +Avneesh

<AWK_> +AWK

<Lauriat> https://www.w3.org/WAI/GL/wiki/TPAC_F2F_Agenda#Agenda_for_TPAC

<Rachael> +Rachael

<Rachael> nickscribe: Rachael

<Joshue108_> scribe:Rachael

Summary so far: There are 4 options to silver. Each has a tradeoff.

We will start by reviewing the goals poll. Then we will have an anonymous survey. Then we will split up into subgroups that are mixed based on votes.

The idea is that we want to uncover weaknesses and strengths in the process options.

Then we'll delve into the details of the top options to adjust for weaknesses before coming to a decision.

Joshue: Please provide some framing.

The idea is that we want something that will be helpful and useful. Part of each process is identifying the various stakeholders and personas of people who use, are effected by WCAG

Andrew: to add context, right now we are working on an update to WCAG which is going to be limited. We have had a lot of work on the taskforces and each has come up with ideas that we can't do because of limits to documents. It may be because of changes to user agents or adjustments to authoring tools. 2.1 will be constrained by 2.0, just about content. Silver is what we would do if we are not limited by those constraints. That is what this conversation[CUT]

Patrick: The processes are distinct.

Joshue: We are aware that the burden is shifting from the author to the user agents. Silver isn't just about tagging on UTAG and ATAG and creating a supergroup. We want to do some blue sky work with silver. We need a space ot disambiguate it from the work we are doing on 2.1

* Please correct me if I get any names wrong.

Patrick: We are not talking about content. We are only talking about the process of how we will create Silver.
... As I mentioned earlier, every one of these process options has the same structure but the details are different.

There are 5 phases: Discovery, Interpretation, Ideation, Experimentation, and Production. First phase is research. Second phase is consolidating results. Third phase is generating ideas. Fourth phase is testing out ideas, prototyping. May give end users a sample document with proposed structure

scribe: and ask them to conduct a few tasks. Then we generate a requirements document and start writing Silver.

Question: What process is this framework built on?

Patrick: I don't know the formal name but this echos work I do in development.

Joshue: Is everyone clear?

[no questions]

Patrick: Design Driven Option - This option emphasized user reserch to write Silver. It focuses on getting information to get the best informed design. A lot of evidence gathering and user research. We want to create a stakeholder map and involve them throughout the process to make sure their perspectives are represented throughout the process.

We want to have a series of surveys for different populations (developers, designers, legislators, working group members, people with disabilities on where technology breaks down) to try to uncover issues and strengths. Make sure we are trying to solve the right problems.

<alastairc> scribe: alastairc

NB: Network issues killed some of the scribing, apologies for a missing chunk, but please read the wiki page linked above. https://www.w3.org/WAI/GL/wiki/Designing_Silver

Shawn: After the facilitated workshops, there is a phase of experimentation. This is to narrow down the options to those most suitable to stakeholders. That moves to prototypes, and then user-research which use the prototypes.

<Rachael> Contextual inquiry: Trying to identify how well things work. One step above user testing. Looking at the current practice. Additional documentation that people use to supplement WCAG.

<Rachael> The next step is Research: Gathering information about the rest of the standards world.

<Rachael> Self-reporting: Similar to contextual inquiry. Have people write down what they are doing as they use WCAG to capture real world experiences. Important becuase people forget to report things in other data gathering techniques (interviews, etc).

Based on the experimentation, there is an iterative phase of refining the prototypes.

<Rachael> WCAG analysis: Most if not all of us already do this. Looking at how things are right now. What works well? Much more systematic.

<Rachael> Analysis of WCAG adaptations: A common thread is that places have their own internal standards which is WCAG plus other stuff or WCAG massaged into something else. Why is that? What is the gap? What is the structure? Some companies can talk about it more easily.

<Rachael> Literature Review: Looking at what people are saying. Very wide open. Experts talking about it, research, thesis, etc. Looking at other's work anaylzing WCAG.

<Rachael> the final step in the phase is Communication. This is a summary of what was found so we have a set of data/results that we can reference in the next phase.

There is an evolution phase, which is the continual phase of maintenance/updates.

<Rachael> Next Phase, Interpretation: We take all that data and make it into interpretations we can use. The first is Case Studies which capture details about how individuals and organizations use WCAG. This is a meta-article from the research. Write a series of case studies that happen with WCAG.

<Rachael> Personas will be much more comprehensive for the design driven option.

<Rachael> Personas: These are used to have an idea of the types of people who will be using WCAG. Examples include a designer, developer, law maker. This is useful as a check through the rest of the process. This structure may work well for a developer but doesn't help a designer, for example.

<Rachael> User stories will be writen looking forward. These identify overall workflows that people are trying to achieve. They will make sure that what we are building follows what we learned.

<Rachael> The next phase is Analysis. This can be done in parallel with some Interpretation. It is identifying overall themes found during research. Pulling things together to help us start coming to conclusions.

<Rachael> The next phase is Communication. These communicate what we created and the rationale.

<Rachael> Then look at ideas to experiemnt with. Protyping: This is iterative. Last phase is production: Need to come up with resources and funding. Then distributing work.

<Rachael> Question: Will this start now? Answer: yes

<scribe> scribe: Rachael

Faster Progress Option:

Trying to do broad consensus up front. Part of the research in this option will be how other organizations build standards quickly. We would still look at building a stakeholder map.

<Joshue_108> +1 to Expanding beyond the usual circles.

<Joshue_108> +1 also to including PWDs as a core of the process.

<alastairc> scribe: alastairc

Jeanne: Some of the interviews will be aimed at people who don't have time for joining working groups.

George: Looking outside in the digital publishing space, there is a possible combination between the IDPF and W3C, and the efforts made (at IDPF) in evaluating user-agents and certified content, it is very nascent, but we do plan to 'make it rock'.

Jeanne: That's a good example of reaching outside of our usual circle.

Shawn: we're going through the entire process, things might occur to you so please do make a note as we don't want to loose site of those.

<david-macdonald> test.... I keep getting kicked out.... seems others are dropping in and out also...

Jeanne: In the faster option, we'd spent quite a bit of time/effort with stakeholders, learning from the best and adapting & adopting into the silver process.

Shawn: In comparison with the design process, the faster progress will be aiming to adapt the process in order to keep the momentum going.

Jeanne: Will also spend time looking at how organisations adapt WCAG, to see where the gaps are.
... We'll do a summary report (public) of the results.
... The personas will be very light-weight, then spend more time on the user stories.
... For the faster option, lots of small meetings, bulk of work in concentrated spans of time.
... We want to be more inclusive of our international responsibilities, which is difficult in weekly teleconferences.
... To get more international cooperation we'll do more face 2 face work, small groups, concentrated efforts.
... Phase 3, a W3C workshop (f2f) perhaps at the time of CSUN, then the silver group could be there, open it up to thought leaders from around the world. They would write a paper to participate, then present their thoughts on what silver should do / be structured.
... Hopefully located in a place to get maximum participation. They do need to be invested in doing it and getting us through this phase.
... 1st day would be the ideation stage, then second day would be small groups building prototypes. So a 2 day workshop for ideation and experimentation.
... The choosing part of this would be based on the workshop participants, then taking it to the working group.
... Hadn't thought about focus groups, but they might help us, especially to get participation from people in Asia.
... We are quite open to a hybrid option, taking an option and changing things.

JF: Are there anticipated timelines for these?

Jeanne: Difficult at this stage.

Shawn: Something we can do, there is a page for designing the design process. Looking at the overall process gives you an idea.
... The design would be longest, fastest would be fastest, the least expensive is unknown.

<Joshue_108> ckk jud

Judy: As a midpoint reflection, this is an impressive amount of work. If we're looking for a decision today, worried that we might loose time by trying to move fast. There are also a lot of people not here.

<AWK> David: question - when talking about prototyping, what does that mean

<AWK> Shawn: a mocked up version of the standard.

<AWK> ... includes at least a few guidelines worked up

<AWK> ... in other options the prototype might be more casual

<AWK> ... "here's the general structure..."

<AWK> David: Low cost? What does that mean?

<AWK> JF: specs cost in terms of resources

Notes from the end of the last session got dropped, I put them in an email here: https://lists.w3.org/Archives/Public/w3c-wai-gl/2016JulSep/0682.html

<Lauriat> https://www.w3.org/WAI/GL/wiki/Comparing_the_Options

<AWK> Scribe: AWK

<alastairc> AWK: Our group had a varied discussion. Some interested in 3, flexibility, but others interested in 1 (design).

<david-macdonald> group 1 varied discussion. started with a number of people with 3 flexible, but we morphed

<david-macdonald> there is a degree of similarity between options and the differences being the amount of time we spend on each of these activities

<david-macdonald> better information from more people, interest in rapid iteration... we want it all is that ok...

<david-macdonald> Jeanne: rapid itereation is key

<scribe> Scribe: david-macdonald

<jcraig> s/varid/varied/

marc: we need living standard approach
... don't know how to conform ith technologies not covered

John f: policy and legislators

JF: need more stability

Joshue: user agent in the stack... contract between dev to do the right thing... do we need to look at the responsibility of the user agent

JB: going back to policy uptake. interesting possibilities. We know a lot about regulatory... most is regulatory not legislative except a few countries. Each system has its own mode of uptake that sometimes look rigid but that may have particular modes of flexibility such as safe harbor
... a standards body can educate regulators about their update approaches, and encourage consideration of those flexible uptake mechanisms,
... glad you are looking them as stakeholders
... it may be tha tthe truest living model is not possible but static itereative can work

Wilco: faster iterative approach ... if we don't take time up front to understand potential problems... might lose opportunity to solve larger problems.

group three... we went with flex

<jcraig> s/loose opportunity/lose opportunity/

Alastair: I thought there needs to be a stage in the middle. double diamond. Spread out to get requirements come back to the problem in the middle, the spread out for prototypes again.

<AWK> David: Concerns about funding

<AWK> ... challenges of working in a volunteer organization

<AWK> ... but we should have all the steps we want

<AWK> ... and can check against them as we progress, even if we skip steps

Kathy: need to ensure that there is a broad stakeholders (which is 2) and incorporate that into our favoured #3

Michael: agree favour with 3 with elements from others .... don't think we should prioritize speed over quality but we need timeline

MC: need to gain credibility through milestones. Design could be a never ending cycle... I'm thinking 5-7 yrs but whatever we choose we should stick to it

JF: 5-7 means 7-10

mc: once we commit to a timeline, let's stick to it

JB: one of the 2 biggest delays have been lack of planning for prototype on fresh elegant new ideas. reiterate, snakes and ladders .... if you don't do the prototype well ... invest in wrong model, have to cycle back

Joshue: need to stick with timeline.

JB: Silver different from 2.1 new ground... probably 1st model won't work, and get further up the board game

MC: good thing is that there is a lot of research before 1st public working draft

will probably be in editor draft mode for long period

SL: involve stakeholders early should solve that

Alestair: We do a lot of this type of thing.... research is predictable timeline, the part of number of items etc can get long and complicated

MC: we should incubate it for 1) continuity ... institutional memory 2) creating 2.1 now. don't want it to be jarringly different

<Zakim> Judy, you wanted to comment on "incubation" and to comment on leveraging smart technologies... and things like alt text... and "jarringness"

MC: interplay between new Silver and WCAG 2.x

JB; incubation has a very specific meaning in W3C

<Joshue108> So how do we incubate without incubating?

JB: it group talks about incubation... might end uo moving to community group....

MC: activities could be considered incubation but might not call it that... but we have good reasons for not doing it outside of the group.

Thentimelinengives more opportunity to do automated pricess, new developments, maybe there will be some hapoy advances that would be positively jarring

JB: scope of W3C gives opportunities to look beyond PC to VR and all kinds of others things...

<Zakim> Judy, you wanted to give quick comment on multiple group option and to give quick comment on multiple group option and to comment on migrating

<david-macdonald_> JB: we can look at WCAG 1-2 migration support for useful bits....

<AWK> +AWK

<Rachael> +Rachael

<Wilco> SR: Sharron Rush, work for Knowbility. I don't have enough to so so I'm the co-chair of EO WG

<Wilco> BB: I'm Brent Bakken, I'm from Houston, I joined EO two years ago, and am chair since last fall

<Wilco> SR: We came to TPAC, we have more then 20 member now. We wanted to visit with the other WGs

<Wilco> ... to say that EO is not just about our deliverables, but we support accessibility throughout the W3C. We want you to think about how you can use our capability for outreach

<Wilco> ... I was talking yesterday, and some people internally had no idea what we were going

<Wilco> ... We already got some ideas. We figure there are 100+ documents on the WAI pages. Some very outdated. We have assigned them all to be curated by EO

<Wilco> ... people are looking at what exists, we look at what we need to do with them, decide what to do to keep them current

<Wilco> ... the outdatedness of the WAI website became a problem, so we decide to update that website too

<Wilco> ... Shawn is on the phone. Eric, Shadi have also been involved

<Wilco> BB: We're in the process of getting resources on a yearly maintainence plan.

<Wilco> SR: Our lead EO page has a bunch of the new stuff

<shawn> tutorials https://www.w3.org/WAI/tutorials/

<AWK> http://www.w3.org/WAI/gettingstarted/Overview.html

<Wilco> ... there are also the perspective video

<shawn> perspective videos https://www.w3.org/WAI/perspectives/

<Wilco> JF: tips his head to Shadi for the video

<shawn> Tips for Getting Started https://www.w3.org/WAI/gettingstarted/tips/index.html

<shawn> [ Feedback box at the bottom ! ]

<Wilco> SR: Denis B has the plan for expanding getting started, to enhance your practice

<shawn> s/peerspective/Perspectives

<Wilco> ... We have people working only on the websites. Someone only worked on the video. The opportunity to participate is more flexible

<Wilco> ... we have a lot of ideas for the website, but to have a designer who would be interested, we would love to have someone

<Wilco> all: Eo has done a great job

<Wilco> SR: We're hoping to start publishing updated documents soon

<Wilco> ... we have a new way of managing all the documents in EO. We've assigned someone as the curator of that resource

<shawn> Mobile Accessibility page https://www.w3.org/WAI/mobile/ Updated 18 August 2016 (first published Jan 2008) - additional updates in-progress

<Wilco> Brent: When I started as EO chair, I would sit in on presentations, asking people about the WAI documents. People would see many things, like drafts, outdated documents.

<Wilco> ... that's why I worked with Sharron to maintain these documents on a minimal yearly cycle

<Zakim> jeanne, you wanted to talk about public outreach about WCAG 2.1 and Silver

<Wilco> AWK: How and when should we be talking to EO about the next WCAG

test

<Wilco> Jeanne: When we talked about WCAG 2.1, we started talking about how to communicate about it. We need to figure out how we communicate the 2.1 plan, and after that Silver.

<Wilco> ... we want people to be assured about all the concerns we talked about

<Wilco> SR: We should have someone from our group to meet with WCAG WG so that when those things are identified, who can relay the information

<Wilco> Josh: We're busy with the spec, so it is great that EO wants to come help us with that.

<Zakim> JF, you wanted to ask if having EO help with Understanding docs

<Wilco> JF: is it appropriate to ask EO to help with the understanding documents?

<Wilco> SR: we've really increased member participants. I don't think we would have a problem recruiting people for this.

<Wilco> ... Once we define the expectation, I can make it into a plan to give to someone

<Wilco> AWK: I think Understanding would be a good target for this. I would love that the spec is familiar enough that the quantity of documents can be reduced

<Wilco> ... for the techniques that may be a bit more technical

<Wilco> SR: I think what was never too clear was that people could submit techniques

<Wilco> Josh: You would hear more about what people think about our techniques

<Wilco> David: I wrote some of the techniques. We should try to get EO closer to the non-normative documents

<Wilco> EE: Don't know if it would make sense to get involved with techniques. The question is, when is the time to do that, and how to make the transition.

<Wilco> ... It would be another several hunderd documents on our stack. But the techniques could be much improved

<Wilco> Shadi: I think the techniques are very important. Is there a new way to write the techniques that EO could help come up with

<Wilco> AWK: We've been trying different things to have external submission of techniques. It has improved, but it is fairly hard

<Wilco> ... We've heard often that techniques aren't easy to use.

<Wilco> ... we are very interested in new ideas about that

<Wilco> JF: One of my concerns is that people are starting to look at techniques as being normative

<Wilco> Shadi: a different format would be good. They are in the same style as the normative. Maybe some form of a database. Now if you want to submit something you need to find the form

<Wilco> ... I think integrating the techniques more in the same format as a tool, might help

<Wilco> ... make sure Eric stays busy

<Wilco> Josh: it is good for people to know we are open and that we want to hear

<yatil> [At least now it’s official.]

<Wilco> David: The techniques are used a lot by developers, also in tools

<Wilco> Josh: It would be good to have an someone from EO in the group who is aware of what's going on

<Wilco> Brent: Having a heads up in place for timeline would help. Knowing the timeline you have for communication , then we can get things ready in time to accommodate that

<Wilco> AWK: It might not mean they need to join every call, it is something we need to figure out

<shawn> Understanding Techniques for WCAG Success Criteria https://www.w3.org/TR/UNDERSTANDING-WCAG20/understanding-techniques.html

<Wilco> SR: Is there budget in W3C to pay for translations

<Wilco> Eric: The problem with translators is that they need to know about accessibility itself

<Wilco> David: We haven't communicated well why there are 400 pages support document

<Wilco> Richard: There is no W3C budget for translations

<Wilco> ... There are ways we can package things for translations, like technique by technique. We also need to manage the translations

<shawn> [ EO did some work on presenting translations a while ago -- and Shawn would like to get that a higher priority when as can ]

<Wilco> SR: Thanks for your time

<Wilco> David: Thank you

<JF> scribe: JF

New Charter

<Joshue108> https://www.w3.org/2016/08/draft-wcag-charter

MC: we should discuss the overall structure of the charter

JO: the overall early feedback is that this is headed in the right direction

<AWK> JF: QUestion about dot releases beginning with 2.1

<Joshue108> JF: Regarding the dot releases beginning with 2.1..

<AWK> ... we should anticipate more than one

<Joshue108> JF: I'd like to see us anticipate more dot.x releases.

<AWK> ... we know that not all SC will make the cut

<Joshue108> JF: Many of the new SCs will not make the cut for 2.1

<AWK> ... we should clearly articulate that follow-up dot releases are possible

<AWK> ... this should be in the charter

<Zakim> MichaelC, you wanted to talk about dot-releases

MC: agree with chartering with the ability

but not with a *plan* to charter more than 1 dot release

do agree there there may also be a deisre for a 2.2, but also needs to be balanced on a desire to ramp-up Silver

we may not have enough data to make that decision now

MC: the current wording would allow that

<Zakim> Joshue, you wanted to say the charter should have the scope for dot.x releases or at least preparatory work.

JO: one of the goals is to give us the room to do additional dotX release

maybe silver isn't ready, or whatever

<Zakim> AWK, you wanted to say that we want to be able to show regular progress, but not necessarily identify that it _Will_ be a 2.2 (but it _could_)

AWK: agree that we don't want to commit to a 2.2, 2.3, 2.whatever, but there needs to be something on a near horizon

so that if a SC isn't mature enough (for whatever reason) that we're not in a position of saying no, wait years for the next major release

AWK: are yo saying we do a 2.1, and time passes and we have a FPWD of Silver, so then at next rechartering we'd go for a 2.2 and continued work on Silver?

MC: suggested earlier that we have a not too short but firm timeline for Silver

<Zakim> MichaelC, you wanted to say .next which could mean 2.2 or Silver

so the question will be are we comfortable waiting, or if no, we may consider an additional dot release

MC: if we do do a 2.2, we need to ensure we don't compromise work on Silvder

in terms of timeline and work in parrallel

<Zakim> Joshue, you wanted to say should we be talking about Accessibility 3.0 or Silver?

MC: but these would be all questions we address down the road

JO: wanted to be sure we are clear that AG 3.0 and Silver are synonomous

Rachel: don't see anything regarding other dot releases - not outlined in scope

MC: by candidate recommendation of 2.1, we'll know what didn't make the initial cut

As long as this document gives us the scope to do that, we're happy

DMD: we know a whole bunch of the proposed SC won't make first cut: do we have a min/max number of SC per dot release?

JO: no, and we don't want that

we'll know what and how many after a review

[discussion around quantity]

AWK: there is a density of requirements that may have an impact on a disre to be in conformance

we may have 50 now, but that number may diminish through attrition, combination, etc.

KW: they may not all be SC targetted to deelopers, there may be design issues, or other role-based things, so that organs may segment differently than the spec declares

<Zakim> MichaelC, you wanted to say +1 to milestones for 2.1 and silver, for the next 3 year period only and to say if we don´t have a solid name we will seem unprepared, but otoh I

MC: regarding names: concerned about adding "Silver" name to the charter, as that may appear to indicate a not ready status that some may reject

<Zakim> jeanne, you wanted to talk about language for Ag3.0

<alastairc> scribe: alastairc

<jeanne> This is the next major version of the accessibility guidance, which requires a major reconfiguration of the way the guidelines are organized in order to account for technology advances, more flexible structure and more inclusive advice.

Jeanne: I'd like to change the sentence that is describing the accessibility guidelines 3.0, (replacement sentence above).

Rational: Have to be careful about ATAG/UAAG, as can't incorporate into this charter, but some advice may be produced as a by-product during the charter period.

<Joshue108> +1 to Jeannes suggestion

<Kathy> +1 to Jeanne

<Zakim> JF, you wanted to reinforce the idea of timeline - aka dot releases every 2 years

JF: Reading it now, see delivery dates in 2018 & 2020, which isn't the current thinking on sliver timescale. Would like to see in charter that we use the dot-x extensions are released on two year schedules. Want to see it match the other web standards like HTML. It means the regulators know they will get updates every couple of years. The structure can evolve over time, but would like to see that we have by-annual releases built into our work.

<Zakim> MichaelC, you wanted to say we are absolutely not in a position to commit now to 2-year updates and to say Silver is a better project to use for more frequent a11y guidance updates

MichaelC: Feel unready to make that sort of commitment, we haven't explored the costs & benefits of that enough. Silver would explore that, and feel more confident using that process. Doing it on the 2.x model, not sure we can commit to that. Not that we can't do it, but that we shouldn't promise to.

Josh: We took the 2.x approach to increase the speed and get through a back-log. What's there in the charter now is sufficient to do that, don't want to have to do a 2.2 if we don't need to.

Kathy: TFs have left things out because we didn't think we'd meet the deadline of Dec, so there are things that we would want to put into a 2.2.

<Zakim> AWK, you wanted to agree with the two year update cycle, won't impact table schedule

MichaelC: Good point. We don't know about the Silver timeline yet, so we don't have all the data, although that's normal and need to make a charter soon. Just don't want to promise to do that yet.

AWK: Our positions are fairly similar, it's been positive to say what our schedule is for the techniques & understanding documents. It does keep things moving. We can tip our hat to that thought process, without saying that we are doing it. Something is coming soon, but not sure we can say that 2 years from 2.1 we can say something is coming, whether that is 2.2 or 3.0.
... One of the criticisms is historically slow operation. We might not move quickly, but timely is good. Don't want 'living standard' that changes day by day, but it should be something people can count on. Also needs to have a clear relationship to it's predecessors.
... I'm in favour of saying something like "our intention is to offer updated guidance on a 2 year cycle. That might be in dot-releases, or in Silver..."
... The timeline here in the current charter covers next three years.

<Zakim> David-MacDonald, you wanted to say "which requires a major reconfiguration of the way" change to "which may involve a major reconfiguration"

<Joshue108> scribe: Joshue

<Joshue108> DM: Suggests..'While may involve..'

<Joshue108> DM: We may find out our previous way of doing things was ok.

<Joshue108> AWK: Don't think so.

<Joshue108> KW: Not given all the complaints etc.

<Joshue108> AWK: I'm happy to say we need a major makeover.

<Joshue108> AWK: If we let WCAG sit it will become less effective.

<Joshue108> JS: WCAG 1 and 2 were great for their time.

<Joshue108> DM: A two year cycle is very quick, a three year cycle would be better.

<Joshue108> DM: Needs more breathing room.

<Joshue108> AWK: Is 2.1 too fast?

<Joshue108> JF: Two year cycles are common in other specs.

<Joshue108> AWK: Lets continue this discussion at 4.15.

<Wilco> https://www.w3.org/WAI/GL/task-forces/conformance-testing/wiki/ACT_Overview_-_What_is_ACT

<JF> https://www.w3.org/WAI/GL/task-forces/conformance-testing/wiki/ACT_Overview_-_What_is_ACT

ACT TF Meeting

<Joshue108> scribe: Joshue

<Joshue108> AWK: In talking about this ACT work, it has an impact on our charter in that we have to describe e'thing that is a REC track deliverable.

<Joshue108> WF: I started the Auto WCAG community.

<Joshue108> WF: Rulesets and implementations are all different.

<Joshue108> WF: I see it as a project coming out of the ACT TF and community group (AutoWCAG community group).

<Joshue108> WF: So how to right rules for automated a11y testing is core work.

<shadi> [[example test rule: https://www.w3.org/community/auto-wcag/wiki/SC1-1-1-aria-describedby]]

<Joshue108> WF: There are different rulesets and they generate many false positives as a11y testing is context sensitive.

<Joshue108> WF: The idea behind the benchmark is to test the accuracy of the rules that are designed.

<Joshue108> WF: So you can create a rule for alt for example, design a filter to match strings patterns etc.

<Joshue108> WF: You can measure the occurance of these errors but it is important to understand the context.

<Joshue108> WF: We need to know how to gauge accuracy.

<Joshue108> WF: These tools if used as continuous integration processess the results have to be bullet proof.

<Joshue108> WF: So they dont break the build.

<shadi> KW: does framework include rule validation or just format?

<Joshue108> WF: We will be discussing how to write the rules, so it is consistent with the requirements that it is supposed to test.

<Joshue108> DM: Like BentoWeb.

<Joshue108> SAZ: Yes and no.

<Joshue108> SAZ: There are many different rulesets. The idea to find a common format for people to contribute etc.

<Joshue108> SAZ: If these are understood there can be convergence etc.

<Joshue108> SAZ: These can be put into a repo.

<Joshue108> SAZ: Rule development should be in the community groups.

<Joshue108> SAZ: Under the WCAG TF, the spec defines the format.

<Joshue108> SAZ: There could also be a WG note - on validation, and how to do it.

<Joshue108> SAZ: We also want a repo - soft deliverable.

<Joshue108> DM: A DB of the rules?

<Joshue108> SAZ: Yes.

<Joshue108> KW: Would it include manual review things/

<Joshue108> WF: Yes.

<shadi> [[example test rule: https://www.w3.org/community/auto-wcag/wiki/SC1-1-1-aria-describedby]]

<Joshue108> SAZ: Here is a manual test.

<Joshue108> WF: Give overview of what a rule looks like.

<Joshue108> JOC: Are these focussed on a11y problems?

<Joshue108> WF: Yes.

<Joshue108> SAZ: THey map to WCAG.

<Joshue108> JOC: Are they flagged as real a11y issues not things that may just be minor infringements etc?

<Joshue108> SAZ: Right now, they dont flag when things could be done better.

<Joshue108> KW: So you are looking at techniques?

<Joshue108> SAZ: Success Criteria.

<Joshue108> WF: They may or may not map to how SCs are used.

<Joshue108> KW: Looking at the SCs is a bigger challenge. How do you get consensus?

<Joshue108> WF: We want to figure out the places where we all agree - then we can work out where we dont.

<Joshue108> WF: This will help the WG understand where there are common misinterpretations.

<Joshue108> WF: We can then start growing that base.

<Joshue108> WF: We don't want to standardise how a11y testing is dont but just find common ground.

<jessebeach> queue

<Joshue108> KW: Theres not always a match.

<Joshue108> JB: Seeing these examples make sense.

<Joshue108> SAZ: These do not reflect the final format.

<Joshue108> AWK: How do you point to the error?

<Joshue108> WF: In this case we use EARL.

<Joshue108> WF: We've not decided if that will be required in the framework.

<Joshue108> WF: Selectors determine if a rule is applicable or not.

<shadi> https://www.w3.org/TR/Pointers-in-RDF/

<Joshue108> WF: If so it will walk thru the test procedures.

<Joshue108> WF: EARL has several ways to do this.

<jessebeach> queue

<Joshue108> SAZ: There are different types of pointers.

<Joshue108> JB: Seperating the algorithm from the report isn't tight.

<Joshue108> JB: I can write these things into Node modules etc but would only use the BOOLEAN.

<Joshue108> JB: It doesn't seem like you have to use the reporting.

<Joshue108> WF: Right, we may even pull that back further.

<Joshue108> WF: It comes down to PASS, FAIL, DONT KNOW.

<Joshue108> WF: Always one of these outputs.

<Joshue108> WF: We dont want to get in the way of that.

<Joshue108> WF: Reporting needs to be consistent.

<Joshue108> WF: In AutoWCAG on rules for WCAG 2.0 AA and for 2.1 we will start looking at that.

<Joshue108> WF: The ACT framework is not limited to WCAG 2.0.

<jessebeach> "The algorithm and the report are not tightly coupled" -> "The algorithm and the report are not tightly coupled"

<Joshue108> WF: Lots of companies have internal policies - they have their own ruleset that need to be implemented.

<Joshue108> WF: We have touched on the rules and techniques etc..

<Joshue108> WF: Techs are targetted at devs but rules are focussed on a11y problems.

<Joshue108> WF: We need to connect these two.

<Joshue108> RM: You have a tree structure between these things..

<Joshue108> RM: If you could capture what test rules applies to each technique you could see in a tree what you are hitting and missing.

<Joshue108> WF: We keep track of what techs the rules are related too.

<Joshue108> WF: SSB is looking at that, aligning techniques to automated testing rules.

<Joshue108> JB: I worked on a tool where we build tasks for WCAG 2.

<Joshue108> JB: We found limitations in testing the techniques, are fails one offs, or for each instance etc what is the outcome?

<Joshue108> JB: Whats good to see with this, is the Silver group can find the context of the test by thinking of the spec as something that can be tested.

<Joshue108> JB: I like the tight coupling.

<Joshue108> WF: We are looking at a three year timeline.

<Joshue108> WF: In year 1 we want a decent draft for framework.

<Joshue108> WF: Get to CR in the second year.

<Joshue108> WF: Then get the benchmark working on rules that are written according to the framework.

<shadi> [[schedule: https://www.w3.org/WAI/GL/task-forces/conformance-testing/wiki/Month_by_month_plan]]

<Joshue108> WF: Several members of the ACT TF have their own rulesets and we would like them to contribute those, so we have a repo that we are confident about and TF sees as good rules to have.

<Joshue108> WF: We will also have a recommendation of how to write the rules etc.

<Joshue108> WF: Anything to add Shadi?

<Joshue108> SAZ: Nope.

<Joshue108> SAZ: Schedule online.

<Joshue108> JOC: Very good.

<Joshue108> WF: I hope this will work for Silver.

<Joshue108> WF: Looking at the testability of the requirements is important.

<Joshue108> JS: Yes.

<Joshue108> SAZ: We want to help the group.

<Joshue108> SAZ: We want to find the balance that the group is up to date with this work.

<Joshue108> SAZ: Finding a good validation model will be important.

<Joshue108> SAZ: We are getting more members.

<Joshue108> SAZ: We hope to have participation in both groups, and give regular updates etc.

<Joshue108> SAZ: We may not have specific things to add right now, but just want the group to be aware of our work.

<Joshue108> JF: Is this a part of WCAG?

<Joshue108> SAZ: Yes its a TF?

<Joshue108> JOC: We need the ACT deliverable text.

<Joshue108> SAZ: Its in the work statement.

<shadi> https://www.w3.org/WAI/GL/task-forces/conformance-testing/work-statement

<Joshue108> AWK: Symbiotic relationship.

<Joshue108> WF: For testing of SCs this will be important.

<Joshue108> AWK: Techniques for future versions could be generated from a ruleset report.

<Joshue108> WF: This stuff is not sequential.

<jeanne> scribe: jeanne

<Rachael> Scope, 3rd paragraph, after 1st sentence, consider adding something like: "Dot releases will continue periodically until 2.0 is replaced by the next substantial release."

<AWK> JF: Still feeling adamant about clearly defined dates

<scribe> scribe: jeanne

AWK: Some of these pieces are not in the charter document because they are outside the charter timeline.

JF: I would like to see Q1 2018,and I want to see that 2 years later, there will be an update -- either 2.2 or Silver
... I want to see that this group make a commitment to regularupdates going forward.

<Joshue108> JS: What do you see as the advantage of puttingthese timelines in the charter?

JO: What I want is to get chartered to work on 2.1 and Silver. I don't want to put anything in the charter that puts it at risk.

AWK: There is a lot of work to do. [hypothetical dates]
... we have to say something on this document. I'm not sure how to thread the needle of the dates and the iterration

JF: Silver is something we haven't articulated yet. Silver -- we don't know the design.
... we have stated the milestones
... I want to put multiple stakes in the ground around it.
... I have had positive thumbs up from people I have spoken to.

David: I agree that setting things in stone could be a problem if situations change.

Shadi: I agree with Jeanne about not publishing every two years in charter. I agree with John, that we should publish more frequently.

<Joshue108> +1 to shadi

<Joshue108> I could live with that.

Shadi: My compromise is that we put in the charter that we will produce a requirements document, that way it keeps the pressure on the working group, and we aren't locked into 2.2. The charter only goes for 3 years, and we will have to recharter anyway

JF: I think we need to publish every two years, and we have to stay in lockstep with the rest of W3C.

AWK: The goals of this sort of change are 1) to incent the working group to keep up to date. 2) to manage the expectations that the WCAG WG is kpublishing periodically to keep up to Technology
... when Joshue and I started, we wanted to publish every six months. And now we do.
... I am looking at the Web Platform charter, and I can't find where it says that they publish every two years. [looks at charter]
... Whether we call it a goal, or an intention, but the question is what we want to put in the charter.
... most people are in agreement that its a good idea, but there is concern that it isn't easy, Not being easy doesn't mean that we won't do it.

<Joshue108> NOTE: After the publication of the 2.1 TR, the group will assess if further 2.x versions are needed and articulate this in future charters.

<MichaelC_> Looking through log, I see ¨we have to stay in lockstep with the rest of W3C¨. There is no reason we have to do that, we should do what is best. Take best practices when helpful, but don´t feel pressured into other groups´ practices if not applicable to our needs.

JO: There are things on the critical path -- like rechartering -- that we have to have to do the work.

<JF> @MichaelC a bit of a mis-quote. I noted this is an emergent pattern at W3C

AWK: Our intent is to publish 2.x revisions on a regular cycle until Silver is ready to publish.
... Can it be in the Scope section, or Introductions?

JO: It's a good question to ask Process-wise.

AWK: The socialization of concepts among the AC is a good idea. During the comment period, if the AC reps want us to update every two years, then we will do it.
... [example of a pointer events SC]
... each iteration after will get easier.

Kathy: We have a 2.1, and theere are probably things that aren't going to make it into 2.1. What happens if we find out that if the structure and how we put it together didn't work.

<Zakim> shadi, you wanted to ask about "predictable"

JO: We can change it if we have good documentation, but it affects our credibility.

SAZ: I agree with Kathy. I am not aware of a charter that commits to periodic update.

JF: Is that a bad thing?

<Zakim> Joshue, you wanted to suggest updated on text our process.

SAZ: laughs. Do what Kathy is suggesting and write a Requirements document at the end of this charter for the next document.

JO: I have updated the draft in IRC.

<Joshue108> NOTE: After the publication of the 2.1 TR, the group aims to release updated 2.x versions as required until Accessibility Guidelines 3.0 reaches TR.

Rachael: Do we have user testing can we do testing outside of the group to see what feedback we get

AWK: That's fine, somewhere between FPWD and CR

Rachael: What if we make a commitment to publish, can we poll the Task Forces to see what they want to do with the SC that aren't going to make the cut this year.

JO: We could have a "contract" with the Task Forces, that what we can't get into 2.1 would be rolled into a future version.

<Rachael> Can we ask the taskforce leads if they would be more comfortable with the SC that fall out if the 2 year requirement is in the Charter vs another type of committment?

Kathy: We know the Task Forces are stressed that we can't make the December timeline with all the work we want to do. We need to have a plan. There will always be things they missed.

JO: That's what we plan to do. Anything that does'nt get into 2.1, will get into 2.2 or Silver. The question is whether it has to go into the charter.

Michael: There is more of a promise (as of today) that it would be advantageous to do other plans. I see why it would be good to plan that there would be another document.

JO: We have to go to the task forces and take the pressure off them to get everything done
... What about the draft text that I proposed.

Michael: I don't want to be commited, I want to signal an intent.
... I don't want to signal the intent too weakly.

<Joshue108> NOTE: After the publication of the 2.1 TR, the group may release updated 2.x versions as required until Accessibility Guidelines 3.0 reaches TR.

<Joshue108> that's version 3

[discussion of whether the agenda advances or concludes]

[group agrees to continue the charter discussion]

<AWK> http://www.w3.org/2015/10/webplatform-charter.html

<MichaelC_> http://w3c.github.io/charter-html/group-charter.html

<laura> Milestones: http://w3c.github.io/charter-html/group-charter.html#milestones

MC: [reads the Web Platform Working Group Charter draft] We need to do some signalling what we want to do in the charter.
... but we have to be realistic what we can accomplish

AWK: Reads deliverables inthe draft WCAG charter.

<Joshue108> [DRAFT 3] NOTE: After the publication of the 2.1 TR, the group will release updated 2.x versions as required until Accessibility Guidelines 3.0 reaches TR.

Michael: An absense in the timeline doesn't mean that we aren't go to do it. The Deliverables are tied to the Patent Policy, the Timeline is guidance to the AC.
... I would like to see a link to page with a statement in an external timeline page.

AWK: Is there a template?

<MichaelC_> https://www.w3.org/2015/Process-20150901/#WGCharter

Michael: We are using the template. Most of what has to be in Charter
... [reads from Process 2015 document]
... it's not advisable to remove or shrink that timeline.

AWK: Talk to the AC reps and socialize what we want to do.

Michael: Be specific: Do you want us to publish regularly, and do you have a concern about putting that in the charter.
... we are straying into the space of "supergroups" [looks at milestones of the charter of CSS]

JO: It looks like that we will table this discussion and socialize the question

AWK: CSS has 30 specs, we have 3.
... We will break here and discuss next week.

<Joshue108> thanks for scribing Jeanne, and to Alastair, Rachael, DavidMacD and JF.

Jeanne: Socialize Silver

- DRAFT -

WCAG FtF

20 Sep 2016

Attendees

Contents

New Charter

ACT TF Meeting

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output