Meeting minutes
WCAG 2.x update
alastairc: proposed scope of changes
… 1. refining, clarifying, resolving
… 2. not aiming to cover new requirements
<Rachael> presentation: https://
alastairc: it is more of spliting or combining things
… 3. not diverting current focus
… backwards compatiility ..
… checking the risk of breaking backwards compatibility
… topic is surrounding the potential of breaking backward compatibility
mbgower: if the sc is numbered version, we may not need to worry much about breaking the backward compatibility
GreggVan: if we make it less stringent, we may not need to worry about breaking backward compatibility
<mbgower> I find some people have completely opposite interpretations of 'backward compatible'
<Zakim> shawn, you wanted to say small benefit and worth reconsidering
group talks about different/various cases of backward and forward compatibility...
shawn: We've always made backwards compatibility a requirement, as there are strong reasons for it. one benefit is if you have to meet WCAG 2.1, you can meet the better WCAG 2.2 and you are covered for WCAG 2.1. OK to reconsider for specific cases.
<giacomo-petri> +1 to what Shadi said
<GreggVan> +1
<AWK> +1 to SAZ
shadi: what if each country does adopt the different version of wcag.. if that case, backward compatibility can be matter.
… sharing the strong reasoning for the backward compatibility.
<Makoto_U> +1 to Shadi
hdv: if there is no backward compatibility, when people use different versions like government cases, it adds, on top of the work of making things accessible and usable, it also adds admin workload
without backward compatibility
GreggVan: the "stronger" sc like 2-2 vs 2-3 or the subset structure of the sc
<Zakim> Rachael, you wanted to ask if it is only breaking backward compatibility based on interpretation
GreggVan: may solve the backward compatibility problem
<Zakim> alastairc, you wanted to comment on the process
alastairc: we are trying to find whether this is the useful thing to work on rather than bringing out complete agreement on the backward compatibility topicl
<GreggVan> what I was saying in brief was --- If 2.3 is always less than 2.2 -- no problem. pass 2.2 and you pass 2.1, 2.2 and 2.3. If 2.3 is always more than 2.2 you are safe again 2.3 passes 2.3, 2.2 and 2.1. BUT IF 2.3 is sometimes stronger and sometimes weaker then Passing 2.3 won't pass 2.3 and 2.3 won't pass 2.2 and you get a mess.
awk: it depends on how people understand the concept of backward compatibility. we have to be realistic and stay clear on the interpretation of backward compatibility.
… and move on
group is looking at the examples for discussion
alastairc: is demonstrating the internationalization example - sc1.3 ruby annotations
Slideset: https://
<AWK> +1 to Gregg.
GreggVan: for 1.3.1 example, we can just add notes because this is the same as 1.3
<Makoto_U> it was SC 3.1.6 pronunciation
GreggVan: this does not need new provision.
<hdv> +1 to Gregg
<Ben_Tillyer> 1.3.1 normative text for reference: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.
<AWK> What does you mean by default not on, Mike?
<AWK> Who creates the blue text?
<mbgower> The AT
mbgower: 1.3 requires association with visual presentation and in this case, 1.3 is not enough to explain the accessibility of this example.
GreggVan: it is already exposing the accessible name with programmatically associated relationship
<kevin> Might be worth looking at Example 2 in H62: https://
<AWK> Feels like some part of this issue may be related to how browsers/AT expose or provide information to users.
<kenneth> (H62 was specifically raised during the session as an existing example of this)
GreggVan: either it can be author-exposed and or AT can expose it using accessible name. so I don't see the reason to create new criteria
alastairc: this was proposed by the member
Jemma's suggestion which support AWK's suggestion - why don't we stay on creating the general consensus on the concept of backward compatibility.
<AWK> My understanding is that the Ruby text is rendered in the tags as Actual text or something like that within the PDF tag structure, and would be programmatically associated.
<AWK> Page 20, 8.2.5.23 Ruby (Ruby, RB, RT, RP) on https://
<kenneth> FWIW one of the slides Alastair was showing from Murata-san's presentation explains that for a long time PDF didn't have a way to progammatically convey ruby
<GreggVan> +1
<Patrick_H_Lauke> oh, forgot about timing adjustable...another one of my classic hairball issues
alastairc: three topics
… 1. internationalization topic
… 2. clean up things
GreggVan: we need to lock down rather than having the new version. and let's fix the 2.2. misunderstanding
<Patrick_H_Lauke> if it's unclear/wrong in wcag, it means en 301 549 locked down these unclear/wrong interpretations?
GreggVan: 1. Ruby case is about 1.3.1 2. regarding the "understanding", we can add the clarification on the concept.
<Patrick_H_Lauke> can an understanding doc clarify normative wording to the point of changing the meaning of the normative wording? i thought not...
GreggVan: add it the understanding doc.
<Patrick_H_Lauke> is new contrast algo not also applicable to "old" colour space?
GreggVan: 3. color space editor case - it can be done by just clarifying concept ad providing the sufficient solutions
<Zakim> mbgower, you wanted to say user agent exceptions too
<JJ> +1 to mbgower
mbgower: it is really important understanding is that somem problems are intractable based on backlog group working experinces.
<Patrick_H_Lauke> "when we say black, we actually meant red"...
mbgower: understading doc is not normative doc
<kevin> +1 to not having informative materials contradicting normative materials
<GreggVan> +1 to can't contrdict but didnt hear one of those
<shadi> "we said black but actually we now wish we would have said red"
<Zakim> alastairc, you wanted to comment on getting group understanding
mbgower: we will keep having this intractable problems over and over and adding the explicit description would not help much
<Patrick_H_Lauke> +1 consensus achieving versus deadlock
alastairc: time adjustable is just one example and we need to have the consensus on this - people interpret the content in a different way in contrast to it was originally intended.
<AWK> Consensus doesn't mean 100% unanimity
alastairc: it would be hard to get the agreement on and move on like that of AD example
<mbgower> i don't think it's ambiguously worded at all.
<alastairc> Less ambigious than interpreted in the reversed (for a partiucular scenario)
<JJ> normative changes will also benefit WCAG2ICT and WCAG2Mobile
<AWK> I agree, mbgower
GreggVan: pointing out the ambuguity of the wording and the group can make it clearer.
… I don't hear any contradiction examples.
… trouble is getting the agreement.
alastairc: it is updating current sc like AD.
GreggVan: we can update understanding doc
alastairc: I will ask Mike and Patrick to think about
giacomo-petri: RE the ruby issue, maybe this can be covered via a combination of needs across multiple SC e.g. 1.3.1 and 1.3.2
… we may just need to ask more techniques or add more clarifying languages
<Zakim> mbgower, you wanted to say can we give the folks on the task force sufficient credit to believe there are challenges and no one on this call is going to solve them in the next 5 minutes.
alastairc: I don't see the problem of making more clarifying contents
mbgower: the big problems is that there is no way we can solve the problems in 5min..
… we are looking for the better tactical ability to work on these complex issues
Patrick_H_Lauke: are we arguing about clarity or contradiction?
… talking about example..
… the current wording does not much wiggle room
<mbgower> Reflow has been pretty problematic in its normative language. Target size has had some real sticking points.
Patrick_H_Lauke: working with Giacommo, to come up with mitigated, soomth over, programtic languages to reflect the reality.
<Zakim> alastairc, you wanted to comment on perception verses interpretation
Patrick_H_Lauke: if the language is not clear like the example of text and image, we sometimes contort ourselves into logical pretzels to stay within the normative wording when attempting to clarify.
<Patrick_H_Lauke> reading the wcag tea leaves / entrails
alastairc: we can make tweaks if that change the outcome or xxx
<alastairc> it is changes to the normative text
<AWK> +1 to GV. That is what understanding is for.
GreggVan: is talking about the way for the working group - we should work on xxx
… normative and critical things
<AWK> A new normative version is by far the less easy path forward. We don't even know if we can get member company agreement on a new charter with a forked approach.
<Patrick_H_Lauke> clarification WILL diverge from previous one if the same normative wording has been interpreted in two or more different ways
GreggVan: like working on immediate impact items
<Patrick_H_Lauke> take wrong as "too vague that it was being interpreted in wildly different ways"
<JJ> Given the timeline of WCAG 3, there is still time for WCAG 2.3 to be adopted in legislation
<Patrick_H_Lauke> so it's semantics to say "so a clarification is not changing the meaning" when the clarification shuts down one interpretation, so for the person that did interpret it the "wrong" way will see it as a normative meaning change
<Zakim> mbgower, you wanted to cover w3c/
alastairc: if we don't change the meaning or outcome - ex; sychronized media, we can do the editorial changes
<Zakim> Rachael, you wanted to ask about editor's notes
mbgower: We have traditionally had a no-fly zone for this sort of thing
mbgower: target size minimun got thumbs-downs because it's a class 2 normative change that's not backwards-compatible
alastairc: That's something we have encountered as a group - if there's anything that involves a normative change, it requires a new WCAG version, and people won't accept anything less
Rachael: Is there a middle space with very specific normative changes, editorial changes, and editor's notes with a .version
<Patrick_H_Lauke> don't worry Makoto ... i already had the issue/PR in progress when you jumped in
Makoto_U: sharing the example of missing clarification and explanation among wg experinces
GreggVan: difference between normative text vs normative meaning
… example of block of text - the wordmanship may be need because the intention/meaning was not changed
<AWK> 2.5.8 is different than "block of text". I do agree with that one. But these are different SC and we knew that when we published. not sure why is imperative now.
<Patrick_H_Lauke> Maktoto_U see the proposed PR I already had since 2021 ... w3c/
GreggVan: the chages over AD by version in 2.0, 2,1, 2.2
… if we take and reword the sc and make it clear rather than changing the meaning..
… that is the viable thing
<Patrick_H_Lauke> but where is the cutoff of "reverses meaning" versus "clarify the meaning". again, if some normative wording has been interpreted in two wildly different ways, clarifying/collapsing the quantum state of the SC to just mean one of the two ways IS reversing it for people who interpreted it the other way
shadi: responding to Rachel's question - EN 301 549 refer to WCAG 2.2 - with publication date - any version would not be picked up because En31549 is already done.
<JJ> In software the .1 would be a patch version, and you would expect that version to behave the same except for fixing unintended behaviour (bugs)
shadi: if the change to be reflected in EN 301 549 is working on understanding doc
<hdv> JJ: good point, and also means backwards compatable
<Zakim> alastairc, you wanted to comment on contrast being embedded in normative text and to comment on the granularity of changes for target size making it different
shadi: if updated WCAG normative changes, depending on whether the update is a revision or requires a new version, the latter would not automatically be picked up by regulators
<Makoto_U> +1 to Patrick. Nobody is wrong, everybody is correct. So this situation is not simple ....
https://
<GreggVan> +1 to collapsing the quantum state analogy
<Zakim> mbgower, you wanted to say that if anyone thinks it changes the meaning, it becomes a class 3 change
<kevin> s/> ... shadi responding/shadi: responding/
<mbgower> https://
alastairc: shares the different cases for embeded chage in sc, or disagreed some changes in some sc so on. We get stuck on these because they are perceived as a contradictory normative change to some people.
<JJ> Why not both? A patch version 2.2.1 and updated understanding docs for 2.2 achieves clearer understanding in two ways.
<mbgower> or come up with a new version
<mbgower> But the whole point of what we're trying to do is IMPROVE a problematic SC
mbgower: It becomes a class 3 normative change as soon as someone disagrees with the interpretation
GreggVan: we may need to agree on the "requirement" and walk through the issues very carefully to understand what it means.
… what we need to do next is to line up what all the provisions need to be
… official interpretation, editorial changes.. and need to talk about next action items.
<mbgower> In other words if we're unhappy with the 2 options of interpretation, can we move to something everyone can live with as an updated requirement?
<Ben_Tillyer> Just done some double checking. EN 301 549 v4.1.1c (2025-09) defines WCAG 2.2 as being available at https://
alastairc: It would be good to arrive at an approach
… can merge non-normative changes as we have been; can look at what's editorial
<Jaunita_Flessas> +1
<Jaunita_Flessas> Actually, +1000
alastairc: would we consider normatively changing a few things like collapsing interpretation?
… each thing would be on a case-by-case basis, but would be OK with publishing that sort of thing in the next charter period?
<JJ> +1
shadi: I think it'd be useful to have an exact backlog of these things, not just for example but actually we want to change X, Y, Z, so we can look at the benefit vs. downsides
… downsides in terms of efforts drawn away from WCAG 3, potential fragmentation causes (it won't be directly adopted because that ship has sailed)
… it'd be good to get an assessment of effort before answering that question
GreggVan: When do you need to know? If it turns out that it's really critical to do this, we don't want the charter to prevent us from doing it.
<AWK> +1 to SAZ. We need data
GreggVan: I don't think people are giving enough weight to the fact that this might be disruptive and not what they want
<Patrick_H_Lauke> to Shadi's point: for a list of things the WCAG 2.x backlog TF has been working on ... it's all logged/documented here https://
GreggVan: if we have time, I'd like to see this listing of revisions, to see if there are other ways of handling
… and if there are some left, assess the impact of that
<Patrick_H_Lauke> from that we can probably make a more authoritative "hit list" of "these are specifically the things that we need to..."
GreggVan: for example, with audio descriptions: is this really a problem? Are people being sued? Or is this something that someone has decided we have people in the field interpreting it differently, but it hasn't had sufficient impact to warrant going through the process of addressing it
… we could burn a lot of time on this, and putting out another version raises...we could have hours of discussion on the impact of that.
… so can we get a list of the identified pain points, and once we have that list, talk about putting something in the next charter?
… if not, why go through all of the grief that would entail?
… when does charter decision have to be made by?
<Patrick_H_Lauke> for the "is it actually worth it?" point ... I'd much rather spend my energy on that right now, than work on some WCAG 3 that may or may not come into force and be relevant for my day-to-day auditor work in the next decade or so
kevin: Charter was extended by 6 months from October 31 to April
GreggVan: so we have a couple of months to decide
<Zakim> alastairc, you wanted to ask do you really want a whole thing in one go?
alastairc: Because the TF hasn't had normative updates in scope, those things which have come up have essentially been put to one side, or just get stuck e.g. the timing adjustable one from a while ago
… so yes, things can come up. We want to be putting a new charter forward by January, ideally; we don't want to use up the entire charter period
… one thing to consider is the pain and effort experienced by those using WCAG 2 day-to-day - if you're interested, consider joining the 2.x Backlog TF calls on Fridays
shadi: I know this is controversial, but honest question: is it worth considering a separate WG for this?
[Kevin shakes head]
kevin: in this particular case, that would be counter-productive and probably take more resources
… one of the concerns raised is that we don't distract too much from the development of WCAG 3
… I think if we have a separate WG that probably does more of that, because it needs e.g. additional Team resources
… it creates separation within the group, whereas I think within the Backlog TF they've been effective at working through the issues within there, and not distracting from the WG
shadi: It seems to me like 2 very separable projects here
<Patrick_H_Lauke> +1 thanks for picking that up alastair. yes, "is it worth fixing this?" disproportionately affects people like myself working at the coal-face actually doing audits day in day out *right now*. and i'm not here trying to find hypothetical holes in WCAG 2.x SCs ... all issues i've raised over the years are things that I encounter in the wild *right now* (either personally, or when providing advice to colleagues/more junior au
<Patrick_H_Lauke> ditors/when i'm QAing their assessments)
shadi: I don't know if there's any real discussion happening in the main group, maybe the TF is essentially doing that already
Kevin: There's more overhead involved in an additional WG
hdv: Really torn on this. I see a lot of value in proposals, like what Patrick just shared, and what we've seen earlier
… it'll be more specific, it'll benefit users, it'll be good for accessibility if these updates make it to the public
<Patrick_H_Lauke> also ... as an aside ... a lot of the questions that came up in WCAG 2.x backlog discussions CAN actually inform WCAG 3
hdv: we'd love for WCAG 3 to be done tomorrow but it won't, it'll take time, so it's worthwhile spending time to resolve issues with WCAG 2
… I get what Shadi says RE it might not be picked up in many places.
… I don't know if the time waste is in getting ideas out of it, or working out how/when to publish or in what form
… I don't know what the solution looks like out of the options we have. I don't know which option is best. I hope there's a path we can find, because it will benefit a lot of different people.
<JJ> A better WCAG 2 will also create a better WCAG 3 imo
hdv: I think it's helpful that this work is done and that we find a way to incorporate it.
… Maybe that involves making it very explicit so that regulators can opt in
kevin: I just wanted to highlight the perspective from the charter, putting aside Shadi's thought on that one specifically
… we don't necessarily need to be very specific in the charter as to what we're going to address; we can say we are going to address stuff.
<Patrick_H_Lauke> +1 to kevin's point of keeping charter vague (having just gone through charter update for pointer events WG)
kevin: that's possibly a nice thing to do, as keeping the charter vague allows you to develop an understanding, and it's not constraining you in any way, which is a valuable thing.
… that isn't saying that it's not doing what we need to do, in terms of understanding what we need to change
<makoto_U> +1 to Patrick. We encounter gray areas in our daily assessment work
Ben_Tillyer: RE Hidde saying these changes will benefit users, I agree completely.
… If we as a group decide we are not going to make normative changes or substantial editorial changes that will benefit users because of difficulty in process or difficulty in adoption, I think we must publish an editor's note or supporting document explaining we have decided not to publish an update with these changes
<Zakim> alastairc, you wanted to comment on resources / TF and to also suggest we need a tie-breaker option, which is a new version.
Ben_Tillyer: I don't see how I'd be able to negotiate on that. If we weren't going to publish normative changes, and weren't going to tell people why we're not doing them, I would be really upset.
alastairc: The way I had seen this working would be in slightly expanding the remit of the TF. It doesn't particularly change the process. Anything informative runs as it does now.
… we would be stacking up changes to go into a 2.something.
… I think that might help in terms of some of the discussions. The potential new version can be used as an escape hatch.
… have 2 decisions: one that is applying currently, in current regulations, and a new version that might not be picked up anytime soon, but is something that our group members can point to, that some enthusiastic organizations might pick up as the clearer version
Jaunita_Flessas: I am fully in support of this idea, because we're talking about 5 years before the standard is even published.
shadi: re what Kevin was saying about vagueness… yes do want to leave room and not tie oneself down too much. But leaving too open can be a recipe for disaster
shadi: if we're going to do formal publications that potentially break backwards compat that's a different ballgame
shadi: good chance that it draws attenton to that away from WCAG 3
shadi: how much vagueness are we talking about/
<hdv> s///?
Patrick_H_Lauke: from my POV my focus is to ensure 2.x makes sense, it impacts by day to day work, doing audits for customers right now, who need to comply with current regulation
Patrick_H_Lauke: I'm glad we started the WCAG 2.x backlog task force. I remember ranting about this for many years. We had about 700+ open issues against WCAG in GitHub. It's a long standing tech debt.
Patrick_H_Lauke: I don't go out to try and find gaps in wording… these are usually questions from myself, clients, colleagues, junior auditors… they might not be really important issues but they are questions that exist right now
Patrick_H_Lauke: we're getting there.
<Rachael> +1 the work that resolves issue contributes to WCAG 3 as well
Patrick_H_Lauke: some of the discussions that bubble up from the backlog task force raise points that feed back into WCAG 3. It's not complete isolation. Vagueness in SCs relates to real world problems
<JJ> +1 Patrick_H_Lauke
<hdv> +1 Patrick_H_Lauke
<alastairc> qv/
Patrick_H_Lauke: this work informs WCAG 3 as well
Patrick_H_Lauke: legislation wise, as much as we would love to, even when WCAG 3 is out, we will still have certain legislations refer to WCAG 2.
<Rachael> +1 that value exists beyond just legislation adoption
AWK: One of the points I'd like to make is that there's always going to be issues that come up that require clarification.
… that has been the case since we were working on 2.0. Before 2.1, there were issues we needed to clarify. We were doing understanding updates to resolve clarification issues.
… there's still a lot of that to do, and there will always be a lot of that.
… Alastair asked whether we would support doing an additional version. I can't say for sure that I wouldn't, but I'm inclined to say it isn't worth the WG's time, to do as a normative update
… I think it's very much worth the WG's time to do understanding updates and techniques that provide clarification
<Zakim> kevin, you wanted to say WG or TF is the same resources and existing charter has vague option for 2.3
AWK: if we do this, it's going to consume resources and time that could go to WCAG 3
… so my gut is it's a bad idea
kevin: The resources argument is an interesting one. Ultimately whether it's a WG or TF it's the same group of resources; it's us.
… The existing charter has a vague option for 2.3, with no further detail
… RE AWK: I worry if we take a hard decision to _not_ do any 2.x normative updates, we back ourselves into a corner that does not allow for fixing certain things
… e.g. internationalization issues in the breakout this morning
… that one does worry me
<Zakim> alastairc, you wanted to say that apart from the contrast update & i18n, it's lots of small things in one charter period
alastairc: RE nature of updates, I can understand people wanting to see what we would be changing. It's lots and lots of small things, with 2 exceptions.
alastairc: contrast update: there's a lot behind it e.g. research, but this would benefit both 2 and 3
… there would be certain things we could do in an updated WCAG 2. The ruby thing was one aspect, but there were also potential updates to maybe add a non-latin equivalent (visual presentation? text spacing? both? can't remember)
… it's possible we're missing equivalent requirements for other regions. These would also apply almost directly to WCAG 3.
<Patrick_H_Lauke> +1 to alastair's points
alastairc: the rest are lots of small things we can take on a case-by-case basis, and I don't think that will take more resource or more time. A little bit more time because we need to bring normative changes to the group.
… Timing adjustable is being interreted in 2 different ways, about 50/50
… Audio description, similar situation. We've got several things in a quantum state, unable to collapse that in the current version.
… I don't see how we get around that without a new version, unless we come up with another option
<AWK> Kevin, under "Normative Specifications" in the charter WCAG 2.x is not listed. Don't know how we view that as not a definitive list?
shadi: I was primarily referring to the big ones that will really create, e.g. changing color contrast. These kinds of substantial changes. Not really listing all the other ones in the board Patrick shared
… maybe it's a matter of tagging which ones would require normative? Maybe the tags already exist?
<Rachael> +1 to a brief line by line discussion
shadi: I wanted to come back to the argument that kevin was saying it's the same resources. Not entirely. Yes there'll be a big overlap, but primarily I think the chairs' time is very valuable.
… if it were to be 2 separate WGs for example, would it be the same chairs, or separate chairs, some focusing specifically on WCAG 3, some focusing on 2.x day-to-day
… there might be some group members who are more interested in one over the other
… I think mixing them together can considerably slow down the development of WCAG 3, if we're going to do publications of the 2.x series. We've seen in the past where that takes all the air time
GreggVan: RE 50/50 decisions; that confuses me as to why if you changed the words you wouldn't still have the same 50/50 argument.
… I think we need to figure out what these things mean, vs. trying to rewrite them, if you will
… without getting the list in front of us, this is spinning our wheels. We need more data. We all want to resolve the questions, fix the things that need to be fixed, in a way that will be adopted, not in 10 years, but right away.
… some of the less-drastic things will get it done sooner, faster, and with more adoption
<Zakim> alastairc, you wanted to comment on chairing / resource and to also say why it would resolve the 50/50s
alastairc: That's exactly the approach I've got on screen right now. We do the things we can right now, and stack up the things that might need a new version.
<Patrick_H_Lauke> things HAVE been brought from wcag 2.x backlog TF to the wider group as a whole. weekly. as they come up/are being worked on
alastairc: RE shadi's point on chairing resources, I don't think there'll be an increas on us, partly because Mike and Bruce are in the TF already. What we are doing is untying the TF's hands, empowering them to resolve issues in the future-version column
<Patrick_H_Lauke> it's not like backlog TF have just been tinkering around in darkness...
alastairc: the things that are going to take the time are going to apply to WCAG 3 as well, and it will help us to have them resolved.
… with things as they are, we can't change the current normative wording, and people have objected to making errata-based updates without a new version. Having a potential new version unblocks a lot of those previous discussions.
<Zakim> Rachael, you wanted to concern of splitting
alastairc: We can take these on a case-by-case basis. Internationalization and contrast will likely need a new normative version anyway. The rest we can take case-by-case along with the informative stuff we have so far
Rachael: The concern of splitting something so inter-related makes it harder for cross-pollination. We've seen cases where things have split off and lost their connection to the WCAG 3 work.
… always supportive of reducing the chairs' work, but important to coordinate across working groups.
… I thought it was interesting that color contrast stands out as one of the bigger issues. Maybe we should allow subgroups to explore areas like this in more detail. Maybe we look at that and figure out what makes it feel so different
… and figure out what the ruleset is as to taking on a change in a specific update
<Zakim> AWK, you wanted to ask why people have objected to errata without a new version?
AWK: RE people objecting to errata without a new version. We already have a process for editorial changes (fixing spelling mistakes, etc.) - Are those the things people are objecting to?
alastairc: e.g. with timing adjustable, because people couldn't even agree on precisely what the details should be, we couldn't update the understanding document
AWK: The WG needs to spend the time to come to the conclusion on that, and that's the thing I'm saying will take up quite a bit more time and slow down WCAG 3 bit by bit.
GreggVan: I suggest the problem is people arguing what it means. We have to agree to what it means in order to make a normative change anyway.
… I'm trying to figure out if people are arguing that it should be one way or the other, or if that's just what they thought it said.
<AWK> both are happening, imo
GreggVan: if the wording is just ambiguous, then we should be able to handle it in Understanding.
… e.g. for color contrast, you wouldn't be changing the definition, you'd be changing the directions on how to apply it in a given color space.
… if we can't agree on what something should say, then making a new version won't get rid of the argument.
<Patrick_H_Lauke> new contrast algo will also apply to the same colour space as the old one. it's not just a new algo for the new colour spaces...
GreggVan: Let's sit down, get the people on both sides together, have a separate meeting to talk it out, then come back. I think that will be more productive.
… then we can get it off the table.
<Zakim> alastairc, you wanted to comment on agreeing what it meant, and what it could mean now.
alastairc: I'm going to run through a scenario. there's a difference between agreeing what something meant, and what people are interpreting it as, and agreeing what it could mean now / in the future.
… Using audio description as an example. We've got the people who were around when it was written interpreting it one way: if there are no gaps in the audio, you have to read down into the definition and into one of the notes, to realize you don't need to have AD to pass
… there's another group of people who are reading it on the face of the spec, saying it doesn't have an AD and therefore it doesn't pass.
… I have a great deal of sympathy with the point of view that that's what it meant, which was required to get to consensus at the time, because it was much more difficult to implement audio descriptions
… fast-forward 17 years, people are reading on the face of it, if it doesn't have AD, it fails.
… my initial thought would be, let's clarify what the original interpretation was, and let's change it in a future version. But I think we'd have an objection even if we clarified that in the Understanding document.
… I think we'd get objections from the originators if we went with the face-value interpretation.
… Regardless of the new version, in the previous version, we'd have to come up with something that we agree with or not, or leave it in its quantum state.
GreggVan: I agree with what you said, RE the 3 layers (what it did mean / is interpreted as / want it to mean)
… question is what were they thinking back then. It's still not something that's easy to automate, still takes expertise, it's still hard to do now.
… What we need is a thorough examination of what they were thinking and why they were thinking it
… what would have led them to this other conclusion rather than think what you are thinking now?
<Patrick_H_Lauke> (wonder if we'll ever get to the "but nowadays AI in media players will be able to just generate AD, so authors won't have to do anything" - similar to the headings discussion yesterday)
GreggVan: I'm not sure if we can figure out something that doesn't require drastic measures with a lot of consequences
<shadi> +1 to Gregg
<Zakim> Rachael, you wanted to suggest that we have a path forward
Rachael: It sounds like we do have a path forward though that we're all talking around: take the cap off of the discussions on normative content.
… right now we get things into that class 3 of normative change, and just stop talking about it because we don't touch these in our current approach.
<Patrick_H_Lauke> "no cap" as the kids say
Rachael: can we agree that the subgroup should start having those conversations, and prep something to bring back to the main group for consideration?
… I think this conversation was incredibly informative about what kinds of information would be helpful for the group to hear
… but it seems like the TF should have the remit
alastairc: That's what I've been talking about - it would be case-by-case, but at the moment those conversations hit a dead end if they include that kind of normative update.
GreggVan: I agree. I think we have 3 paths forward: definitely should take the cap off and let them explore them
… I think they should think about the ones that are stickier, and for those, schedule a meeting with the broader group, so they don't come to a decision that then gets shut down when brought up to the next level
<Patrick_H_Lauke> gregg, this has already been happening. big issues HAVE been brought to AGWG meetings
<Patrick_H_Lauke> let's not make it sound like wcag 2.x backlog has been trying to sneak things past AGWG as a whole
AWK: When we say, should we ask the TF to come forward with proposals to the WG for things we think they should target, that's one thing
<shadi> +1 to AWK
AWK: but RE the next charter period, I'm not convinced we should make that decision
Rachael: I think we should commit as a WG that they can commit to _exploring_ the normative changes
AWK: We have to know whether they are permitted to explore or effect those changes
Rachael: We can leave it open in the charter
<Patrick_H_Lauke> WCAG 2.x Samurai ....
AWK: I would probably vote against leaving it so wide open. The WG should be able to make a decision as to whether it's going to do these types of things, based on e.g. here's the top ten issues that have been pain points
… I'm not sure we've seen a slate of the things, I'm not sure we've seen them as a group
Rachael: To echo back, from an AC point of view, you would want to have a clear definition of how we're handling this for the charter.
<Zakim> alastairc, you wanted to ask how to get around the original meaning vs mass interpretation, as both have objections
AWK: Yes, from an advisor to my organization's AC perspective
alastairc: We have a few things where we've got a difference between the original intended meaning and the current mass interpretation, and we get objections to the other interpretation
… and it's not just a little bit of text. As a chair, it's hard to find a compromise on
… there are objections from either or both sides on taking either interpretation
… if anyone has advice on how we get around those kinds of disagreements. As Patrick mentioned, those sorts of things _have_ been brought to the group, and we haven't gotten anywhere
<alastairc> Less time if we can decide what it should be.
shadi: I don't have advice, and I do recognize these types of discussions can take a lot of resources in my experience
… I got on queue to raise similar concerns to AWK in terms of vagueness, concerns of draining resources from WCAG 3
GreggVan: re-raising the "get everyone's point of view in a meeting" approach
alastairc: We did that for timing adjustable (10 times vs. 10x duration), we included you as well
<Ben_Tillyer> timing adjustable thread 1) w3c/
alastairc: my bigger point on that was, if you get stuck on that kind of thing, it can be easier to say, from this future point forward, here's how to clarify it from now, without having to go back
<Patrick_H_Lauke> opens w3c/
GreggVan: There will also be potential argument around levels
<Zakim> kevin, you wanted to ask why
kevin: I'm a bit perplexed with shadi and AWK's comments, and why the lack of specificity in the charter would be such a problem. I think nobody's suggesting that we don't have a plan. Nobody's suggesting that we don't be clear on the issues we're looking to address.
… I don't quite get why that level of specificity needs to be in the charter. I think that introduces a lot of constraijnts that make it very difficult, that when you get to the point, it ends up being different than what you thought, and then the charter has locked you into a position.
… I'm seeking to understand what the concern is, if we allow for a little bit more openness in the charter
AWK: Suggestion to chairs: I don't know if the group has recently gone through the exercise of determining how it's going to make decisions about things related to issues of interpretation
<Patrick_H_Lauke> 50% + 1 share
AWK: maybe we should have something for you to fall back on out of that. e.g. if the WG feels that something is 9 points out of 10 and another is 1 out of 10, maybe we can arrive at different conclusions, but it's difficult to go through that process when you're focused on a particular issue
AWK: RE Kevin: Part of it for me is I think that we've seen the WG over the years, including when I was heading it up, be able to extend deadlines, keep working on things longer, and work gets delayed, because there are distractions
… I think this would constitute those types of things
… On top of, I think there are other member companies that are concerned with how the WG does its work, and want to have a well-incubated specification before they agree it's okay to take it to REC track
… we would like to have an opportunity to go forward and create something that is able to be in REC track, and be more agile about that
… the group tends to want to do 2-3 year charters. If we did shorter charters, it might allow us to be more nimble.
… it would be a mistake to allow the WG to write itself a blank check to allow itself to update WCAG 2 when we're trying to get WCAG 3 in shape and ultimately out the door
shadi: responding to Kevin, I don't intend to require specifying everything so far down in the charter that your hands are completely tied
… but "will explore updates to WCAG 2.2" feels too vague, and doesn't convey an understanding of what it entails
… I asked myself with the timing adjustable issue, how much of an issue is it, how much fragmentation is it creating, is it worth the effort
… how much vagueness and "writing a blank check" is there?
<Zakim> alastairc, you wanted to comment on timing for WCAG 2 updates
shadi: The concern with being too open is that it may continue to delay development that is already very delayed
<Patrick_H_Lauke> "how long is a piece of string" / "how vague is too vague"
alastairc: On that timeline aspect, I would anticipate that this could be essentially a time-constrained thing. We can prioritize the backlog, and say that everything we agree to in the first year of the charter goes into a CR at the end of the first year, goes through the process, and gets published before the end of the charter period
… it's something we can fit to the time as opposed to a thing which could continue indefinitely
… I would hope that allays some concerns
Ben_Tillyer: The current charter says that for non-WCAG3 work, we are to continue addressing open WCAG 2 issues, so I think that's the scope
… I feel that the chairs and the group has been doing a good job at closing the issues that do not warrant editorial changes
<Patrick_H_Lauke> as for the specific example of "10 individual instances of extension versus extending to 10 times the original time" ... that originally came out of a live question during an actual real life audit of a site for a client, and needing to decide whether it was normative pass or normative fail, and whether customer is breaching legislation or not
<alastairc> It's the TF that's been working on closing the issues, the chairs just let them get on with it :-)
Ben_Tillyer: in capacity as AC rep, as well as personally as AGWG participant, I feel that the charter is fine given its current wording
… if those issues require normative changes, isn't that being inferred in the current wording aswell?
kevin: The charter is not specific about limiting the work to non-normative changes only.
… the limitation for that has come from the pushback that we have about addressing those normative changes. It's more that we've imposed that on ourselves, it hasn't been imposed on us by the charter.
alastairc: I think we've probably got to a point where we will go look at what would some of the prioritized changes be. I think Kevin and the chairs will work on what we will be putting forward as the charter
… there will probably be offline conversations about that as well
… I don't feel that tackling the name will help us at this stage
<Ben_Tillyer> can I confirm, as @AWK and @shadi's "no" isn't minuted, and opposes @kevin's minuted response, that my interpretation of the charter is correct?
Policy guidance
Rachael: This is something that would complement WCAG 3, a note, not a portion of WCAG 3
… a note to policy makers on how they might use WCAG 3
… we always try to distinguish between conformance within WCAG 3 (the "ruler") and compliance which is not within our scope, and is what policymakers do
… gives us an opportunity to make suggestions around that space
Rachael: wanted to give a general sense
… state what standards can/can't do, identify gaps where policy needs to pick up
… notion of scope, not necessarily an entire site
… e.g. if I have a site that sells things, and I don't have checkout flow within my scope, that seems like a bad thing
… recommending sets of supplemental requirements and assertions
… recommending dates or expirations on conformance tests
… handling bugs/complaints, e.g. rating severity of issues
… guidance on handling audiences with required abilities (e.g. airplane pilots)
… guidance on partial compliance and how that might be reported or evaluated
… suggest importance of organizational maturity (processes/assertions) and improvement over perfection
… how to encourage honest reporting
… how to handle third-party content
<Jaunita_Flessas> +1
Rachael: what are people's thoughts?
Jaunita_Flessas: I think this is great, and we should probably include some leading standards e.g. EN 301 549, and identify areas where we might recommend policy makers increase scope or push standards forward
… not necessarily just standards by themselves, but also ancillary things that the law requires currently
… I would think third-party would be a big area
<Jem> I think "Ways to encourage honest reporting" is the interesting idea.
shadi: Really welcome this work.
… very very nit-picky, on previous slide, RE informative note, I would encourage us to make even more abstract - informative guidance - not worry about whether it's a WG Note or e.g. a separate web page
<Jem> This was the big topic for Silver Task force group. - policy implication with WCAG
shadi: that will allow us to figure out later what shape this has
… some of this seems to go beyond just policymakers, e.g. sampling/evaluating almost feels like a separate piece
… I think to me it's very limited to the very first bullet: what does WCAG 3 cover, and what do policymakers need to pick up?
<Jem> +1 to Shadi
shadi: I don't think we should be giving advice to policymakers as to what regulations they should incorporate, that may be scope creep. We should focus from a technical committee perspective, we wrote a spec, we know what it can and cannot address
… for example, here are 3 conformance levels, you need to pick a level
… depending on how WCAG 3 is structured, let's say it maybe provides even more granularity/levels, you could maybe think about different kinds of levels for different industry sectors
… that is the kind of advice I would expect in this kind of guidance document
… a lot of the other things seem beyond just for policymakers. Not saying they're not good to think about or work on, but not the core focus to me
GreggVan: I think there should be 3 goals.
… Some of these e.g. sets of supplemental requirements seem way too detailed.
<Jem> "Suggest the importance of organizational maturity (processes/assertions) and improvement over perfection" seems to be reasonable.
GreggVan: First goal: understanding. A lot of the group Shadi led a while ago needs to come in here. They need to understand what the issues are that we've discovered.
… Second: topics or aspects that they need to consider, which will come out of the understanding.
… Third: suggestions for how to address some issues, e.g. bugs
… the first two are purely informative. The third is a little bit pushy; the reason for doing it at all is that if every country takes the same guidelines but applies them differently, you can lose all the great work we did in harmonization.
… the point of the second goal is for the topics to be a summarization
… caveat for goal 3, specific regulators may know something we don't, so they may have reasons for doing certain things a certain way
<Lisa> COGA made an appendix for policy maker . see https://
<Lisa> feel free to use any ideas there :)
<Zakim> alastairc, you wanted to ask how we say it's difficult to apply WCAG to a whole site, you need to do some sampling without that advice. Also, levels does solve different types of content.
alastairc: shadi said we want to do the first bullet mostly
shadi: that seems to be to be the most relevant one
alastairc: the framing is that this is informative guidance for policy makers, we are not trying to make policy documents
alastairc: for policy makers to make the best out of WCAG
jeroen_: policy guidance is interesting for a lot of member states in the European Union and outside, but it might not be just one document, more like a collection of documents or thought or ideas
jeroen_: in the Netherlands we refer directly to WCAG-EM, it works really well for us, in order to get data in a standardised way
jeroen_: might be worth looking at breaking up into different kinds of documents so that legislators can refer to them more specifically
giacomo-petri: re guidance for policy makers, we want to be as comprehensive as possible. We in this room probably all agree that reaching 100% is impossible but we should guide policy makers to help them get it right
<jeroen_> +1 qiacomo-petri
shadi: in my mind, in WCAG 3 there is the formal document as well as supporting guidance (like the Understanding docs and Techniques with WCAG 2; the entire object is WCAG 2)
shadi: there could be several kinds of guidance pieces, like an evaluation methodology or scoring system, that policy makers may adopt or use it, probably not exclusive for policy makers either, consultants might use that too
shadi: it would be helpful to map out these documents and what they contain
shadi: what does the WCAG 3 “package” contain?
mbgower: I don't use WCAG-EM but look at it sometimes… looking at the bullets in the slide, if there's non prescriptive methodologies that would be great. There's different scales to it too
mbgower: it'd be good to know how does it apply in different situations
<Zakim> alastairc, you wanted to comment on the focus
alastairc: to shadi's point… for this document / set of documents, we should keep the audience in mind … it is about saying when you apply WCAG you might want to recommend a sampling methodology
<Zakim> kevin, you wanted to suggest message rather than messenger and to engage with policymaker stakeholders to understand needs
alastairc: next step would probably be: who would like to work on such a document
kevin: it would be not to worry about the mechanism for this message
Kevin: might not be a document, might be something on a website, doesn't necessarily need to be a working group note or something like that
kevin: we'd do well to engage with policy maker stakeholders to understand rather than making assumptions
jeroen_: agree with Kevin
jeroen_: governments are probably willing to look at W3C for guidance even outside formal documents
jeroen_: as government we prefer documents to be more widely reviewed and welcome this kind of guidance from a place like W3C
Jem: re Rachael's question on if there's anything we need to add… was curious about a process regarding handling complaints… can someone explain how this is related?
GreggVan: could you explain 'provide guidance on handling audiences with required abilities?'
giacomo-petri: together with honest reporting also consistent reporting
giacomo-petri: eg I work on RGAA and ittakes a lot of time to map the French requirements to WCAG requirements
<Zakim> alastairc, you wanted to reply on bugs/complaints bit
alastairc: the cost of the lack of harmonisation…
<Jem> lack of harmonization is a great word.
alastairc: re bugs/complaints: this has to do with larger site to be consistently conformant
alastairc: this is encouraging people to a maturity approach rather than hitting people with a stick
<Zakim> Rachael, you wanted to answer gregg
alastairc: trying to tackle the balance between getting to 100% and @@@
Rachael: regarding handling audiences: this is about creating applications for specific audiences, like software for an airplane, where you can assume specific sets of abililities that are already required
GreggVan: are you talking about content only pilots would access?
GreggVan: others may want to access it too?
GreggVan: we may need some good examples.
GreggVan: I wouldn't currently take anything off the list
Rachael: are there things that are missing from the list?
<Jem> These sound like a good list to start with.
<Jem> I am just curious about "Ways to encourage honest reporting"
GreggVan: I'm thinking of problems that will arise when we try to apply requirements as rules
GreggVan: it's important that we don't give them advice, it's that we give them understanding
<Makoto_U> FYI: Guidance docs in Japan https://
<Zakim> Makoto_U, you wanted to share guidance docs available in Japan
Makoto_U: fyi have similar guidance documents in Japan, we have guidance separately for polciy making, procurement, assessment and a11y support
Makoto_U: we made it concise, simple and easy to understand
<GreggVan> I would word it "problems that arise in applying stanards -- separate from any recommentations on how to handle them.
<shadi> +1 to Makoto
<Jem> It is a good example including procurement, Mokoto!
Rachael: chair hat off, we have this new concept of trying to age out requirements when they can be met with the accessibility supported set
<Zakim> hdv, you wanted to respond to understanding
<Jem> +1 to Rachael
hdv: This is something that is being explored in AB as well, the focus on what W3C can recommend to policy makers and having that be specifically about understanding rather than telling them what to do as members have their own dept for that
<Zakim> Jem, you wanted to ask what is the policy implication of "encouraging honest reporting"?
Jem: what sort of policy implications are there if people aren't honestly reporting?
GreggVan: re what Hidde said… when we in the WG make the case in a policy doc specifically, it is likely to be seen differently than when ACs individually talk to policy makers to try and reduce their regulatory pressure
GreggVan: what about non-browsers? if something like browsers or AT can make it so that author doesn't have to do anything, doesn't mean we take it away, we can just say, 'when x is available in a user agent, then…' req can still be there
GreggVan: we don't need to take them out
<GreggVan> +1
Rachael: I completely agree. But think we need a section in our guidance on how that works
Rachael: re honest reporting… don't know what the solution is… there's a challenge or fear particularly in the US where ppl are afraid about what will happen when they fail requirements
… sometimes people don't want to know how (in)accessible they are. There's some space where an approach to help encourage people to make claims about where they are is useful
<Zakim> alastairc, you wanted to comment on the automatically meeting, and making sure regulators don't continue to require things of authors past that point
alastairc: +1 to those points
alastairc: re aging out requirements… it would be helpful to make that really clear to regulators and everyone else, so that we don't build up dogma about it
alastairc: re reporting… we had ideas around that some places have an ombudsperson, monitoring people who can take a sample of things / do some smell tests to see if people's statements are accurate
jeroen_: +1 to alastairc
jeroen_: in the Web Accessibility Directive, there's also a requirement for a feedback mechanism, in our case it is the national ombudsman
<Jem> +1 jeroen
alastairc: so when somebody notices a statement isn't correct they have somebody to complain to
<JJ> +1 jeroen_
kevin: caution about this is to not go too far about it
kevin: we need t be clear where we stop, it is a fine line to walk
kevin: when we talk to policy makers, there are also cases where we need to push back
jeroen_: I agree with Kevin. Some kind of policy reference guide, pointing to best practices
shadi: agree with Kevin and Jeroen. We should be driven by goals we have for conformance… there was a subgroup where we developed scenarios where conformance is more challenging
shadi: to avoid that we end up keep adding more infromation, we should be driven by the boundaries of conformance
Jaunita_Flessas: one way to not cross lines is to define things for policy makers, like third party policy makers, the things that need to be in an assertion, what a review process might be. Could help policy makers without us saying do this exact thing
<mgifford2> Ben_TillyerI was disappointed that the UK monitoring document just specified axe, but not how to move from this document to a government-wide scanning approach. NZ & Singapore have done better at providing open source solutions for this.
giacomo-petri: honest reporting needs some nuances… it could be subjective, too. I've seen reports done in good faith, but were not be very good reviewed from the point of view of a professional auditing agency
giacomo-petri: who defines honesty?
alastairc: this is about how reliable testing is
<Jem> I think honesty is related to transparency...
<Zakim> JJ, you wanted to suggest reproducable
<Jem> and consistency
JJ: reproducability is the most important part for me… when I can use the report to reproduce and verify the claims
JJ: on the web you could archive pages to check afterwards if it was honest or correct
kevin: how can we encourage organisations to admit failure and what challenges does that bring?
kevin: if they effectively say they don't comply that can have consequences, but there is a lot of value in being able to see there are problems
kevin: in the WAD and UK regulation there are requirements to add a list of failures. Where orgs are basically admitting they don't comply. Great for users as they can use this information
mgifford2: there's a problem with WCAG not talking about rules or referencing ACT. Automated tools are important evaluating large websites
mgifford2: from a CMS perspective (Drupal maintainer) I think about systems
mgifford2: I'm thinking we need discussion on how automated tools can or need to be used as part of modern accessibility evaluation
mgifford2: they are essential, not sure why it is missing from the guidelines
<Zakim> alastairc, you wanted to comment on automated testing
alastairc: to mgifford2's point, as a standard we try to be a mechanism for UIs (WCAG3) / web interfaces (WCAG2), the standard says this is what accessibility looks like
alastairc: there is a definite overlap with how to use scope testing / what is required
hdv: Some regulators already mention automated testing, e.g. in the EU the by-yearly reports.
… agree that it's a helpful thing, just a matter of which doc it should be in.
<mgifford2> How we have tried to address this in Drupal - https://
hdv: and for WCAG3, it could be an assertion.
giacomo-petri: we need to consider edge cases, like in some cases automation is not possible eg banking login will be tricky to automate
giacomo-petri: shouldn't force companies to do something tehy cannot do
mgifford2: we should help people follow best practices
mgifford2: from talking to the Canadian employment agency … there are best practices for internal systems that are not followed even by governments, there may still be easy ways to make it happen if the systems support it
mgifford2: we should try raise awareness about it
shadi: I'm hearing at least two separate strands… both important. One, more general, re best practice and encouraging realistic approaches, the Dutch brought their 'comply or explain' approach when we were working on the Web Accessibility Directive
shadi: but this may be out of scope of this particular WCAG 3 discussion. This is probably an additional layer, putting this in practice. This would equally apply to WCAG 2, it is more generic
shadi: here we might want to focus on things that are specific to WCAG 3, to make it a better ruler for rule making
<Jem> +1 shadi - agree with focusing on WCAG 3 with policy.
<Zakim> alastairc, you wanted to comment on how we'd raise awareness
giacomo-petri: banking example was just an example, testing manually can be as effective as automated testing if it is very small. Let's focus on the goals
alastairc: re mgifford2's comment… people may push back on certain situations… we can describe which exceptions need which kinds of things
<Zakim> Rachael, you wanted to ask why only focus on wcag 3
Rachael: wanted to ask Shadi, isn't it somewhat arbitrary to focus just on WCAG 3?
<Zakim> shadi, you wanted to respond to Rachael
<mgifford2> We could also include automated testing and policy advice in any new revisions to 2.x
shadi: we know how far WCAG 2 goes, my hope is WCAG 3 will go further
shadi: hear me out… if we had more levels than 3, like 5; would give us other possibilities
<alastairc> I also hope that because WCAG 3 goes further, the policy guidance should therefore be smaller than it would be for WCAG 2.
shadi: would give us other mechanisms
shadi: part of it is that the conformance model in the technical document of WCAG itself, the other pieces are outside probably, like the evaluation part and something for policy makers about putting the bits together
<mgifford2> kevin - NP on removing references. It is both open source and a Digital Public Good, plus a government created one at that. So pretty neutral.
shadi: the issue we have with WCAG 2, it's fairly binary, one of the main issues WCAG 3 is trying to solve
Ben_Tillyer: we've talked a lot about assertions, it would not be unreasonable to ask organisations that make these reports to assert that the conformance claim matches the content of internal defect locks
Ben_Tillyer: maybe not making the test credentials identifyable but maybe something that matches the public information
<Zakim> Rachael, you wanted to suggest reframe
Rachael: I was thinking of conformance centered content
GreggVan: I think it would also be good to add the advice to include non-testable stuff
GreggVan: in EN 301 549 we don't require AAA but we list every single one of them
GreggVan: we should make sure that that gets on our list to include.
Rachael: so we have two different ways we could go… we could flesh out an outline for the 'package', or we could look at who is interested in working on this
<jeroen_> I volunteer as well :)
<Rachael> https://
Rachael: in previous slides we talked about all these different concepts… how do we want to take them? what pieces might we want to create?
… we have things that are more conformacnce centered and the concept of an evaluation methodology
<jeroen_> I can't edit, Rachael, but I'd like to be added to that list :)
GreggVan: it's not Understanding WCAG 3 but understanding the problems faced by people
GreggVan: it's understanding problems faced by implementors and evaluators, like I just got 10,000 videos and someone says they're not accessible
<Jem> is it like subgroup under AG?
GreggVan: before telling them how to solve it we need to ensure they understand the problem
<Zakim> Jem, you wanted to ask how and what it takes to work on this project including the expected deadlines...
Jem: I'm debating whether to sign up. What's the deliverable and often will we meet?
alastairc: that is to be defined, minimum output would be some guidance for policy makers, either a document or set of web pages, first task of the subgroup would be to work that out. Would expect regular meetings
alastairc: you'll have a couple of years
GreggVan: sign me up
<mgifford2> I don't think I can get sign up to additional regular W3C meetings, but I'm certainly willing to provide feedback on the policy recommendations document as it evolves.
kevin: just wanted to check are we thinking about the stuff that was identified in the Silver research that would form part of the WCAG 3 “Understanding docs” equivalent? Like user needs, methods tests, information for developers/designers etc
kevin: is that part of this as well?
alastairc: probably not all under guidance for polcicy makers but there are parts that should go into this bit
[shadi shares screen]
shadi: this is the work Gregg was referring too, it started off in a wiki
shadi: for all these situations where conformance is challenging
shadi: we provided some examples of things that are hard
<alastairc> Is the wiki page a better resource than the draft note?
shadi: interesting part is 'how technical standards might contribute to addressing the situation'
shadi: with bugs/issues, one idea can be severity levels and more granularity
shadi: there are a lot of questions re accompanying / supplemental guidance… things like good practices on writing accesssibility statements in machine readable format
shadi: in other situations we had things like prioritisation
<GreggVan> can someone post the URL for this document
shadi: and then there is how policies can help address the situation, like type and volume of the content in question
shadi: there are also a lot of website types, like small business vs very large ones
shadi: the reason I am showing this… we came at this from a conformance angle… and the q how can we address these situations and what are the different parts to it? Might help generate the content for these pieces we want to develop
shadi: so let's look at what are the conformance issues we're trying to address rather than what are the types of documents we want to write?
shadi: severity and consistent ways for reporting, maybe that comes out of the technical standards, part of thje reporting piece… still belongs to the technical aspect of the standard
Rachael: incredibly helpful, thanks for reminding me of this document
<Zakim> kevin, you wanted to react to shadi to ask for new scribe
GreggVan: The thing in the WG that we agreed on were the problems. The part where there was controversy was whether they should be addressed in technical standards at all, or whether they would be policy issues.
… there was a note on the page that I referred to as the "Shadi-led workgroup output"
… I tried to pull some of the topics; I think it's good to grab the headings and put them in this document. I got partway through it. (the whole thing is tl;dr)
shadi: This is why I think these pieces need to be developed together with the technical standard.
… we have a very different situation now because we have much more granular requirements now than we had in WCAG 2.
… We can do many more things. The documents can impact each other in both directions.
… if we find issues, maybe we can take them back to the people writing them and do something about it
… having these developed together is more important than sequentially
Rachael: To clarify, I don't think we were suggesting that the policy guidance would be sequenced after WCAG 3. But there is a lot in the how-tos that makes sense to be done after the normative work, e.g. detailed role-based content.
<shadi> +1 to Rachael
Rachael: I think policymaker content has to go out at the same time
… RE reporting evaluation methodology, I don't think that's as important to go out at the same time, I don't know if others agree
<Zakim> alastairc, you wanted to comment on instance vs requirement
Rachael: I don't think that all of the informative docs are equally important, but the policy-making document is critical
alastairc: Shadi, I know you're pushing for various things in the conformance document. I'm going to agree that I think they sort of do need to develop side-by-side
… I am very skeptical as to whether us defining more levels actually would help very much
… if the regulators generally pick a particular level, then those other levels kind of fall away
… I struggle with us trying to define whether this thing in this granular way is more important than this other thing.
… Policymakers are in a better position if they're changing things by scale
… e.g. UK central government defines either a level or a level plus a set of assertions that government departments must do
… not every single one needs to be scored against every single one, but e.g. you need to do the usability testing one and the automated testing one
… disability testing involving people with disabilities may be required
<Zakim> shadi, you wanted to speak to timing
alastairc: I don't think we can sit here and create all of those things ourselves. But we can provide things that policymakers can hook into.
shadi: Processing what you said; the devil lies in the details.
… Let's imagine we only have the 3 levels as suggested, but on top of that we have some kind of scoring mechanism that tells you how far off the mark you are.
… there's still conformance level Bronze or whatever and you failed, but the difference between WCAG 2 and 3 is now I can tell you how far off the mark you failed.
… that might not be part of the technical standard itself; it might be an addition, part of the reporting or evaluation or something, where it tells you how far off the mark you are.
… that can be guidance to policymakers: set a bar, but maybe focus on people farther off the bar
… We can only do such a reporting thing if the requirements are written in a more granular way, as they are now. I think the granularity is very positive as it gives us the ability to do these kinds of things
… to build an evaluation methodology on top, to give us a better feeling of how well you're doing, what you need to focus on
… gives us the opportunity to write guidance to developers on what to focus on first
… especially paired with tags as discussed yesterday
… I don't think they need to all be developed at the same time, they're not all equally important, they can have different delivery dates. I think that's totally OK.
… but in the beginning, I see a kind of tree trunk, where they need to be started together, since they influence each other.
<Rachael> +1 to a cohesive approach
shadi: the design of the requirements impacts the methodology, impacts what we can recommend to policymakers
… we need a cohesive approach.
… As we branch out, when each one gets delivered, yes there can be prioritization.
… I hope that response to both Alastair and Rachael.
jeroen_: To add a bit to your suggestion; in the Netherlands, the bar is AA in WCAG 2, but we also have partial compliance which we show every 3 months
… makes it very clear to policymakers what the organization is behind on / focusing on
… partial compliance has been very important to track progress over the years
shadi: But if you have a methodology that gives you better clarity on how far they are...
jeroen_: So we have some indication of progress, but it could be way better than it is
GreggVan: We need to be careful that we don't mix the policy with the technical. It's good that they grow side-by-side, ruler and rule.
… and that way, when we have something that shouldn't be in the standard (the ruler), we have a place for it to go in the policy document (the rule)
… you don't want to end up in a situation where it's not going to be accessible but also technically not possible to do
<Zakim> giacomo-petri, you wanted to mention granularity vs n of instances vs context
GreggVan: so it's very good to separate those too and have them in parallel
giacomo-petri: I agree with almost everything Shadi has said. I think granularity will help, but it's not enough.
… e.g. now we're able to distinguish between informative and decorative images. But at the same time, if we have 100 decorative images in the page but have no alt attribute, it can still be a problem
… the number of things that are working can be difficult to objectively count
shadi: Not necessarily. We know that that approach gets very difficult very quickly, as you start playing numbers and getting lost. But what if you get minus points for missing a functional image?
… e.g. -50 for missing one functional image, -10 for missing one decorative image. Could stop counting at one point because you know you found 3 wrong ones.
… it depends what you're looking for. If you're looking for conformance, you missed the mark and you don't conform.
… if you're looking for how well you conform, then you search deeper and perform scoring
… just an idea that we could continue evolving, but it's a way to try to give a bit more color
… points could be different weights for different functional needs as well
alastairc: chair hat off, Gain hat on where we're testing things on a daily basis and still really struggle with how that kind of severity could be incorporated, even with more granular things
… could have a carousel with a number of functional images, that you could technically click through, but are more or less decorative after the first one, and could even be considered an equivalent of the description
… e.g. if you have 15 different images of the same article of clothing from slightly different angles, providing alt text is a pain
<Zakim> JJ, you wanted to reporting levels
alastairc: any time you're looking at number and severity of instances, it becomes so difficult to find something that would correlate to actual experience.
JJ: Conformance levels in WCAG 2 are simple with pass/fail, I do worry it could become far more complicated in WCAG 3.
… I wonder if there could be tooling co-developed at the same time to help support the WCAG 3 conformance model?
… e.g. contrast formulas are complicated, but there are automated tools you can use
GreggVan: There's always the risk of gaming when you deal with counts and percentages.
… when you introduce weighting, this way lies madness.
… adding different severity for different disabilities, anyone who would like to suggest that, I would recommend going through the entire set of guidelines and trying to weight them all and bring it back to the group. You will quickly find yourself in a quagmire.
… we asked everyone to take the set of current ones and go evaluate a website. Few people did it. If it's so hard to do this for one site because it's so much work, even when it's only pass/fail, I really think we need to be sure we're creating something that's really usable.
… I worry we're inventing ways to make it more and more complicated, and thus harder and harder to actually use in practice.
Rachael: I'm going to try to wrap us up to get us to the break.
… in the document, someone mentioned the Netherlands' approach to progress; Gregg has asked for a link to that, if you could add it to the document that would be fantastic.
… after break, this has come up repeatedly - let's have a severity conversation and explore it in more depth.
… complexity is really key, so when we put the first WCAG3 draft out, we did have a weighted version, and it was weighted based on the effect a requirement would have across different functional needs.
… it was also based on density.
<alastairc> Just to note we did get at least 6 people complete the requirements review (or most of it, AFAICT), and another 6-8 do partial reviews.
Rachael: what we heard back very clearly was that counting and adding complexity was a non-starter for WCAG 3. Whatever we do has to keep it simple.
… severity does add difficulty to users beyond what they're doing now.
… while we can add tools to help evaluate beyond pass/fail, if they have to evaluate those instances based on context, that's going to add complexity.
… I think it's worth one more pass after break
kenneth: Just a quick reminder, there is always that limit on what can be automated, and it is often quite low due to nuance requiring manual checking, so don't assume we can hand-wave away the majority of the complexity with tooling
Issue Severity
kevin: We keep circling back to this as a conformance or reporting approach
… ideally include clear and transparent rules around weighting
… Rachael has linked to previous conformance proposals within the document, and highlighted 5 ideas that were explored and ultimately filtered out because they were found to be lacking in various different ways.
… Goal is to introduce this topic and have a poke at it in the next half hour
… then leave the idea with people to have a think about it, and we'll leave as it is, to be taken up subsequently by AG
GreggVan: The concern I have about this is that I don't think it can work for a bunch of reasons, and we keep wanting to make it work. An incredible amount of time has been spent on it, you're right.
… we keep circling back around to it, and coming to the same conclusion that it can't work, or at least we can't find a way for it to work, and then we park it again.
… a few of the fundamentals that cause it to fail:
… first of all, to weight, you have to decide that some things for some people are more important than other things for other people.
… secondly, we're all about the tails. People with disabilities are always on the tail of usability, off on the edges.
… if we look at only the people with disabilities, where are the most mainstream disabilities? We'll give them the most weight. Then we leave the people at the edges off the table. Then we end up doing the same thing that we criticize others of doing when they overlook accessibility.
… RE categorizing by number of functional needs they affect, this can cause some to get higher points serendipitously when they just happen to touch across multiple categories.
… whereas things that only touch on one category instantly get rated lower.
… Number of errors vs. number of instances, anything that's trivial that just happens a lot is going to get a high score.
… RE adjectival scoring, I keep forgetting what that means - good/better/best?
… RE task completion, what counts as a task? If I go shopping, that involves 10 or 15 things, is that all part of one task?
… If you've got a scoring scheme, try applying it across a bunch of use cases and see how well it applies. A lot of times it sounds good in the abstract but falls apart in practice.
giacomo-petri: We need to clarify the requirement to define what is severity. I think everyone has a sort of prioritization when remedying accessibility, e.g. ranking blockers
… there are a bunch of parameters. First of all, we should define the characteristics of each requirement, then based on those, define what is severity.
… for some requirements that could be number of instances
… but we need a way to define/clarify severity
<Zakim> JJ, you wanted to levels / severity
JJ: In WCAG 2, we already had levels, which was a way of weighing them. Seems like AA is always the goal with 2. I like that in 3 you're thinking about a baseline + supplemental.
… I don't generally see people go for AAA with WCAG 2, so this seems like a nice way to encourage it.
ack
JJ: yes, this will result in some things being weighted higher in terms of score, but ultimately a judgment call is already being made when working with WCAG 2
jaunita: There could be aa missing alt attribute in images that may be informative, but might not be telling you a lot. e.g. does the presence or absence of sprinkles change that it's a cherry cupcake?
<Zakim> kevin, you wanted to comment on context
jaunita: if sign language isn't available on the page, and the language on the page isn't the user's first language?
Kevin: As soon as you start talking about severity within the context of specific pages or tasks, it limits our ability to define that in a way that's not dependent on the way you're testing
GreggVan: RE blockers, especially in the cognitive area, things that slow some people down stop others.
… we may talk about major/minor blockers, and if it's a "minor" blocker we might let it go. I worry about the edges again.
shadi: I wanted to point out that a couple of the previously-explored ideas were done using the WCAG 2 requirements, not necessarily using the newly-rewritten requirements that are more granular
… so maybe we're not quite repeating ourselves over and over, and are learning things as we're retrying.
… One of the things that I'm gaining comfort with separating, maybe we do need to separate conformance from reporting/scoring.
… e.g. yeah you missed a text alternative and do not conform, maybe we can be that harsh. But maybe we can give a secondary number to tell you how far off you are. Is it a complete failure, or is it something that is more acceptable?
… I really hope we can do something, for multiple reasons. e.g. sites that want to understand how much they're improving, and understand where to focus on
… I think we have to move away from all issues are equal. And yes, something can always be a blocker for somebody.
… In building code, no matter how flat you make the ramp, it will always be too steep for someone. There are some people who can't even push their chairs on a flat floor. But somewhere you draw the line, or have multiple levels.
… I think Lisa was suggesting an approach via email, in outlining blockers vs. really important issues for a cohort
… I think those can give good indication of how good you're doing without moving the mark
… We all do it anyway, every consultancy has a scoring mechanism, every company will have a dashboard. Can we have a more common way of doing that?
giacomo-petri: And scoring will be a number of numbers, not just one percentage, but maybe more
<Zakim> kevin, you wanted to ask if this is conformance or suggestions for ranking this
kevin: Just wondering, does this kind of point to more of a tool to support reporting mechanics rather than a model for conformance? And this is just one suggestion, it just so happens that we are suggesting it and this is how we're suggesting it?
… and if we can build and offer an EM Report Tool, but you can build anything you like
giacomo-petri: In my opinion it should be more robust, it should be able to demonstrate objectively where you are.
… provide numbers that demonstrate where you are
shadi: I think the robustness is more important than the normativeness. I think the normativeness we can resolve later if it really becomes something where it's so technically sound we can standardize it
… WCAG-EM is a good example where you don't have to have a normative standard to be widely accepted and even adopted in some cases by some regulators
… I think it could be a way, just like WCAG-EM is a way of doing website conformance testing, but not a required way to do it
… what's important is it's very closely related to how we define conformance, how we define requirements, how we define the WCAG standard itself
… so it's going to be very closely interconnected with the standard
<Zakim> JJ, you wanted to mention Common European Framework of Reference CEFR
shadi: so that might make it unique at the end, but I don't see a reason to say from the start that this will be the only way of scoring a website, it can be just _a_ way, but we need to think about it while developing the standard itself
JJ: I saw some similarities with the common European framework, with Levels A, B, C, then A1, A2, B1, B2, ...
… then within each of those levels you have e.g. reading, writing, speaking
… and when you take the exam you get a score on each of those skills, where 60% is a pass and then 70%, 80% are each higher benchmarks
<Zakim> kevin, you wanted to ask would this becomes a de facto Level A, AA, AAA?
JJ: could have some similarities, it has been proven to work with languages
kevin: If we talk about the severity for each requirement, does that effectively become Level A, AA, AAA, like the conformance model, and does that become a problem?
<Zakim> hdv, you wanted to respond to Kevin
hdv: I think we want to try and avoid that we are using it for the same thing. Severity is probably very close to how we do levels, because it makes sense to prioritize things that have more severity, but I don't think they should be the same classification.
Kevin: I'm cognizant this was a short discussion, and we're about at time. We will come back to this.
<JJ> https://
Kevin: if people have proposals or resources, e.g. I'm interested in looking at the one JJ shared
shadi: I do think there is an angle, I keep thinking about Page Titled requirement that has the intent or purpose of a page. Maybe there is a way to say in purpose, out of purpose, etc.
… looking at Alastair's example with the product website, I think we can agree it isn't getting in the way, it shouldn't fail the site
… but if there were a problem with e.g. the footer, doesn't have the same priority (avoiding using the word severity)
kevin: Thinking about the purpose of the page or the view, it doesn't have to be as rigorous
<mgifford2> JJ that's a reference that makes sense in Europe (and with language learning in some other places) but I do have to say it is backwards in North America. Very few folks in North America will be excited about getting a C. Getting an A is (almost) always the best.
Ben_Tillyer: You might assume what the purpose is of the page, or you might determine why you built the page, but later down the line you could have a researcher who's really interested in the color of corporate logos in footers, and then suddenly that logo in the footer becomes very important to that person
… and then if it's been deprioritized here, it'd be getting in the way of that use case
shadi: And you're not saying it's a pass and the page is accessible, you're saying this is a higher priority, or website A is in a worse state than website B
giacomo-petri: Your intent is not necessarily the intent of the page
kevin: Thanks for the quick-fire discussion. We will be coming back to this.
… to wrap up today, we've kind of covered a lot. We'll be going through this as chairs, we'll bring it back to the group
… tomorrow is breakouts; there are a number of accessibility breakouts which I'd encourage people to check out
… Thursday and Friday we have a number of joint meetings set up in the calendar with other working groups
… with that, we'll close off for today. We get a whole hour back. Go fall asleep.