Meeting minutes
Slideset: https://
kevin: Presenting some slides, this is an update on WCAG3
… we'll use the queue in IRC
… if anyone has questions, we'll pick them up as we go
… we are going to cover today, first an intro on WCAG3 itself
… recap on the new approach, what we are hoping to achieve
… current status, topics to go in depth, what's next
… WCAG3, developed by AGWG
… a major development from WCAG2, it does not deprecate, you could almost have regulations that cover both
… we won't go into the regulatory bits
… goal is to cover more disability needs than WCAG2
… general goals is a new structure, there are a lot of challenges in WCAG2 to add new success criteria
<shawn> starting point for official WCAG 3 info : WCAG 3 Introduction https://
kevin: baked into the structure, WCAG3 will use a new structure to address this
… lean more into user needs, connecting requirements with user needs
… help users of the standard to understand why this requirement matters, front load with why
… we know from anecdotal evidence, when developers understand why, they are more likely to do it
… we are looking to expand coverage of disabilities
… within the work, we've been slowly developing things
… most recently, working on content maturity, five maturity levels: placeholder, exploratory, developing, refining, and mature
… increasingly mature content runs through these levels, within each level, we're looking to ensure we tick certain boxes
… they also tell a story in terms of what we need from wider review
… if content is exploratory, much of the content is, the details are unclear, but the direction is, we are looking for more specific feedback and input
… the general structure of WCAG3 deviates a bit from WCAG2, for each area, we have guidelines
… guidelines are plain language outcome statements, within each are foundational and supplemental requirements
… the goal with these, foundational are part of the base set of conformance, there are a lot of concepts here we are still working on
… foundational are base set
… within each, we have how-tos, how to achieve the requirements
… similar to the WCAG2 explainer documents
… within each are methods and tests
… methods are technology dependent, how would you achieve that requirement
… for example, a method could state that the user agent could meet the requirement, meaning that the author does nothing
… we'll talk about the accessible support set
… if there is a test, we can make it a requirement, but if there is no test, it's hard to require
… tests can vary depending on platforms
… that leads us to assertions, one challenge we have is the requirements are difficult to test in a consistent and repeatable manner
… this comes out of work like COGA, when you start trying to unpack it is hard to create consistent tests
… the model we've adopted is assertions, meaning that an org has asserted they have done certain things, like testing with people with disabilities
… it's good, but we can't test the success or impact of that
… you can assert that, and we can include it in evaluations, no quality assessment, but proof of the work
… this will allow us to hopefully integrate some harder requirements
… that's the overall structure
… within a requirement, the structure is more fine-grained
… within WCAG2, many success criteria are very meaty, with lots of requirements
… for anyone who knows WCAG2, sometihng like 1.3.1 info and relationships becomes overloaded
… we want to get as detailed as possible
… here is a requirement about text resizing, this is to show structure
… core requirement is that text can be resized to at least 200% of the platform default
… you can limit or declare when it applies, and has exceptions, the requirement applies except in specific circumstances
… it allows us to provide clarity
… one challenge as we've done the editorial process, when there are multiple exceptions
… start to question whether it is an appropriate requirement
… having the structure helps with the editorial and review process, to determine whether a requirement needs to be something else, like an assertion
… some thorny questions, not all but some, what we get, what we reflect on
… how can we make WCAG more user friendly?
… standards language is difficult, how do we make it more approachable, plain language
… when expanding the coverage, we want more coverage for cognitive and low vision
… how can we make the standard more future ready?
… when we published WCAG2.2, we deprecated 4.1.1, the parsing requirement, it was tricky to take out
… could we write requirements so we don't need to remove any, but maybe it no longer needs to be met
… last on is about the conformance model, how do we avoid a pass/fail conformance model
… it's not just about the conformance model, it's about how regulators adopt the model
… how people use it
… user friendly standards, the Silver Group, who did a lot of the research on the usage and usability of WCAG
… tons of work, they were looking at simplifying the language, easier points of access
… how do we know when something passes, fails
… we see this in the WCAG 2 backlog, lots of ways to interpret
… easier points of access, people coming in new to standards
… more plain language throughout the standard, looking to unpack criteria, adopting a style guide to create more consistent language and material
… work looking at supplementary materials
… WCAG2 has developed an ecosystem of supporting materials, WCAG3 is going to need the same, what does it look like
… thinking about the cognitive needs coverage expansion, it's difficult to create requirements, many opportunities for improvements
… how do we make sure we put something in that improves things
… this is how we got to assertion
… example for clear language, the assertion is that they conduct a plain language review, check verb tense, length of paragraphs, purpose of content
… you could look and think these could be requirements
… but when trying to do this, it's hard to make this actually testable
… as an assertion it is fine, as a content provider you've provided evidence you've done this
… it does two things, it provides a way to make sure these things are presented and covered, and pointing out to people things they could potentially do, like plain language review or usability testing
… it will fit into the conformance model
… ready for the future, technology changes and will continue to do so
… looking at browsers and webpages, but that's not the only way to access content
… mobile challenges, we have voice, AI, etc.
… one area to address this is to stop referring to webpages, and to focus instead on a page or a view
… the idea behind this is to allow for interfaces that don't fit into the previous "webpage" model
… talking about conformance, it's a very active topic at the moment
… this is the current thinking
… conformance based on a combination of foundational requirements and then a set of supplemental and assertions
… you could have options for selecting a subset, you could focus on specific domains like education or healthcare
… one idea is having a points based system, another is percentage based
… we have a diagram here, the block of foundational requirements with the supplemental block on top, within that is bronze, silver, gold levels of conformance
… we're actively working on that
… accessibility supported, going to be vague, this is a difficult area to define, the concept is similar to WCAG2
… how does a content author know a technique will work in practice
… the accessibility supported set will identify the tools, browsers, AT, software, that fits within the set
… if you work within the set, and it allows groups to define sets of their own
… the goal and aim in WCAG3, there will be an informative set, this is our support set, this is what it means
… that goal is about providing a set of foundational requirements to rely on
… you can rely on these things to ensure conformance, like the relationship of labels and elements
… there might be higher conformance levels, regional sets or contextual sets
… next steps, we have updated the draft with another coming soon
… we have a draft schedule, we're rechartering so thinking about that now
… upcoming draft due in December 2025, or early January
… close to complete list of guidelines, requirements, and assertions, big editorial work on this
… lots of work to define this, now subgroups are reviewing the work
… we'll update the draft
… within there, we are going to include goals for the conformance model
… we're still kind of hoping someone invents one that solves all our problems
… also include proposed options
… we're looking for public comment on any guidelines or assertions missing
… and more info on the conformance model
… broader discussion on the conformance model, trying to loop in regulators, we want to make sure they are in the conversation to know what they want
… we want to provide information to policymakers when using our specs in regulation
… draft publication schedule for the next 4 years. Hard numbers in there, some flex
… hoping to solicit feedback on 2025/2026 draft, 6 months of 2026.
… Goal of the next charter release is develop the candidate recommendation
… get to CR by late 2027
… 2029 latest to publish REC, with time for review in between, after 2029, working on the informative documentation
… it's already begun, it will be interwoven as we work on things now
… we'll have more information once we release the charter
… finally, we really encourage feedback, it only benefits more from people who want to use it
… we use discussions in github, we encourage people to participate freely, some are long, chairs help summarize
… you can always send an email to the AG comments, one per issue please
<Zakim> Jem, you wanted to ask about resolving potential discrepancy in two different domains - 1. conformance in "supplemental requirement" and 2. coordination among subgroups such as COGA, Low vision, Mobile and Policy, usability testing and assertions, WCAG 2 ICT, ACT and so on.
Jem: I have two questions, I am happy that the Silver TF items have survived, first is when we worked on Silver TF, we had a lot of discussions about conformance, supplemental criteria
… different domains requirements, how will you measure by domain?
… second question is about the current effort, one of the agenda items this week was different sub groups, how do the subgroup outcomes will reflect into WCAG3?
… each subgroup will come up with outcomes, how will that be connected to WCAG3, in supplemental notes or other ways?
kevin: First question, don't know, currently there's an idea about groupings that align or are higher value in some domains
… not sure yet
… early stage thoughts, we'll see if it has legs
Jem: Who decides whether its higher value?
kevin: The WG, they need to look at the requirements, what applies more in what domains, as an example, education
… video content is very important there
… up to the WG to explore that as a topic, it may not pan out
… the other question, you mentioned COGA, Mobile, those are taskforces of AGWG, not subgroups of WCAG3
… AGWG has a number of TFs, mobile a11y TF, looking at WCAG2 mobile
… similar to WCAG2ICT
… we're going to be leaning on them, can they review WCAG3 for mobile
… COGA, they have their own outcomes and work
… the subgroups are within the work of WCAG3, in January we broke off small groups that worked on a specific set of guidelines
… 4-6 subgroups at a time, it seems to have worked well
… to come back to the question, mobile will review, COGA will review, and we're picking up content from their work
Jem: Mobile and COGA will be win WCAG3
kevin: Sort of, we'll be collaborating
r12a: So I'm a guy who writes documents and creates apps every day, I want to make them access, you've done a lot of work and that's my problem
… I don't have time to make myself into an a11y expert
… I don't have time to look things, and as I get older, I find it harder to remember what I've read
… I'm looking for a rapid answer more and more
… if I'm making a table, what do I need to do for that
… looking for a task list
… I want instructions
… I thought at one point WCAG3 is going to do that
… and it sounded like you might cover browser things, are there plans to have task-based things for users
kevin: Yeeeessss, one of the things that came out of Silver was how to create content for small developers
… one suggestion was providing specific developer or designer guidance, that is still there, we haven't started working on it
… WCAG2 has benefited hugely from the education and outreach resources on the WAI website which address your concerns
… theres the standard, and there's getting into the standard, using it to create content
… having an authoritative voice communicating what is needed is wanted
… we haven't started, not sure what it will look like, but we will explore it
… there will be an ecosystem, many good people will write about things, and there's challenges there too
… that's where the authoritative voice is handy
… if I'm talking about WCAG2, I have a slide that says don't read WCAG2. we need other places to start
… the research was clear
r12a: Let me know if you need a tester
<Zakim> nigel_, you wanted to ask about barriers to access
nigel: As part of that ecosystem, the BBC HTML guidelines have that task based idea
… not usable for everyone, it's a problem for everyone
… I q'd myself for the other end of the telescope, the draft now doesn't mention barriers to access, how do you understand for any a11y feature, what barriers to access it helps to overcome
… why don't you mention barriers to access
kevin: For each guideline is a set of user needs, not in the current draft, that is being devleoped and cleaned up for the last 8 months
… it's going into the next draft, it will not live there in the end, it's informative and will be put somewhere, it should address that
… "as a screen reader user I need this..."
nigel: That will help, one thing I'm conscious of is that there is not a one size fits all solution, there might be multiple solutions to achieve the same thing
… reading it now, I don't see that nuance about meeting the user need
… it feels a bit inflexible
kevin: The guideline is intended as an outcome statement, the goal is to define the needs that drive the requirements, it's not the only way, the methods and tests cover that, we can discuss more
<Zakim> shawn, you wanted to react to nigel_
shawn: Just briefly, similar to the situation now, it's likely that WCAG3 will be the standard, it won't be the introduction, tutorial, it will be integrated into the resources
<Zakim> Daniel, you wanted to comment on accessibility support set
Daniel: Coming back to accessibility supported, it's key in WCAG2, one conformance requirement
… if we are planning to undo some of the scaffolding in WCAG3, the definition is normative, any changes we make to this will impact auditors and testers justify their claims
… I think I heard this will be informative in WCAG3, or will have informative documents?
… this is a key thing about the testing affordances that accompany WCAG3
… are we planning to make this informative
kevin: I don't think so, but ask Alistair
TabAtkins: It is well known among CSS WG members that the WCAG2 color contrast algorithm isn't very good in some cases, we've intentionally avoided being specific as a result, are there improvements
kevin: Short answer yes
… we're looking to explore the algorithms, what is the best, which one delivers the best user experience
… it's on the cards
BrianE: Question, historical context around conformance, one of things on the slide, questions about % of conformance, the current direction is we have baseline, then supplemental, and tiers within that
… were there discussions of %s or levels of conformance within guidelines
kevin: I think it has been discussed
wendyreid: It was in the past
kevin: Meeting requirements at different levels would be tricky, vs having multiple requirements to meet
… we can discuss later and clarify
BrianE: Thinking of having more flexibility, room to move within individual guidelines, was curious about the perspective
<Zakim> JJ, you wanted to techniques / methods for non-web?
JJ: Question about the plan in WCAG3 for methods for non-web
… WCAG2ICT, WCAGMobile have no techniques
… will there be methods for non-web
kevin: WCAG2ICT looks at how to interpret WCAG in a non-web context
… we've changed the W in WCAG, it's the W3C Accessibility Guidelines, offers a method in different
wendyreid: Yeah, we have examples for things like games, audio or haptics
kevin: We're at time, thanks all, appreciate you, please bring your questions to us or issues in our github!