Meeting minutes
Adam: Anyone new to the group or change of affiliation?
mattking: Joined back.
WCAG 2 updates — https://lists.w3.org/Archives/Public/w3c-wai-gl/2026AprJun/0044.html
Adam: Talk through the most recent proposed updates to WCAG2
<Zakim> alastairc, you wanted to comment on WCAG 2 normative updates process
Patrick_H_Lauke: Usual announcements: bi-weekly one that the group has been sent an email last week with the list of proposed changes. Deadline is next week, please take a look. Pull requests, comment, like, subscribe. A side note: We're currently working on gettinghte errata things ready as well.
<Zakim> AWK, you wanted to discuss process for normative changes
alastairc: Anticipating Andrew's question. The process on normative updates is roughly as follows: We sent around pre-CFC which included two/three categories. Things we think could be errata should be evaluated on that basis, and some things whicch are proposed updates. We CFC things if they get agreement.
<jtoles> preseent+
<Patrick_H_Lauke> see the "Errata for refresh" and "Future version updates" columns on https://
AWK: I've grown concerned about the regularity of normative changes that are being proposed and I want to make sure that the working group has an opportunity to think about what the actual cost is. So far, we've got changes, and I don't know... this is part of my process question. We've got changes proposed now to consistent help to change a work
… serialized to linearized, we have changes to notes within 2.2, which is a note, so it's not normative, but this is a normative document. There are a bunch of things. What happens when we do that is that there are costs to training, documentation, translation, audits, and with the EN who is referencing WCAG - there's a large cascade there. I'm
… concerned that for some of these things the working group discussed the language went through public review. People know I'm going to advocate for the spec to be stable because of these types of things. The changes are starting to stack up. and the work takes away from progress of WCAG3.
<kirkwood> +1 to Andrew
<Stephanie> +1 andrew
<Patrick_H_Lauke> to the point of backwards compatible: i do not believe the "errata for refresh" items at this point don't change any interpretation that would break backwards compatibility
<shadi> +1 to AWK and GreggVan
GreggVan: Similar vein. First, we want things to be backward compatible, but if we keep changing things, then everybody who passed yesterday won't pass today. People are still working toward compliance to WCAG 2.2. Two: EN is frozen. Are the changes proposed significant? Unless it's just a complete faux pas, if people are confused in the
… understanding, and it could be better if it was stated a different way. I just really think coming out with a 2.3 is what you'd have to do, is the wrong thing for us to do unless there's something catastrophic or something just hugely benefit really something that needs to happen because it's going to be very disruptive things.
<bbailey> Alastair 9 June Errata and updates for WCAG https://
<Zakim> hdv, you wanted to agree changes could mean a lot of work downstream, but given the nature of the changes that's not the case now
<Patrick_H_Lauke> there's only so much handwaving you can do in understanding, as alastair said...
alastairc: No one responded to the email, which I sent out entirely to elicit this kind of feedback and to try to work out where the groups stood. It would be really helpful if people could reply to that with their feedback. Greg, I would say a lot of these minor editorial updates because things don't quite make sense, but they're not trying to
… change any interpretations; things like don't refer to success criteria by their number alone, fixing grammar. I don't want to use all our time today on this aspect, but if we could respond, we can set it up for discussion in a week or two. I think it would be helpful.
<alastairc> Also, there is a cost to not changing, every misunderstanding is a like a little paper cut to it's use.
<HaTheo> +1 with Hidde, I think there is real benefit to changing the wording and improving the wording even to older guidelines, as its used and is helpful for people running accessibility programs. I also don't think they cause meaningful or dramatic changes to the way they would be interpreted.
hdv: I kind of agree. I agree that it would be problematic to make big changes like Andrew said. I don't think we have changes of that nature in this set of changes. I feel like what is being proposed there is helping to clarify stuff. It's helpful to make it more clear. I think it's helpful to get those misunderstandings out of the way, I don't
… think the changes are so big it would cause actual problems in the real world. I think it's a great idea to make these changes even if it costs some people some work, I think it's not that big of a change that we're being shown right now.
<AWK> From Alastair's email: "If you have reservations about the errata or changes above, please reply to this email and/or comment in the appropriate GitHub thread"
<bbailey> +1 to hdv
<nattarnoff> A significant complaint is that accessibility is an always moving target. Continuing to make changes to 2.2 reinforces this complaint.
<Stephanie> +1 nattarnoff
<Patrick_H_Lauke> right here, right now, WCAG 2.x is what people use, and need to use for the foreseeable future. just saying "we'll fix it in WCAG 3" won't solve people's concerns/questions/misunderstandings/lack of clarity in the trenches...
<alastairc> https://
AWK: I wanted to comment back to Alastair - you suggested that no one has responded about this and that maybe no one cares about this. In your email you said if you have reservations, please reply to this email, and maybe no one did and or comment in the GitHub thread. It is not clear for people where they're supposed to respond, or what the
… process is. I would be interested in there being a survey, so that responses are captured in that point in time. Meaning, this is ready, now we're going to discuss it, as opposed to trying to disambiguate what was a comment from before, and what is a comment now.
<Charles> +1 to the concern of external cost on the public staying in sync
<Charles> -1 to the concern of the cost on the working group attention
<Ben_Tillyer> +1 to LoriO, very important
<kevin> +1 to Lori's comment on these are issues that are often raised from community members
<hdv> +1, it's very important we listen to real world feedback
<AWK> The two items that change in the normative document today seem to have been raised by TF members.
<Patrick_H_Lauke> +1 to Lori
LoriO: I'm not for or against having WCAG2.3. One thing to remember is that the issues that the task force looks at or considered or debates are comments from the field to the task force. The suggestions and input are from the users of WCAG, and if they feel strongly enough to put in an issue, I think that we need to consider it if it's valid and a
… big enough issue. It's not the task force that's suggesting or pointing out these changes.
<erinevans> +1 to Lori
<Charles> +1 to LoriO on importance of public issue if the issue can be resolved without normative changes
<Patrick_H_Lauke> so ... no errata, basically
<kirkwood> could there be legal issues as well?
shadi: I agree that the callouts are from people are trying to use the standard and finding specific issues. I'm hearing two different things: on one side, it's very small, minor clarifications that doesn't really change anything. On the other hand, they are normative changes, which does have an impact on Internal tools on standards that are build
… on the standards. For example, EN 301 549 which uses the text in different sections for software or documents. So suddenly people have different versions, even if it's just minor word changes. So if they are so minor, these changes and maybe the cost of the changes is not sufficient and its enough to put them in the understanding to clarify, if
… they do need to be changed in the normative then we should think about WCAG 2.3 to make that clear, so that we're not changing a version that people are already using. So I'm going back to the point about the impact of even minor changes that they do have, and the cascade of things. If the most transparent thing would be to do a 2.3 but we have to
… think about the cost of effort of that as well, and how that would delay WCAG 3.0
<Ben_Tillyer> Assuming people tend to link to specific versions e.g. https://
<alastairc> The title 2 referenced the informative docs as well.
Wilco: I agree with Shadi on this. I want to stress that point. I think particularly in EN 301 439. The changes directly impact the European Accessibility Act. Even if we don't think it changes anything we're not the ones who are going to need to decide whether anything has actually changed. We are not the ones legislating this. When we make
… changes, it's up to whether the legislators think the changes make a difference. I think that's kind of harmful and I think that's taking a risk that we shouldn't be taking in the US also. Changes to WCAG were cited as one of the reasons for delaying Title II. It worries me.
<alastairc> These are the normative changes referenced: https://
GreggVan: I agree with Wilco, we are in a fragile situation, where it's being adopted and taken seriously, and we all need to do is add more evidence. It keeps changing. Alastair, you said in your email to reply or put comments in GitHub. Some of us have email overload. I get more than 50 emails from WCAG a day from all the GitHub activity. I wish
… there were filters that says what was closed. We agree that if there's edits to clear up what we meant, where could that go? In the understanding document. It's the normative changes that we worry about, and I presume your question that you're asking about was not about the changes we're looking at today, which are the clear ones. Patrick, if you
… get toward the end of the deadline, it could be helpful to send out a reminder.
<Patrick_H_Lauke> detlev, and those items are still being discussed, and we are trying to address this in understanding
<Patrick_H_Lauke> those are not changes to the normative document
Detlev: To relate to what Andrew said at the beginning, I think there are a few changes which I don't really see the need of. For example, why change serialize to linearized or the other way around? It doesn't seem to have any significant impact. I do think it's important that there are some things, and I slightly disagree with Hidde , There are
… some things which do have a significant impact on assessment or conformance assessment. for example, these 2 cases which have been discussed at length on GitHub, which is one of them is the logo question. I agree there are different ways interpreting normative text, and I think we have seen that within the working group, there's some way to say no,
… that was never meant to be interpreted this way. Ask for more than the least impactful change, because everything else would need explanation and would be easily contested.
<Zakim> alastairc, you wanted to comment on survey vs github usage and to comment on 2.3 as future place
Jon_Avila: I think it's helpful to have the issues broken out as folks on the team does with the editorial and minor, etc. I think that's helpful and I'm glad we're tackling some of these questions and I think it's useful. I't s a bit tricky navigating through all the GitHub discussions and things to figure out exactly what the current state of
… things are, and the other challenge is understanding the actual impact. It may be a lack of discussion within the group to understand these important issues, and then we take away the time from WCAG 3, so I don't have the perfect answer.
<Ben_Tillyer> +1 to alastairc on understanding vs normative differences not sitting well
<Zakim> bbailey, you wanted to mention that wcag2ict is one of the group giving scrutiny
alastairc: To Jon's point, I think some of them may have been initially opposed as errata, but because they did make some interpretation impact, we categorized those in the email as changes for a potential 2.3. I got on queue to discuss surveys versus GitHub usage. I think it doesn't seem like an approporiate thing to do to pull out decisions
… around doing an errata, then that might be suitable for a survey. We'll have a look through the GitHub issue comments and see if we can draw that out.
<Patrick_H_Lauke> when WCAG actually hits the real world in wide adoption, things start to bubble up that were never even conceived in public review
<bbailey> https://
<Patrick_H_Lauke> +1 bbailey
bbailey: We've had all this public review, it must be really close to perfect, and that's just not true. People don't read our material closely. For the example of linearize, we stopped our phone call for at least half an hour. It's confusing not to use the correct word. It's confusing for people. What does it mean for a group that discovers errata
… and refuses to publish it? Personally, I find it embarrassing. Posting a link into the classes of changes, and it's hard to come up with a situation of a site of any content that would fail based on this correction.
Adam: This topic is taking a bit longer than anticipated, and we have other topics to discuss this week.
<Zakim> AWK, you wanted to point out the difference between editorial errata and non-editorial
stevef: General comment. We always seem to be talking about the process issues about whiter we could 2.3 or whether we should not, can't we just have a vote on it so we can make a decision instead of spending hours going around in circles?
<Jon_Avila> 4.1.1 was an errata right?
<kevin> Jon, no 4.1.1 involved republishing WCAG 2
AWK: Adding a clarification: Alaistair said we have done errata in the past, and we have, we've done editorial errata. It's just our process for doing and approving editorial errata.
<bbailey> We deprecated 4.1.1 for WCAG 2.1 -- nothing since has been that great of a change
<Zakim> kevin, you wanted to mention Process perspective on errata
GreggVan: As Andrew said, we're a standards body, so when you were going to make normative errata changes, it has to go through the same review as the normative change does. You don't do the errata, the editorial errata process is totally different than the normative errata process. the normative errata has to out to public reviews tc. As soon as
… you put something up for a vote, people get to discuss before the vote.
<Wilco> stevef the next charter that's being voted on in AC says there won't be normative changes to WCAG 2.x https://
<kevin> http://
<Jon_Avila> I think this page lists 4.1.1 as an errata https://
<Zakim> hdv, you wanted to invite folks to check if any of change suggestions mean we require different things
<kirkwood> have same recollection 2.3 v 3
Kevin: The process recognize that error can be made in specifications when they're written and how they are then subsequently interpreted and implemented. There's a specific provision within the process that working groups must maintain in errata to address these issues. How we do that is up to the working group, but there is a requirement for us
… to do it. I think it recognizes that this is input from the broader community. Second, my recollection is we have had a discussion on whether to publish WCAG 2.3 or get on with 3, and that discussion resulted on the decision to get on with WCAG 3. Will double check.
hdv: I think we need to look at what the actual change suggestions are, and we're all agreeing we don't want to just change a thing, and then there are points at a completely different thing. I think everyone will have a change to actually look at the changes and see what's in there before we have a long discussion about the process of things we
… can or cannot do.
Conformance features review
Adam: Going to move forward in the next topic.
alastairc: Will share screen to the presentation, link is also above.
Slideset: https://
alastairc: Have had a few topics on conformance, so we wanted to take a step back to see where's we've got to, what we have previously considered, and what we're looking at now, to make sure people are on the same page. This is a structured topic on conformance and the features that we either have considered or are considering at the moment.
alastairc: [reviewing slide content]
alastairc: WCAG 3, has Intro, provisions, conformance, and reporting. Related to conformance, we are planning policy guidance and an evaluation methodology, equivalent to in parallel with WCAG 3, those weren't things that were planned with WCAG 3. This is to say that if something doesn't fit in conformance but sits in other informative documents,
… there are places to put that that we didn't have before. There are things like how-tos, a WCAG2 to 3 mapping. Theres a potential for a process standard, so Design for All the the example that we looked at a few weeks ago.
<Zakim> Charles, you wanted to discuss reminder how to get involved in path / flow definitions
Charles: Can you remind me how to get involved in the path flow definitions group?
alastairc: We have already started, but please drop the chairs an email and we'll discuss that separately.
alastairc: Would like a discussion with the group to call out the pros and cons for adding this as a feature to conformance. [reads pros and cons from slide]
<Zakim> Rachael, you wanted to ask clarifying question
Rachael: Are we talking pros and cons about levels within conformance or levels within reporting outside of conformance? I find them differently.
alastairc: For purposes of today, this is things we're considering putting into conformance, but I could see a legitimate comment. We're thinking about conformance, but if there's comments around that might shift it from conformance.
GreggVan: complements to Heather on her scribing!
<Heather> All the scribes do a great job :) My technique is to have captions displayed, and then I type like hell.
<Heather> :D
GreggVan: if we have, say, 3 levels below AA, I worry people will stop at those levels
<Jon_Avila> I agree that comparison may not be that helpful with levels because you can miss 1 thing at one level but hit all the ones in the upper levels.
<Zakim> Rachael, you wanted to say cons risk to harmonization and risk of regulators picking a lower level than AA as conforming
<Stephanie> +1 Rachael
Rachael: chair hat off… I see two risks with these levels: one is a risk to harmonisations as different countries may pick different levels; another is a risk that regulators pick a lower level than Level AA is currently, which effectively lowers the bar. If we keep it out of conformance, that would prevent it, and that would be a requirement for me to support more levels
AshleeF: currently, AAA doesn't get done very often
AshleeF: so I feel levels shouldn't apply to one set of provisions, which would make them be compared to one another, and open it up to basically discrimination between groups… so if we can break hem up into sets that are related to each other, it would be better
<Jon_Avila> It will be really hard to agree on what go in which levels things go in- I also agree with Alastair's point that context may be more important.
AshleeF: if authors want to choose not to do, say, sign language, they would end up not conforming to the set of provisions related to sign language; it would be clear to procurers
Wilco: product manager hat on… what problems are we trying to solve?
Wilco: it seems we want to better reflect real accessibility
Wilco: but if the levels don't reflect impact, like these don't, it defeats the purpose
Wilco: I think this doesn't address the issues we're trying to tackle
<Zakim> AWK, you wanted to cite the risk that no one meets the level we desire.
AWK: people don't currently meet WCAG AA on their websites, making it harder will not improve that
<Jon_Avila> +1 to Wilco
AWK: we need to recognise this reality
AWK: that a very small number of websites currently meet WCAG 2.x at AA
AWK: to me that suggests have a way to help them measure progress and be able to conform at a lower level and higher level is good
<Charles> Leaning on Note 2 of of 5.2.1 has always bothered me. It simply says not recommended for policy requirement of entire site based on some content. That is an opportunity to not have that content. Not a discouragement of AAA conformance in general.
<Jon_Avila> I agree with Andrew - maybe a way to show progress and things you have done well rather than just what you have not done.
<Zakim> hdv, you wanted to say what I think we're trying to solve
hdv: I wanted to agree with Rachael that we don’t want to lower the bar through levels
… many of us want to prevent that
… keeping this out of conformance will help that
… the problem we’re trying to solve is to allow for more differentiation between products
… in the Netherlands, we have thousands of products
<julierawe> +1 to Rachael and hdv about concerns that we don't want to lower the bar through levels
hdv: and need to be able to express the difference between them
<Wilco> @hvd, do you think more levels solve that problem though?
hdv: that distinction would be helpful to make
… to AWK’s point, we do see a good number of websites that meet WCAG 2 AA, but I recognize it is a small percentage
<AWK> Would love to see one of those, @hdv!
<Zakim> alastairc, you wanted to comment on severity / levels and to also say partial conformance needs to be better dealt with
<hdv> Wilco, yes I think so… but probably not conformance-level levels
alastairc: re Wilco's point… there seems to be more variability based on context than is possible for us to encode in levels
alastairc: I do agree with Andrew that most sites don't meet AA, it's only a small percentage
alastairc: I think we need a distinguishing thing, but don't think levels is it, not in conformance (chair hat off btw)
shadi: re regulators choosing lower levels… countries could already do that now, they could pick Level A. We havent' seen countries do this now. We've seen the opposite, we've seen countries add requirements
shadi: we've seen steps as being regarded as too big; in WAD, certain requirements were removed/overridden
<Jon_Avila> AODA has removed live captions and audio descriptions
shadi: I worry that if we have a level that is too high, we'll start to see fragmentation
shadi: in that case we might think we're helping, but we should avoid playing regulator in this group
Wilco: similar point… organisations today don't do level A first and then AA . In practice organisations never have flawless WCAG performacne across the board, they build into organisational practices that try to improve over time
Wilco: it doesn't happen group by group in practice, I don't see this solving that
<hdv> +1 Wilco
GreggVan: if you have many levels people will stop at some point
<alastairc> Gregg - I think Wilco's point was that, in practice, people don't start with A then do AA, they break it down in different ways.
GreggVan: we're talking about setting a line for the absolute minimum as being our baseline… to have levels below, we'd basically say 'you can conform at lower levels' is not great
hdv: what I’m hearing is there is an appetite for levels, but outside of conformance
Matt_King: I'd like to learn a bit more about the multiple documents approach
Matt_King: it could be relevant to this discussion
<HaTheo> +1 to Matt. I think ways to chunk WCAG are helpful, but I am not sure about finding/releasing an opinion on "levels" will be possible(there are so many opinions). I would love to investigate tags or something else that lets people more consistently explain where they are in and out of conformance.
Matt_King: I'm averse having levels because discrimination would be inherent if we're breaking requirements based on different groups of people with disabilities
<Wilco> +1 Matt
alastairc: thanks all… we've collected some more pros and cons now
alastairc: continuing the presentation… we also looked at scoring
alastairc: this is imagined as an informative extra
alastairc: preliminary conclusions… severity is an important factor
alastairc: as a mechanism for comparing accessibility and progress towards conformance score align with the experience people have of that website
<AshleeF> +1 to wendyreid (I think some concerns mentioned may be out of our scope, I think further discussion would be helpful)
alastairc: proportionality would give us a score that aligns with experience
alastairc: in the real world… scoring under 60% is quite hard because you would need to have a lot of different types of inaccessible content
alastairc: progress to conformance score removes the need for levels and helps with procurement…
<Zakim> GreggVan, you wanted to suggest
alastairc: we also talked about cons… one is that it isn't part of conformance and therefore could be ignored, the other is complexity
GreggVan: I would like to suggest an Adjusted/Normalised Progress Towards Conformance Score
GreggVan: so if we take the minimum score you could possibly get and call that 0, and the maximum 100, then that's the score we should be using… that's something people are using
<Zakim> GreggVan, you wanted to suggest "Adjusted Progress towaard conformance Score"
<Zakim> Rachael, you wanted to say con that scoring is difficult to create without internal gaming
Rachael: it's very difficult to create an objective score that doesn't have some gaming aspect to it… it's very tough
alastairc: we were weighting between core and supplemental, not user group, if that helps
Matt_King: I think this has the same problem as levels… how it is currently designed, we're still weighting provisions, fundamentally
Matt_King: you're measuring the number of provisions you're meeting, in some form or another
<julierawe> +1 to Rachael about conerns there will be some gaming aspects to this scoring system
Matt_King: not sure if that aligns to real world user experience
Matt_King: not sure if that direction benefits users
<HaTheo> +1 to Rachael. I worry that this would cause people to game the score and fix the easiest issues, which I am not sure actually explains the work/benefit.
Wilco: I think there's a real risk regulators will just use this and say '70% is good enough for us'
Wilco: I do feel better about this idea than multiple levels. There is potential here
Wilco: but a lot to be figured out
<Zakim> alastairc, you wanted to comment on scoring aligning with experience, lack of severity, but shows improvement without setting gates.
bbailey: re the complexity of counting, eg alt text and assessing quality is tricky
alastairc: chair hat off… would agree with Matt that scoring does not necessarily align with experience, mostly related to not being able to measure impact
alastairc: without some mechanism for incorporating severity, which would be time consuming in terms of scoring, there is no way around that
alastairc: what's available for you to increase your score depends on the content you've got … eg iff you don't have specific types of content, you could automatically meet it
alastairc: didn't feel that was a big con
<Zakim> wendyreid, you wanted to say progress scoring only further reinforces the "all or nothing" paradigm
wendyreid: these conversations are all tied together… the discussion re PTC score, it's reinforcing the 'all of nothing paradigm'
wendyreid: a lot of our focus and a lot of the cons we've identified, are us trying to create ways to prevent behavour. But we have no control over what other people do. We're trying to write requirements to try and force behaviour. I think that's the wrong angle.
wendyreid: no major company with regulatory exposure is going to reveal this, it's opening yourself up for problems
<kevin> +1 to Wendy's points
<Stephanie> +1 wendy
wendyreid: could be helpful to procurement… but only tangientally… see VPATs
<CClaire> +1 Wendy's points
wendyreid: feels like we're still just reinforcing that old paradigm. We need a different angle and stop focusing on bad behaviour, start thinking about supporting positive behaviour. Leave the boundaries to the regulators… we can recommend things but have no control over that
<hdv> +10000 Wendy
<Zakim> hdv, you wanted to talk scoring reality and user experience reality
hdv: many great points
… I agree with wendyreid
… there are 2 realities here
… 1 is “yes, we score things mathematically” and the other is actual user experience
… that can seem at odds
… but in reality they can reinforce one another
<bbailey> +1 for focus on reinforcing good behavior (versus concerns for gaming)
hdv: like when we monitor government websites, when they are away from a score, they will try to reach it
… but they may hire someone to tell them where the barriers are and then remove them
… the relationship is not direct, but it’s definitely there
… in the end, it is about user experience, and the kind of things you need to do to get points is remove barriers
… totally agree with wendyreid that we need to stimulate good behavior and not focus on bad behavior, which will happen no matter what
… regulators have ways of managing that
Wilco: these kinds of determinations have an inherent problem in them… large scale accessibility improvements are an organisational problems. A process type standard like Design for All seem like a better way to go about this
GreggVan: re all or nothing… WCAG is not 'all'. That's way more than WCAG, which is the minimum
GreggVan: if that minimum is too high we need to take things out
<Charles> in essence, a guideline is about what to do, and not what not to do.
GreggVan: we need to be clear can't stop until you're at the minimum. Are we serious about 'less than 2.2'?
GreggVan: we've looked at 2.2 and at what to add on top. All is not WCAG, and we have to do everything that matters in the minimum.
<Zakim> alastairc, you wanted to comment on conformance all/nothing is from being an output standard and to comment on who creates the scoring, as many companies / regulators do this already
alastairc: re all or nothing… and I take wendyreid's point that 2.2 is 'all or nothing'… that is one of the characteristics of being an output standards. Process standards also exist, as Wilco said, and are a different thing
alastairc: lots of companies create scoring based on WCAG 2… I don't thinlk that would stop if WCAG 3 had some kind of progress to conformance score. Chair hat off; my idea would be as simple as possible and allow orgs to build on top of that, and then normalise partial conformance
alastairc: regulators, VPATs, may do their own thing … but it would just be a mechanism that allows for some differentiation
<AshleeF> From my POV, I think what many people may mean by "make WCAG 3 easier" isn't about making it easy from a time or effort perspective, but making it less intimidating/complex to approach and progress through, like regarding information architecture for one example.
Matt_King: this discussion is awesome; wendyreid's call to reframe the discussion is great
Matt_King: if the minimum is too hard, we need to change the minimum
Matt_King: there do exist output standards that aren't all or nothing when it comes to provisions
Matt_King: what if… the worst site in the world and the best site in the world could claim 100% conformance with WCAG, within the output standard? That output standard would force companies to share the information that they weren't previously sharing
<alastairc> AshleeF - The basic requirements for people with disabilities don't really change, so I'm not sure that it's possible to make it easier overall. Easier to understand, yes, but not less effort overall.
Matt_King: if there's a measurement system that is forced on everybody, but allows policy makers to say this is our bar… then everybody is incentivised to do something that is good
<AshleeF> alastairc I think that's what many people ask for in my experience--making WCAG easier to understand.
wendyreid: +1000 to what Matt just said… the challenge with 'all or nothing' … there's a good reason people don't do A first and then AA, is that they aren't iterative in relation to one another, it's just not how the requirements are structured in WCAG 2.x.
<AWK> +1 to Wendy
wendyreid: because we know the current model isn't working because it isn't iterative, is why I'm pushing for a new model where we can help people build towards an accessible website.
<alastairc> Wendy - one part of the "compliance" puzzle.
wendyreid: re output standard: we should actually start thinking about ourselves as making an output standard, we know that accessibility is much bigger than the standard. We should probably think of ourselves as one part of the conformance puzzle…
wendyreid: in conjunction with other things, such as standards like Design for All
<giacomo-petri> big +1 to wendyreid point
wendyreid: a lot of our struggle comes from trying to force it all into WCAG
Jon_Avila: things like a VPAT could be useful in market comparison, but they don't demonstrate what's been done, at least such a demonstration isn't required within VPAT
Jon_Avila: so the challenge is how do you know if you're accessible… how do you know when you've done enough? Many people think their website is accessible
Jon_Avila: we need some way to measure… have you done these things…
<Charles> the informative intro (formerly 0.2) has always suggested the use of all the layers of guidance and going beyond it. that is the nature of a guideline. do everything. then conformance ignores that suggestion and says do only this. so rethinking the problem includes the problem we created.
Jon_Avila: highlighting what's been done well can help people make a decision
Jon_Avila: and indicate what else needs to be done
<Zakim> alastairc, you wanted to move onto the next items
GreggVan: wendyreid said something really important… we / WCAG are not the sole determinant of what's accessible, many things are critical but can't go in. When I talked about all or nothing and us continuing to shoot for that… that's just one side of the scale, and the other side of the scale is to think about if WCAG 2 is too much
<Zakim> Rachael, you wanted to answer gregg
<Zakim> alastairc, you wanted to comment on next items
Rachael: consensus what I've heard over many years isn't all or nothing… the group seems to have strong consensus that the right amount of requirements is WCAG 2.2 AA… what we're talking about is communicating better about the road towards that level.
alastairc: [continuing the presentation] we've talked previously about severity levels, in 2023 at TPAC we made progress
alastairc: this is an open call to see if folks have thoughts on how to progress with severity
<Zakim> Rachael, you wanted to comment on a thought
shadi: my recollection of the discussion is that it was examined using WCAG, so each requirement was deemed important to someone -- would this be different using WCAG 3?
Rachael: for context, I've gone through all the conformance models in the past
Rachael: this one, to me, has the most promise, as it has the least ambiguity… it assigns severity based on the thing that's being evaluated
Rachael: a simple way of looking at it…
[types it in for the scribe]
<Rachael> Interaction as part of process- Severe; Interaction outside of process - Moderate; Legal, financial or medical information - Severe; All other information - Moderate; Decorative content - Minor
alastairc: so paths have been included at each stage, and we'll come back to the authoring tool one when the core model is more settled
alastairc: this could also intersect with other features like functional needs and weighting scoring levels
alastairc: and we are at time!
Adam: thanks all for your time and thoughts!
Adam: see you again next week!