Meeting minutes
<rscano__> <rscano> present+
cwadams: introductions?
<AWK> +AWK
cwadams: future agenda items/topics to add to future list?
Decision about Publication Approach to WCAG 3
<alastairc> For the minutes: https://
cwadams: options regarding once-yearly release of wcag 3 in github discussion
… really good discussion there
… questions' phrasing might have introduced bias; this process is new to us too
… we'll be running polls in this meeting to try to correct that
… points:
… we can't assume legislators can adopt without working with them
… legislators might prefer single relase
… waiting too long
… needs of regulators vs implementers
alastairc: project plan says 4 years, this question came from "should we have something before then"
Rachael: we know conversation was hard to follow for many people
… we're working on addressing that
… you can also use github via email
cwadams: anyone who made a point we missed in the summary?
… poll time
… this question was already in github
… if we don't get consensus, then our current approach is the standing decision
Wilco: what's considered consensus in this scenario?
cwadams: hopefully a significant majority
… chairs were discussing this before
… not sure if that answered your question
Wilco: yes thank you
GreggVan: full consensus means everyone can accept it as a compromise
… broad consensus means you mostly get that
… majority is only 1 more than half, which is a problem
<alastairc> There is a binary decision here (the starting point), but I hope we can get to acceptance with some refinement of the option(s)
<Rachael> Consensus is not a vote. Consensus indicates that a substantial number of individuals in the group support a proposal. The exact number of working group participants supporting a Call for Consensus and any objections are not the only factors in the decision. Although significant support from the active membership is always desirable, consensus means working through objections until they are resolved either through amending the decision or in
<Rachael> rare cases overriding the objection as laid out in Managing Dissent. Objections must have a clear rationale based on the technical merit or with reference to the agreed scope of the work. Moving on usually means a careful approach is taken. For example, not adding something to the documentation.
GreggVan: chairs can call a question if it goes for to long
<Rachael> AG decision policy https://
GreggVan: is this written down somewhere [see Rachael's message above]
<cwadams> Should WCAG 3 1) continue building on WCAG 3 Outcomes OR 2) switch to starting from WCAG 2.2
cwadams: first poll question:
… "should WCAG 3:
… "1. continue on WCAG 3
… "2. switch to 2.2"
<GreggVan> 1
<dan_bjorge> 2
<alastairc> 1
<JakeAbma> 2
<Graham> 1
<JustineP> 1
cwadams: standing decision is option 1
1
<Wilco> 2
<Frankie> 1
<Poornima> 1
<wendyreid> 1
<Rachael> 1
<jeanne> 1
<Francis_Storr> 1
<mike_beganyi> 1
<jon_avila> 1
<ShawnT> 1
<ashleyfirth> 1
<tburtin> 1 WCAG 3
<bruce_bailey_> 1
<Jennie> 1
<AWK> 1
<julierawe> 1
<ToddL> 1
<DanielHE> 1
<jeanne_e_c> 1
<Jaunita_George> 1 or 2, there's benefits and drawbacks to each
cwadams: not a trivial question, so individuals supporting option 2 can voice their reasons now
<Graham> 22 for 1 and 2 for 2
<mbgower> 0, I can work with either
<laura> 0
Wilco: complete switch to WCAG 3 is tremendous value destruction
… new structure isn't proven yet
… transitioning to new structure will also take much more time and money than nessicary
… WCAG 2 isn't all bad; there are areas which need to be updated, but much of it is fine
<AWK> Is this question about using the WCAG 2.x _structure_ or using WCAG 2.x as the starting point, including the SC?
dan_bjorge: authors and implementors
… often look at WCAG because of legal requirements
<Rachael> AWK, about using WCAG 2.x as the starting point (not just the concepts of WCAG 2.x but the actual document)
<alastairc> AWK - starting with WCAG 2.x, then trying to update it to get to the improvements we've been aiming for in WCAG 3
dan_bjorge: with new versions, authors need to adhere to multiple versions at once
… incremental updates are much easier for that than completely separate versions
<AWK> @rachael and @alastairc - and as the question of backward compatibility would be answered next?
dan_bjorge: "absolutely incredible amount of busy work"
Jaunita_George: length of time
… will new standards be obsolete by the time we publish them
… apple's google glass just came out
… will new standards tackle new technology in a timely manner?
scotto: i wasn't sure what we were voting for
… process behind each option wasn't clear so i didn't know which way i wanted to vote
… in current poll
<alastairc> Scott, did you see this, and open the comments underneath? https://
cwadams: question to people with concerns:
… can you tolerate this, or would you strongly and formally object?
JakeAbma: we must be able to address people's issue before the projected date
<Glenda> +1 to what Jake is saying.
JakeAbma: we need an in between for WCAG 2 and 3
… we should have started this 8 years ago
… now it's too late, so we need an in between
(scribe note): so far everyone who voted 2 agrees with what Wilco said
wendyreid: confused by idea that moving to WCAG 3 is destroying WCAG 2
… no one here wants to completely throw out WCAG 2 --- there's so much good stuff in there
… but its model can't fit everything we want to
… there is a way to do this without loosing what we've already done
… lot of gaps
… lot of things content authors need which don't currently exist
<jeanne> +1 to the delay caused by the back and forth
<Zakim> alastairc, you wanted to rebut, particularly around structure updates.
<Frankie> +1 to Wendy's comments
alastairc: we started in october
… if you look at the project state in the project plan 4 years from now,
… i think it would take us longer to do that incrementally than to keep everything in draft
GreggVan: WCAG 3 started in 1998 when we were working on WCAG 1
… because they're they same issues we were trying to address then
… the structure of WCAG 2 doesn't allow us to bring forward the things which aren't strictly testable
… if there's just some things we want to tweak about 2.x, then do that
… if we want to address the things we couldn't in 2.x, then we need a new structure
… 3 will still cover the 2.x content
… we need to focus on what the new structure can bring in
<Zakim> jeanne, you wanted to talk about the years of research behind the decision to create WCAG3.
GreggVan: 2.x stuff will come in as outcomes
jeanne: brief history for new people:
… first 2 years of what became WCAG 3 was research
… partnered with academics and industry to research the structure of WCAG 2
… to say "WCAG 2 is good enough" is insufficient because we have independent research
… i can give links if you'd like
… there was a lot of work done well before it came to this group
… i don't want to see that work thrown away
<Zakim> Rachael, you wanted to answer scott's question
jeanne: it feels like this conversation is starting over
Rachael: scott: we started with a bunch of options,
<jeanne> Silverr Research Archive
<Zakim> cwadams, you wanted to talk about future retrospectives
Rachael: but this question felt too fundamental to address quickly
cwadams: we want to develop and review, not speculate
<Zakim> Jennie, you wanted to discuss change in who follows WCAG 2
cwadams: for those uncomfortable with any decision, be aware there's time built into schedule to address retrospectives
Jennie: audience of people following and implementing wcag has significantly changed since WCAG 1
… old structure doesn't work for now broader audience
Glenda: short term, it's still important to fix 2.x
… long term, reserve 3.0 for when we're ready to redesign structure
… and why don't we add Digital Accessibility Authoring Practice Guide right now
… living document
… like ARIA
… informs 2.x and 3.0
<mbgower> Introduce new considerations that can be used and adopted in the shortest period of time.
mbgower: a lot of what we're talking about right now is tactics
… it'd be good to also talk about strategy
<Zakim> mbgower, you wanted to say I'd like to see if we can get agreement on the strategy, first, and then talk about tactics
mbgower: a lot of stuff seems like tactical debates around the same thing
… we need to agree around overall goal first
Wilco: i'm not married to 2.x structure
… how do we minimize cost and efforts required of organizations when need to conform to both major versions?
… how do we keep pace with tech changes
… how can we predict what web will be like when we finally get recommendations out
<cwadams> dj: Regarding Jeanne's comment about research. It's important that we talk about it when we discuss.
<cwadams> dj: I haven't seen that, and wasn't aware of that. Maybe review the research and see what it is to inform our decisions.
<Zakim> alastairc, you wanted to comment on 'fixing' wcag 2.x, and whether we can introduce new things into that structure
alastairc: in response to Glenda and Michael
<ashleyfirth> That's ok. As someone new, I agree with DJ and would love the chance to read the research and then comment on the discussion.
alastairc: for example, VR module could be in WCAG 3 as guidance without a conformance model
… re: Wilco's question
<Wilco> can I clarify Alastair?
alastairc: i don't think organizations would have to conform to both at the same time
<mbgower> Sure Alastair, I think new modules is a tactic that can meet the goal I suggested. I'm not sure we have agreement on the goal.
Wilco: legislators in US/Japan could be on 2.x, Egypt could be on 3.0
… so organizations would need to conform to both
<jeanne> THis is not a new question. We were on WCAG 1 and WCAG 2 for a decade.
<Zakim> Rachael, you wanted to say that the proposed structure is designed to address tech change
alastairc: by publishing guidance early, we could focus on some pressing things first
Rachael: WCAG 3 structure was design to focus on logical change
… its outcome-centered structure can better address issues than 2.x
… such as focus visible
… clarifiaction: standing decision was that if there was enough interest in taking on 2.x then we could do that,
… but there wasn't enough interest
… so we decided the way of managing the overlap should be a detailed mapping document to clarify mutual coverage between versions
<cwadams> Draft RESOLUTION: Continue building on redesign effort (Silver, Outcomes, etc) as the way to create WCAG 3
cwadams: 0 for tolerate
… +1 for support
<jeanne> 1
<julierawe> 1
<alastairc> +1
<wendyreid> +1
<ToddL> 1
<Jen_G> +1
<GreggVan> 1
<Graham> 1
<JakeAbma> 0
<Frankie> +1
<Rachael> +1
<DanielHE> 1
<bruce_bailey_> 1
<mike_beganyi> +1
<ShawnT> 1
+1
… -1 for don't support
<Francis_Storr> 1
<Wilco> -1
<tburtin> +1
<dan_bjorge> -1
<Detlev> 0
<Bri> 0
<kirkwood> 1
<scotto> 0
<Jaunita_George> 1
<jon_avila> +1
<laura> 0
<Poornima> +1
<AWK> 1
<Glenda> 0
<kevin> 1
<ashleyfirth> 0
<Jaunita_George> +1
<Jennie> 0
<mbgower> 0
<ljoakley> 0
RESOLUTION: Continue building on redesign effort (Silver, Outcomes, etc) as the way to create WCAG 3
<cwadams> Should we publish to final rec track using 1) time boxed approach 2) modules or 3) as an entire document
Rachael: there are objections
RESOLUTION: Continue building on redesign effort (Silver, Outcomes, etc) as the way to create WCAG 3 (with objections)
Rachael: please email chairs with details of technical concerns with your objections
<alastairc> I think they were: 1. How to minimise the cost and effort of conforming to 2 versions, and How to keep pace with the technological changes.
Rachael: so we can address them when we go through with this approach
Jennie: is there a significant increase in number of 0s between this vote and previous?
cwadams: +1s increased
… 0s increased
<mbgower> 0 was "tolerate"
<alastairc> We didn't have a zero option the first time...
<Jennie> Thank you for clarifying
cwadams: also more attendance this time
<cwadams> Should we publish to final rec track using 1) time boxed approach 2) modules or 3) as an entire document
cwadams: adding something that wasn't in github conversation
… option 3 is wait until it's all complete
Rachael: that was the original support
<cwadams> Should we publish to final rec track using 1) time boxed approach 2) modules or 3) as an entire document, 0) unsure
Rachael: we brought it back for discussion because of concerns brought up about the first two, so we didn't want to remove it
<GreggVan> 3
<cwadams> dj: Can we vote for 2 approaches at once?
<alastairc> 3 as preference, with 2 if possible, and 1 as drafts...
<wendyreid> 2
<Rachael> 3, 2
<Graham> 2
<Detlev> 0 I have read the thread but I am unable to tell what is best, sorry
2/1
<Bri> 0
<ShawnT> 2
<tburtin> 0 I have read the thread several times and need more information / definitions to tell which is best.
<Glenda> 2
<Frankie> 2
<Jen_G> 2
<JakeAbma> 2
<jeanne> 2, 1, 3
<bruce_bailey_> 2 , 3 , 1
<dj> s/\//,
<ToddL> 2/3/1
alastairc: by default before this question we were going to do option 3
<dan_bjorge> ...none of the above? want to avoid separate documents, but would prefer objective-based approached to time-boxed or all-at-end
alastairc: other option was time-boxed output
<dan_bjorge> 0
alastairc: publishing whatever was ready at given time
<ashleyfirth> 2
<Wilco> 0; What Dan said
<rscano> 2
<laura> 2,3
<DanielHE> 2
cwadams: 2s are majority so far
… i see some individuals using 0 as "none of the above"
<Jaunita_George> 2
<AWK> The differences seem academic. Even modules are whole documents. Modules can be time-boxed also.
dan_bjorge: from my understanding, modules imply separate documents
<cwadams> +1 to AWK
dan_bjorge: and time boxed isn't objective-based
… i'd like objective-boxed
<ljoakley> Dan +1
Dan +1
<Rachael> +1 to adding a milestone based option.
<Wilco> +1
<scotto> +1 dan
<Jaunita_George> +1
<laura> +1
cwadams: Rachael: new poll with Dan's approach?
<Zakim> cwadams, you wanted to scribe change
<alastairc> This was based on the question: How do we get guidance out faster?
<alastairc> Modules would be topical guidance (e.g. guidelines for VR, or an updated keyboard & pointer guidance).
<alastairc> Time boxing was more applicable to starting from WCAG 2.x, but would be for the itterative approach.
<mbgower> time-boxed modules :)
<rscano> +1
<laura> Scribe List https://
<Poornima> I
Gregg: excellent document of COGA area.. here's the best guidance we have.. put a +1 on that thought
… on the Rectrack: am not sure I understand the purpose, maybe we should publish the drafts regularly
<Frankie> +1 to publishing regular drafts
<Glenda> +1 to what Gregg is saying about “COGA Usable” and the concept of a non-versioned living document called “Digital Accessibility Authoring Practice Guide” <<< not a legal requirement but SUPER helpful.
but not as a requirements or publishing formal documents as first
… until it is complete, no one is going to adapt it
… it's gonna be big haul until it is complete, put modules 3 and 2 both into it..
<rscano> +1 to publishing regular drafts
chuck: this is one of the valuable decisions, find this as one of the easiest decisions in modules
<Zakim> alastairc, you wanted to propose a different approach
chuck: acknowledging to Andrew and Gregg
Alaistair: iterative/time-boxed approach was more to the WCAG terms.. turning back to the original que, to put a time aside for the packaging module say keyboard and input, do we put time to packaging
wendy: we are maybe getting little bit hung up on the publishing, update the main document every time, if we are thinking the recommendation process, update wcag rectrack drafts
<alastairc> Could do, options: Do we put in effort to publish stand-alone modules of guidance before the final WCAG 3 is published? +1 / -1 / 0
<Zakim> cwadams, you wanted to ask Alistair if we repoll on 2 options?
wendy: instead of waiting for 10 modules to complete, the modular approach can be more doable and work..
<Zakim> kevin, you wanted to comment on publishing as Notes and potential consequences
Kevin: if someone wants to write notes in rectrack, that could be problem in how patent policy related material is handled
<cwadams> proposed RESOLUTION: Put in effort to publish stand-alone modules of guidance before the final WCAG 3 is published (+1 / -1 / 0)
<jeanne> Use the CSS model
Kevin: you could create modules in rectrack , say module for accesible VR
<mbgower> +1 to stand-alone modules (REC track)
<scotto> +1 to wilco's point. already feeling like i shouldn't be voting right now
wilco: I'm little reluctant to go for this like on the poll, the rectrack to conform modal and guidance, as there is a good difference
… don't know we could say yes or no to the modules
Rachel: curious for a strawpoll for modules or single document
<Wilco> +1 I like that much better
<rscano> +1
<alastairc> StrawPoll: 1) Should we explore publishing modules further 2) Should we continue with a single document
mbgower: i really do feel wcag 2.2 is going to sit there and adopt, until it is completely replaced
StrawPoll: 1) Should we explore publishing modules further 2) Should we continue with a single document
<julierawe> +1
<jeanne> The US took 10 years to switch from WCAG 1 to WCAG 2, that didn't stop developers from implementing WCAG 2
<Graham> 1
<rscano> +1
<GreggVan> 2
<mbgower> +1
<dj> 2
<Francis_Storr> 1
<alastairc> 1, fine with 2.
1, and 2 also fine to work in parallel
<Rachael> 2, fine with 1
<jeanne> 1 but fine with 2
<bruce_bailey_> 1 -- noting that action words have been "explore" and "put in effort" -- but fine with 2
<ToddL> 2/1
<dan_bjorge> 2
<Frankie> 1
<ShawnT> 1
<laura> 2, 1
<Detlev> 0 you have lost me
gregg: modules are seperate great ideas, advantage of making notes, allows us to keep changing or adding
<cwadams> 9 ones, 6 twos
gregg: like this is our word in a short period of time, and keep updating
… i think the question was creating the formal recommendation document, when we really continue to be working on this to move on
<tburtin> 0 perhaps could we have each option written out to think more about?
<Glenda> voting 1 - creating INFORMATIVE useful guidance in useful focused modules (like..let’s do one on VR/AR with what we know TODAY)
<cwadams> 10 ones, 6 twos, 1 zero
<mbgower> The value of a REC is that it can be adopted. The interim releases could be both RECs _and_ other guidance. Gonna have the malleable challenge no matter what.
Alastair: wendy made a good point of how messy it'll take, malleable to change or update
<alastairc> Suggest we (chairs) investigate further, and bring it back
<cwadams> +1 to alastair
dan_bjorge: echoing wilco's point, question is are we doing as informative/normative? is the scope going to be outcome/technology based?
<scotto> agree with dan/wilco. i'm not sure i'm comfortable voting still, as i wasn't at the beginning
<Jon_avila> Module term in problematic for me for the reasons stated.
gregg: the question of normative is like surely the objection, if you look at wcag 2, say a module on VR, this is going to be recommendation, and get frozen there
<cwadams> Me too!
<alastairc> This was trying to answer the question: What could we put out prior to a full WCAG 3 rec
gregg: VR refers to many things, movies, webpages.. if we are talking about informative modules, am happy.. but taking this as a normative, which are recommendations itself that can't be change, then i see this as problem
<Jon_avila> I agree with Gregg
chuck: am suggesting if the group is comfortable with this proposal on wcag 3
Alastair: if people are interested, we can bring this back
wendy: we have done a lot of work in planning this out, naming, grouping, but none of them are published.. does the document go out complete or in part?
… we can take an approach if the project lead or chairs to suggest how do we go with this as a draft like focus on one outcome
<Detlev> aside: there seems to be a lot of overlap / redundancy in current outcomes, would not want to see them punished as is...
<Detlev> published not punished
wendy: one document with all of the outcomes, and segment them as informative modules
<Zakim> Rachael, you wanted to say intent right now is to publish in draft quarterly
Rachel: we do publish public drafts quarterly twice
… there is a question how do we approach to breaking out this? this conversation is all about it
<jeanne> WCAG Research Summary document that was used for the Design Sprint for WCAG3
chuck: no resolution yet, will bring this back again
chuck: we are going to discuss wcag 2 topic / proposals
WCAG 2 Issue Resolution
<cwadams> https://
Alastair: Keyboard 2.1.1
… basically, it is possible to pause this without going for convention, may not be a good thing
… doesn't require everything to be able to mouse with a keyboard..
… next one is 'accessible authentication'.. Issue 3198
<alastairc> PR for keyboard: https://
chuck: reg. 2.1.1, not sure what the latest proposed version of changes, if you are not following normal conventions, and not haven't bugged i
<Zakim> cwadams, you wanted to ask about 2.1.1 keyboard when alastair finished
mbgower: chuck, that's how normally I would do too, that req exists in 508 , but not wcag.. if we deviate from standards, then we need to document it
… trying to capture recommendations or considerations, there can be .. it's a good point to capture and note here
<cwadams> +1 that's clever!
<mbgower> yep, it's a stretch. :)
Glenda: .. we can file it under 3.3.2 Labels or Instructions
alastair: we are not going to sort of ask of resolutions on this, but highlighting them on the list if any issues, and we can tackle them
alastair: now discussing 'Pointer gestures'
… it should not be changing requirements, the descriptions are available already.. just checking if it matches sort of expectations
<Zakim> mbgower, you wanted to say here's the link to the document I was talking about https://
mbgower: the link to the document is here, to formalize
alastairc: i think we are good to go, if any points to help with this, continue adding
… sectioning elements, that are updated.. there were questions about why this was added to wcag 2.2, there was a response, feel free to add comments
<alastairc> https://
alastairc: you can follow along this project as in the link posted here
… any comments, please add. otherwise, this is going to be published by next week
mbgower: if anyone has updates on card sorting process, any good feedbacks, share
Frankie: when exactly this is published?
<Zakim> kevin, you wanted to react to fran
kevin: the first thursday of every month I have time for publishing
… based on materials available, timeframe, techniques and understanding documents that are merged will get published
<alastairc> This is an improvement to the previous.
Rachel: 11 people complete the card sort so far
… have a schedule to bring back in 2 weeks to talk about the outcomes, agendas and more
… leaving it open to the 30th jan
<mbgower> https://
chuck: reaching to the end of the call
<mbgower> that is the card sort and the categories; two different links
<laura> Scribing Commands and Related Info: https://