Mark Boyden: All right, friends, we're going to go ahead and get started. We like to try and keep these things rolling on time. You are here at Knowbility's Be a Digital Ally for the WCAG 3 Status and Review by Rachael Bradley Montgomery.
Couple of pieces of housekeeping I'm gonna roll through here, as soon as my,
Slide changes there. So, Be a Digital Ally is a monthly program that we do here at Knowbility. Our basic goals are to cover the basic skills and principles behind accessible digital design, and to make digital content accessible to people with disabilities.
Our audience?
Are people who are newer to, accessibility, typically, but
Also, for any skill level who wants to learn the topic at hand.
We, we're glad to be a part of your accessibility journey. In these webinars, we always strive to create an inclusive and accessible space for everyone, so we ask that all be kind, polite, and respectful, and we work to ensure accessibility throughout.
Knowbility is an award-winning digital accessibility organization. We were founded in 1999, so a little over 26 years old now. We are a 501c3 nonprofit. We're based in Austin, Texas, and we operate globally. And our mission is to create an inclusive digital world for people with disabilities.
We have several community programs. Right now, the Accessibility Internet Rally is going on.
I'll tell you a little bit more about that in just a second. AccessU is our annual conference. We're beginning to gear up for that. That happens the second week of May.
And AccessWorks, that's a program where we match, help match companies that need users with disabilities to do user testing, and we pair them up with people that we have in our database.
And they get paid a livable wage for doing that work. It's part-time, but it's one of our programs. We also have a K-12 digital accessibility program, and then this program be a digital ally.
The Accessibility Internet Rally, they're turning in their, their websites this coming Friday. It's an annual hackathon on it, building
accessible websites. We bring in web developers and nonprofits and artists and musicians who need websites, and over 8 weeks, the developers
learn about accessibility, are trained in it, and they build a website for the nonprofit. Winners get tickets to AccessU, and we have an awards ceremony coming up January 15th, if you'd like to join us. And you can find out more about that program at Knowbility.org slash air.
Also, coming up soon is our annual training conference on digital accessibility. It is a hybrid event. It's May 11th through 14th in 2026.
You can either attend in Austin, Texas, or join us online, and you can get more information about that program at accessKnowbility.org slash accessu.
Then we have services, too, and so we can do accessibility testing, auditing for your website or smart application.
We also do leadership training and strategic consulting for organizations.
As well as customized training programs. Access Works is also part of our services, as described earlier, and we also have an accessibility help desk where you can contract with Knowbility to get on help as needed.
So, coming up next month, we're going to be dealing with making math accessible, and we'll have more… we'll be sending out more information about this, but that will be December 18th.
And, at the end of the program, we'll ask you to give us some feedback.
So, I'll put that up much later, but I just wanted to let you know that we'll be putting that up when we complete this,
The succession.
You can stay connected.
to Knowbility in multiple ways, our newsletter, Knowbility.org slash subscribe. You can follow us on social media at Knowbility, or you can email us at events at Knowbility.org.
All right, final on the housekeeping side of things. You may put your questions in the Q&A. They are on the, in the button on your menu at the bottom of the screen. Other places, if you're on a small screen, sometimes found under More.
You'll be able to ask in person, and raise your hand. That's under the panel item. React. There's a raise hand option there.
And during this, you can type in the chat, and Rochelle will, see those and comment on them and answer them as we go along, but otherwise, we'll handle most of the Q&A at the end, and that'll be the time when you can raise your hand and all of that.
So, I would like to now introduce you to your instructor, Rochelle Bradley Montgomery. Rochelle, go ahead and take it away.
Rachael Bradley Montgomery: Alright, hello and welcome, everybody. Let me go ahead and share my screen.
Make sure that is all working correctly. Can you go ahead and see the WCAG 3 status and review?
Mark Boyden: We see it.
Rachael Bradley Montgomery: Fabulous. All right. Well, let me start off with a question that everyone, seems to ask whenever I talk about WCAG 3, so before we begin our journey together through WCAG 3, I want to address this question, which is, when is WCAG 3 coming?
There we go. So here is our draft schedule.
While this is a draft, there's always the chance of slipping, and that chance increases the closer we get to a final publication. This is what the chairs of the Accessibility Guideline Working Group are working towards at this point.
So, previous posts, if you have been following the WCAG3 effort, have asked, kind of… they're asking for patience while we come up with how long this is going to take, and so we have been experimenting for the last two years and running different trials to have some data, and so we are kind of pulled that all into this particular
draft. You are going to get a draft of WCAG 3 in January of 2026, so maybe the end of December?
early January, and that is going to be a fairly complete initial draft. I'm going to talk about maturity models, or maturity levels in a little bit, but it is a developing draft, but it is a fairly complete developing draft.
It is going to be available for comment. We're gonna… I'm gonna go over with you today some of the comments we are looking for. At the end of 2027,
beginning of 2028. We will be giving, or putting out the last major draft for comments, so we're hoping to have been through a lot of iterations by then, it's a two-year period, and are going to be down to the last set of review and revisions, and we are aiming to have WCAG 3, the recommendation document and some of the supporting informative content.
out in 2029, probably towards the end of 2029. Then we will be finishing the rest of the informative content in 2030. So…
Now that that is out and available to you, I will say again, this is a draft, we're finalizing it. This information that I'm giving you today is about as hot off the presses as it possibly could be. The full schedule, once we are completely finalized with it, will be available at a link in the slides.
Which is the WCAG3 timeline. You can actually, search for WCAG3 timeline, and you will see the current one. But this new one will be available then.
So, with that in mind,
I want you to kind of step back.
And, get comfortable. I'm gonna walk you through this journey that we are on with WCAG3. I'm gonna step back into some background, make sure we're all starting from the same place, and walk you through from beginning to end.
So WCAG 3, the Web Content Accessibility Guidelines, are now the, sorry?
were developed by, or are developed by the Accessibility Guidelines Working Group. This is the same group that did WCAG 1 and WCAG 2. It's under the W3C. It represents a major development from WCAG 2. So in the same way that between WCAG 1 and WCAG 2, there were notable differences and changes, there'll be just as many differences between WCAG 2 and WCAG
3. It is not guaranteed to be backwards compatible, that's why the number is going up from WCAG 2 to WCAG 3.
It does not deprecate WCAG 2, and so I really want to stress this. Just because WCAG 3 is coming doesn't make WCAG 2 any less important. It is still the standard that is pointed to by most…
International laws, it is still the one you should be working to, and even after WCAG 3 comes out, it will take time before the.
Tamer Zaid: one.
Before there's actually a change in WCAG… in the laws, picking up WCAG 3. I'm going to pause, because I'm hearing someone speak, so do I need to address something?
Mark Boyden: I believe that was a new person who came in with Mike on, so I muted them.
Rachael Bradley Montgomery: Okay, perfect.
Wanted to make sure. So…
There's a couple goals that WCAG3 is setting out to resolve. Our first goal is that we want to make sure that WCAG3 is written so it can be adopted by government regulation and support harmonization between the different laws that pick it up. So we want to make sure that it is something that can be adopted worldwide, and as it's adopted, everyone's pointing to similar and related standards. That just makes it easier for
everyone to comply. Very few things are only in one country or legal area these days. Things are adopted worldwide and used worldwide, so the closer the standards are to each other, the better.
We want to design WCAG3 to make sure it keeps pace with rapidly evolving technology. And that's not just the rapid change that we're dealing with in how content's presented, it's also the change in the types of content and in how AT supports
Different interactions with that content.
We want to make sure whatever we create scales for both small and large sets of content, and also simple and complex sets of content. There's such a variety on the web and within all digital content and technology.
We want to make sure it applies as widely as possible to as many digital content situations as possible, from a simple website to a virtual reality environment.
We want it to be able to support solutions from more than just the author, and this is a big shift in WTAG3. So, WCAG1 was very technology-specific. WCAG2 strive to be more technology independent. We're pushing that even further in WCAG 3, and we also want it to be solution-independent in many ways. So, we want to be able to write outcome-based
Standards, and then have specific solutions underneath that, but that allow it to be flexible as it's written and can comply for a longer period of time.
We want to make sure that it's easier to read, easier to understand, and easier to use than WCAG2 is.
And we also want to expand it so that it addresses more disability needs than WCAG 2 is. So those are the goals we set out with. It's not a small task. Even updating a standard is a huge undertaking
Re-envisioning a standard is, quite a journey to go on, and welcome to that journey if you are just joining us on this.
One of the ways that we decided we would work as a working group is, with maturity levels. And I should pause and say, I am one of the co-chairs of the Accessibility Guidelines Working Group, I'm Executive Director of Accessible Community and an Accessibility Architect at the Library of Congress, so, have been working in accessibility for a number of years and am deeply involved in this particular project, and I appreciate Knowbility.
Inviting me here to be able to talk about it.
In order to be able to get through the process of writing and re-envisioning a standard, we decided to work at different levels of maturity. And so the content is evolving over time. And all of the content has an indicator next to it in the drafts of what level of maturity it is.
So that tells you, as a reader.
Where in the development process the content is.
Whether the draft content is ready to be experimented with or adopted, we don't want you building things that are likely to change in 6 months, but we do, when it gets more mature, need people to be building and trying out those standards. We're also telling you what kind of feedback we're looking for. The more mature it is, the more details we want, the more implementation trials we want.
So we're trying to communicate with you with those markings about what we need back from the public.
At each step, the draft becomes increasingly detailed, and the content is more definite. So the first and fuzziest set of content is placeholder content. That is going to change. If you see something marked placeholder, assume it is changing
Don't worry too much about providing feedback on it. If you see something marked as exploratory, change is very likely. We're looking at it as a group, but we're still evolving what it's going to become.
If it's marked developing, the details are still likely to change, but the overall direction is pretty set. The group's fairly confident in the direction, and so while we're still working on it, it is…
ready for comment. And that is the stage that is coming out for the majority of the draft in January. So the draft that's coming up will be at the developing stage.
Then, content will move on from there, in chunks.
And it will move to refining. And at that point, details may change, but they're not likely to change. The overall direction is very unlikely to change when it reaches refining, and when it is mature, it is very unlikely to change at that point. So, again, not all of the draft will always be at the same level. This January draft will almost all be at the developing level.
WeCAG 3. What is so different? And I'm going to walk you through all the different pieces that are coming in January in hopes that you can start thinking about it now, read the draft.
And provide comments back to us.
The first part is the structure.
So, to orient yourself on WCAG 3, it is organized into guidelines, and those are plain language outcome statements. So, for example, it might be, users have equivalent alternatives for images.
Or users can review, confirm, and fix the information they submit in order to prevent errors. They're all user-centered plain language statements.
Under those will be a lot of informative content, that's called how-tos. And when I talk about informative content, that's content that's not part of the main standard. It's understanding documents in WCAG 2.
It's called How-Tos in WCAG 3, and it is content that is easier for us to update, change, and add to than the main standard. Updating a standard is a very,
intensive process, and so the informative documentation is something we can update pretty regularly and easily. That content is going to include things like understanding why a guideline is there, who it affects, how to get started, and we're going to create activity-centered
Documentation for planning, design, development, and testing, all tied to that guideline.
Underneath the guidelines are a combination of requirements and assertions.
Now, I want to note that the word foundational, supplementary, best practices, a lot of this terminology, we're all still discussing it in great length in the AG, in the Accessibility Guidelines Working Group. It's going to change, but the concepts are pretty, agreed upon at this point.
So, one part of the guideline is going to be foundational requirements, and those are requirements that will need to be met in order to conform to the standard. So, they are things that essentially are required for you to do.
They are also very testable. They are items that can be tested and verified with very repeatable results.
Those will be in the standard itself, and then the informative documentation underneath it will be methods, those are very similar to techniques in WCAG 2, and under those will include different tests.
In addition to the foundational requirements, guidelines will have supplementary requirements. Those also have methods and tests. The difference is that supplemental requirements or supplementary requirements go beyond the foundational requirements. They're used at all levels of conformance, but there is some flexibility, at least as proposed right now, in which ones are picked and used to meet
conformance.
So I'll talk about that a little more in the conformance model. Just know right now, you've got these foundational requirements and supplemental requirements, and then you have something new called assertions. So, requirements are very similar to success criteria, but assertions are brand new. These are statements of fact.
that, talk about having completed a procedure that we know, from accessibility practice, improves accessibility. So we know that doing usability testing with people with disabilities improves accessibility.
But it's not like a success criteria, where you have these repeatable results. I conduct a usability test, and you conduct a usability test. We may get different results, so it's not as provable. But we do know and want to encourage
People, too, go ahead and do these processes because we know they lead to better results. So we're letting them make assertions that they did conduct these processes as part of conformance. These have to be documented.
And they have to be attributable to a person who's making the assertion in order to be used. But they do then have the potential to be used for conformance.
Something else we've learned over the years is that there are best practices, things that we just recommend in general people do. They're not necessarily testable, they're not necessarily applicable to everyone, so we can't really make them requirements. But we want to put them in
where everybody can see them, right along with the requirements and assertions. So those are also there to support guidelines, and will be visible within the document.
Here is an example requirement, and you'll see some of the differences, and I'll compare them in a little bit with WCAG 2. So there's three sections to any requirement. The first is just the requirement text.
And in this case, it says, text can be increased in size to at least 200% of the platform's default body text size.
The second section of this is it applies when text is presented, except when the same text is available elsewhere in the page view, and can be increased to at least 200% of the platform's default body text size. So essentially.
Text has to be increasable when it's presented, unless there's an alternative version of it. That's kind of what this is saying, but it's trying to be as close to plain language as possible. We aren't trying to put everything into a single sentence anymore, and we're trying to break it out. So this is the format of the requirements you are going to see in the next draft. All of them are written in this
way.
An example assertion?
is a plain language review. So the content author, and this would be replaced with whoever actually was doing the assertion, conducted a plain language review to check against, and then applied plain language guidance appropriate to the language used. This includes checking that the verb tense used is easiest to understand in context.
The content's organized into short paragraphs.
And the paragraphs of informative content begin with a sentence stating the aim or purpose of the content. These are good plain language practices. Conducting a plain language review creates notably more usable
Content. We want people to do this, and we want them to be able to assert that they did it, and take credit for having done the work in creating a plain language review.
So, this is, just an example assertion.
So 220 versus 86. This is one of the big things that comes up when we start talking about WCAG 3. It is the difference between the number of requirements and assertions.
and the number of success criteria in WCAG 2. So there are 220
approximately 220 requirements and assertions in WCAG 3. It is a long draft. But what we have found is that by increasing the number of requirements, we are lowering the confusion that is there in WCAG 2. Here is an example of why.
In WCAG 2, there is success criteria 1.1.1, non-text content. It says that all non-text content that is presented to the user has text alternatives that serves the equivalent purpose except for situations listed below, and then it lists a number of different situations.
This is being broken down into at least, it's actually quite a few more than this, but at least four different requirements just on images alone. That non-decorative images are detectable.
That decorative images are programmatically hidden, that equivalent text alternatives are available for images that convey content.
And an assertion that
you can use, that we follow an organizational style guide for image-text alternatives. So these are four different pieces that are all implied and kind of buried underneath success criteria 1.1.1. We're trying to bring all of the implied requirements, all of these extra checks that we do as accessibility professionals, but aren't directly in the success criteria, up to the forefront, make them clear.
Explicit requirements that people can see and understand simply.
That increases the number of them. But it does seem to reduce confusion, and you don't have to go hunting through extra materials to see what you have to do.
12 versus 4. There are 12 different categories of content in WCAG 3, versus only 4 categories of content in WCAG.
Q.
So in WCAG 3,
We are organizing it, at least at this time, by the thing you are testing or working with. In WCAG 2, the guidelines are organized by perceivable, operable, understandable, and robust. In WCAG 3, the categories are image and media alternatives, text and wording.
Interactive components, input operation, Error handling, animation and movement, process and task completion, layout, risk.
Consistency across views, help and feedback, and user control.
So… Part of the…
way we are approaching WCAG3 is that we believe in tagging, and we are going to tag the content as perceivable, operable, understandable, and robust.
And we will provide a way to actually sort the content. So if you want to use the original organization of those four categories, you'll still be able to. You'll just re-sort the content. But the default view we are tying into,
The thing that is being… Written about from a standards point of view.
I see I have comments, and I apologize, when I shared screen, they went away.
Mark Boyden: Well, one was, from Cam. Higher count, lower confusion. This is great. Has a personal checklist breaking down SC111, 131, and others into multiple checkpoints.
We are also… sorry, Kevin. And having something like that is, I'm sorry, having something like that more universalized is exciting.
Rachael Bradley Montgomery: Like many accessibility professionals, I've had to rewrite checklists to make it more explicit, so I'm excited by it, too. It also lets us deduplicate. There are a number of success criteria that over the years have intersected with each other. By breaking it into smaller pieces, we actually get to reduce some of that duplication and overlap.
Mark Boyden: A similar one is, so an assertion is a type of audit support, question mark.
Rachael Bradley Montgomery: An assertion can be an audit, it can also be part of development, so it is going to be tied into from a conformance statement.
But it has to be somewhere. So if you were writing a VPAT, you could… the company could make a statement, an assertion on the VPAT, or they could put the assertion as part of their accessibility statement on the website, for example, or the product that's being provided. It has to be available somewhere in order to use it.
But it affects a number of different processes, like the plain language review, but it could also be usability testing, it could be having a style guide that is used across,
Across an entire product in order to create consistency, so they touch in different areas, it just depends on what the assertion is.
Mark Boyden: The last one I think you just answered is… was, is it expected to stay within the poor framework?
Rachael Bradley Montgomery: So, it is not expected to save day in the poor framework, but if you love the poor framework and want to use it, it is a great educational tool. You will still be able to sort everything and use the poor framework instead of the framework we're going to use by default.
And again, all of this is up for comment and conversation, so feel free to counter that in the comments, and provide comments if you disagree.
So, lots of opportunities to do that over the next two years.
Some other concepts in WCAG 3 that are worth noting and knowing about. The first one is views. So, you'll see page slash view in a lot of places in WCAG 3 in the draft that's coming up, and that's because we are going to be using views in addition to URI-based web pages. So, in WCAG 2, it's a web page as a way of evaluating
And that is tied to a URL as…
different technology involves, as the web has moved out into different areas. A web page as a concept is becoming less frequently used. There's a lot of situations where we need something different, and the view is what we will be using as that alternative. It is content that is actively available in the viewport, whether that viewport is a VR glass set, or a single-page app, or a mobile app.
This allows for interfaces that don't fit in the web page or website model to still use these standards. And if you are creating a web page, you can still use a web page that is still perfectly valid as a unit of conformance. So, that is an expanded area that's coming.
Another concept that's in WCAG 2, but we don't talk about or leverage anywhere near as much as we could, is this concept of accessibility supported, and we are leaning on that a good bit more in WCAG 3.
The concept is similar. It is how, how does an author know that a technique will work in practice? And if any of you were working during, kind of ARIA's adoption, some browsers used it, some browsers didn't, different browsers used ARIA differently. I mean, we always go through these evolutions of technology.
We need to know, is the method that you're using to make something accessible actually going to work? Is it going to work with the technology stack that you are using? And that's what Accessibility Supported really asks.
In WCAG 3, we're going to have something called an Accessibility Support Set, and that is a defined set of user agents
Assistive technology and plugins that you are making your conformance statement based on.
We're going to have a default set for WCAG 3, but especially in non-English languages, you may be picking a different default user set. If you're working in a kiosk, you may have a very restricted accessibility support set. It's the things installed on a kiosk. If you're working behind a firewall, your company or organization likely also has a slightly different accessibility support set.
This lets us explore the option of not just having author solutions to problems. One of the ways we may… we are trying to write
WCAG3 requirements is to focus on the outcomes, not who is solving them. So, if the accessibility support set solves it, and you have a scoped accessibility support set, the author doesn't necessarily need to fix something.
And an example of this is, like, text on images. Increasingly, we are finding that the accessibility support set can pull text out of images. Ten years ago, it couldn't, but it's pretty, pretty robust these days, and as it becomes more and more robust, the need for the author to provide, excuse me, provide a text alternative to images of text
is reduced.
And it becomes more important that they don't break the operating system and assistive technology's ability to pull that text out by doing things like creating crazy backgrounds. So, it's shifting how we think about assistive technology and how we think about accessibility as we move forward. How can we encourage more universal solutions? How can we allow the standard to be used
useful across these different pieces of technology in these different areas. So you're going to see some things in WCAG 3 that aren't in WCAG 2, because they've been solved by browsers for a long time, like pointer visibility.
But we can't assume we're going to have browsers. We have to assume that technology will be using web content in applications and areas that aren't within a browser framework, and we want to make sure they know they need to figure out the pointer problem, too.
So, we have things that already are defaulted as working within a certain and, kind of conventional current accessibility support set of Firefox, Google, with
existing assistive technology, but we're not assuming that's always going to be the case. So that'll be something a little different that's coming in WCAG 3 as well.
At the foundational level, we want to make sure that the methods that we provide in WCAG 3 can be relied on by the accessibility support set. So, within the context of writing a standard.
The accessibility support set will, say, alright, within this set of technology, this set of methods is going to work. We've tested it, we know it's working, and then if you're using things outside of that, you'll have to do a little more testing. At the higher conformance levels, especially when we start doing non-English language support, things may be regional or contextual, and there'll be more, more details on that.
And Mark has provided a link to the current version of Accessibility Supported. If you haven't, looked into that or have forgotten it, again, it's not talked about all that often. You can see it in WCAG 2.
How will the accessibility support set be kept up with constant updates from browsers, AT, etc? We will have to, have a process for doing that.
And some of that will be coordinating with those companies and organizations, so, that is definitely something that we are… have started doing already, and will need to do over time.
I know that a number of other organizations track where different user agents are at supporting different technologies. I don't know if we'll be relying on them, or if we'll be doing it ourselves. That's a question that's still to be determined.
Great question.
Functional needs. This is not, again, a new concept, but how we're using it is a little different. So, when you read EN 301549 or Section 508, you run into functional performance criteria.
Functional needs are similar, but their functional performance criteria as they are right now aren't sufficient.
So, we are working to create a set of needs, that are created by kind of a limitation that people are experiencing. And so, for example, without vision. They have to be able to use content without vision, with limited memory, with sensitivity to motion, and so we're putting that together.
And we want to make sure, again, we are expanding coverage of WCAG in a way that still lets people need it. And…
So…
the requirements, all requirements and assertions, are going to be tagged with these functional needs, based on which ones they most impact. So, some requirements, support a functional need, but it doesn't… it's not a…
kind of, it's not as important as certain other requirements or assertions might be to supporting that particular functional need. We want to make sure the most important assertions and requirements are tied to the functional need and tagged with the functional need that they impact.
And that leads us to our conformance model. And I want to stress, this is a draft, this is the thing we are talking about most right now, but this is what'll be coming out for comment and conversation in the January draft.
At the most basic level of conformance, which is bronze.
People would meet all of the foundational requirements.
and some portion of the supplemental. So I have an image on this screen of a bar.
And that bar is divided into one-third at the bottom, which is the foundational requirements, and about two-thirds above it, which are the supplemental requirements and assertions.
The line that dictates bronze is in the supplemental section, so that all the foundational are included to get to bronze, and some of the supplemental are included to get to bronze.
Because all the requirements and assertions are tagged by functional needs.
then we would put a requirement in to meet Bronze that a certain subset of those, a certain number of those supplemental bifunctional needs would have to be met.
So the conformance scope to meet it would be a certain… all of the foundational and some set of supplemental requirements and assertions within each functional need. So you couldn't just support individuals without vision, you'd also have to support individuals with limited memory and individuals with sensory disabilities, for example, or sensory requirements.
Again, how we work those functional needs out, to be determined, but that's the concept we're working on.
When a requirement's not applicable, it's marked as passed. And why that's really important is that gives us the complex to simple scoping ability. If you have a simple website, and you're not building in motion and video and a number of other complex, technologies.
You don't need to meet those, you just automatically get credit for having met them.
And so, there's not a tax for creating something simpler.
So that's just an important concept here to understand. So again, I'm going to repeat this again, because it is… and then I'll answer the question, it's a little bit hard to understand.
All foundational requirements must be met in this set.
The supplemental has requirements and assertions.
And a minimum number against each functional need would have to be met to meet bronze. You would meet more to meet of those supplemental to get to silver, and you'd be even more to get to gold. Now, the question, is this equivalent to level A? The answer is, we don't know yet, and that is one of the questions we're going to ask you. So I'm going to go to the next slide.
We really want public feedback, so how do you get involved? Where do you go from here?
We have goals for the draft that's coming out, and we really want public engagement. We want to know what guidelines, requirements, and assertions we missed, because I'm sure we did miss some. So, even though there's 220-ish in there, we would like to know if… which ones we didn't get.
We would also like comment on the conformance model. Is it an improvement over what we've got?
is it doable, or implementable? And are there alternatives that the public would suggest, that you would suggest, that we haven't considered? Now, we've considered a lot, and… but we would really love to hear your thoughts on those.
We also plan to take this forward with different examples and discuss the conformance model with different regulators worldwide to get additional feedback. So those are our goals for basically January through June, and we publish every 6 months.
Some of the questions that we have as a group, and we would like more comment and thought on.
Does the new format, so all of those broken-out requirements, how we're writing them, does it make WCAG 3 easier to read and understand? So when you take a look at it, do you feel like you can digest, understand, and use WCAG 3 more easily than you could use WCAG 2? And are there things we could do to make it even better?
Then we get to the foundational set question.
Should the foundational set, that set of mandatory, be smaller?
approximately the same as WCAG 2A and AA, or, I'm sorry, smaller, approximately the same, or larger than WCAG 2A and AA. So there are 3 different levels we've been talking about for that foundational set. One is extremely tiny.
And it could simply be, are things detectable? Do they cause harm?
like, immediate physical harm, and do they limit the interaction? So, is it, saying you must use a mouse or a pointer? So, those could be a very small set, it's about 21 of those 220.
requirements, and it would be a very tiny set, which would give a ton of flexibility to people on how they met the other supplemental, which supplemental they picked, and how they met that bronze level.
We could put it to be all of those prerequisites, those kind of… that tiny set, plus do things exist? Do captions exist? Do audio descriptions exist? Do abbreviations, are abbreviations spelled out?
But none of the quality checks. So, is there text alternatives? But we wouldn't get into, are they comparable and high quality in that foundational set? So we can kind of make it a little bit bigger than that, and go to that level, which is a little below
2.2A and AA.
Or, we can take that foundational level up to where 2.2A and AA is, so that all the existing success criteria are there, and covered, and a few extra things that are comparable to those would also be there.
That shrinks down the flexibility, but it makes sure that, accessibility in WCAG 3 is about comparable to accessibility in WCAG 2. There are trade-offs in all of those decisions. If you think about that sum, if you think it should be a smaller set, what rules would you use to select that set? If you think it should be approximately the size of WCAG 2.2A and AA,
You know, what are your thoughts on that? That is a comment we would really like you to think about and, come back to us with.
Should we include assertions within the foundational set is another question. Right now, we are assuming assertions will all be supplemental, but there are a few assertions, like the plain language review, that are so valuable to people with cognitive disabilities. They are not repeatable, testable statements.
But the process itself has value, should those be required.
should we tag, a very small set as a starting point? So, separate from performance entirely, we have had conversations about kind of a prerequisite set. Things that are detectable, avoid immediate harm, the ability to, edit content, very…
small, defined set, and not have them tied to conformance, but just give them to the public and say, here's the starting point. If you don't meet these.
Don't go on until you meet these. That's something we've talked about, we'd like to hear more from the public about whether that's useful.
And should there be one or more levels within the foundational set? So, in WCAG 2, we have A and AA. In many ways, we treat those as the same thing, because AA is required in most places.
But, there is this potential on-ramp. We could…
create an on-ramp in educational materials completely separate from the standard itself, and talk about it from an educational side. Is there a value in putting multiple levels within that foundational set from a conformance side? So that's a question back out as well.
I will come back here.
And C…
The technique document, so all of the understanding content and all of the techniques are being rewritten and moved over. So all of that content will be available, along with additional information, in WCAG 3, but it's not going to be a one-to-one relationship, because we're breaking out the requirements in a very different way.
So…
How do you do feedback? I just gave you a ton of questions to think about. I hope it will, give you something to peruse… ponder and think about going forward. There are a couple different ways you can tell us your answers.
The first is to file an issue on GitHub.
That is our preferred way. It lets us track things, get back to you, you can set it up so it emails you back, so you can keep up with our discussions.
So that is definitely the first way, but we also have discussions on GitHub. That's something new in WCAG 3 we didn't do in WCAG 2. When we are having some of these conversations, if you are passionate about one, find the discussion on GitHub and jump in.
You can also send an email to public-agwg dash comments at w3.org. If you're filing issues or sending emails, please send one issue per GitHub, or one topic, one concept.
per issue or email. If you send us 10 pages of different comments, we then have to break them all out into separate issues, and we can't track it back to you. You aren't seeing the feedback on each individual issue the way you will if you put it in as one at a time.
So, again, ideally file an issue, send an email if you can't, try to keep it as a one-to-one relationship between the thing you want us to address and, the issue you're filing, or the email you're sending. That just really does help us respond.
More effectively, and helps you track it better.
If you're ready to take another step in and join the AGWG, the Accessibility Guidelines Working Group,
You can do this a couple ways. So, one is if you're working for a member organization. If you are, talk to your AC rep for the W3C, they can assign you, you can join, and start contributing immediately.
The second way is you can become an invited expert. Invited experts are individuals who aren't employed by a member organization, but contribute their expertise and time to working on WCAG 3. There was a time when I was sitting in an audience from the other perspective and thinking, wow, I really want to do this. I discovered I was part of a member organization and didn't know it, so that was a quick join.
But I've also worked as an invited expert on WCAG, and both are fantastic ways to contribute. If you want to be an invited expert, there is a form you fill out. I will tell you from a chair's perspective, what we look for is people who have already contributed. So, if you want to come in as an invited expert, I would suggest the first thing you do is hop on to GitHub.
get into some discussions, provide some comments, some thoughts, and then put your invited expert application in. If we see a history of participation, then we are much more likely to accept you in as an invited expert, and we also know where to place you, on what subgroup, what area you've been interested in or engaged in. There's a lot more information about all of that on W3.org forward slash
Membership.
And with that, I will take questions and conversation. Happy to help with, any… any questions you have coming out of this.
Mark Boyden: Rochelle, there was, just a little above the question and answer, it was a fairly lengthy little comment.
About WCAG failures and deaf users that might be worth reviewing and…
Rachael Bradley Montgomery: commenting on. Alright.
So yes, for individuals who are deaf, we are working on a new sign language-based section in WCAG 3. That is an area we are looking for invited experts on, so if you are excited about that, put some issues in, send… and are willing to come join the group and work with us on it.
We are definitely writing some, they will be in the January draft, but we definitely would like more input from the Deaf community to make sure we are doing and writing what needs to be there.
Mark Boyden: As a reminder, if you'd like to ask your question live, just go to the React button, and then click Raise Hand, and we'll ask you to unmute and ask your question.
Let's see, we have one comment from Roger. Roger's long advocated that accessibility stop being treated as an add-on, but is integral. It appears that this is where it's headed. Thank you.
Rachael Bradley Montgomery: I am hopeful that it will be too, and I'm hopeful that if the standard's a little more readable, and the processes are a little more important, that we'll get there, that it will move that forward. But so much of the work you all do is critical for that step. The standard by itself cannot force adoption.
Mark Boyden: Is 20… Christina asks, is 2030 the anticipated published date out of draft, or the date the draft will be completed?
Rachael Bradley Montgomery: So, I've put the draft schedule for those of you who joined late, because it's the first thing I put on. So, the 2030… 2029 is when we're hoping that the draft is published and out. That does not mean adopted into law. It means that the recommendation is finalized and put up as WCAG3 is here.
2030 is when the rest of the informative content would be done, so for 2029, what we learned when we wrote WCAG 2.1 and then 2.2 is that there is some informative content, the tests, the methods and techniques, that we have to write in order to write a good standard. If we don't write them, we don't end up with as good a standard.
So, we know we're going to be providing that out with the normative document.
And that 2029 goal date here. But things like, how to integrate that particular guideline in planning, or in design, or development, those additional guidance, longer descriptions, more examples, all of that extra content we probably will not have in the 2029
date, we're looking more at 2030 for getting all of that content out.
Will there finally be limitations on maximum color contrast? For example, yes, we do have a, I believe.
I've seen go past, though have not verified in the last two weeks, that there is a requirement around, maximum color contrast. I believe it's a range. When you get to WCAG, one thing a lot of people are looking for beyond the schedule is the contrast algorithm we will be using. We are still getting research together for that.
So we won't have those numbers, but the concept that contrast needs to fall in a range based on size and based on, having an upper end as well as a lower end is in there.
Did that make sense? Did I answer that in a way that made sense, Mae?
Excellent.
Is there a plan for working with governments and organizations to ensure this actually gets adopted? So, yes, that is a… are we stuck with WCAG2 for the foreseeable future? Practically, what does two standards mean? There's a lot in there to unpack. Yes, W3C…
works with, different government regulators and converses. A lot of the WCAG members, or at least some of the WCAG members, are on some of the groups that write EN3159 or Section 508.
We don't have the ability to…
in any way force governments to adopt it, and my expectation is it will take time to be adopted. We will have these two standards overlapping for a good bit. WCAG 2 will likely be,
The legal requirement for probably at least a few years out, even after WeCAG3 is out.
Practically, what does that mean? It means that you're still going to need to meet WCAG 2, and our hope is that we're building WCAG 3 in a way that you'll be
at least working towards meeting WCAG 3, if not meeting WCAG 3 by meeting WCAG 2. There may be a few extra things. My hope would be that by providing clear guidance, that people are adopting WCAG 3 and starting to build towards it, even though they're meeting WCAG 2 in the interim. So there'll definitely be a changeover period, just like there was a changeover period between WCAG 1 and WCAG 2.
And a lot of times, it just depends on the organization, where they're working, and how forward-thinking they are, what standards they're using.
All caps! Is all caps in there as a requirement? I can't remember. I know we've talked about it, but what I don't know is if it's part of the plain language assertion and writing assertion, or if it's in there as an actual requirement.
But if it is not in there, and you can point to some research on it, that would be perfect. Put us, anytime you can point to research on how a requirement or an approach
helps people with disabilities, it's easier for us to put it in, because we have to be research-driven. So, if it's not there, please go ahead and file an issue, and just point to that research, and
We're happy to get it in there.
And that's exactly why we want to put this out for comment. We want you to be able to look at the list and go, yeah, missed!
Fill in the blank. Missed sign language, or you missed all caps.
Mark Boyden: We've got a few more minutes for any more questions, if you'd like to ask them.
Okay, meanwhile, I put in the chat a link to our survey, and I'll put that slide up here in a second, but Rochelle, thank you so much for being here, taking the time to put this information together.
And, and help us understand what's going on with WCAG3. I certainly appreciate it.
Rachael Bradley Montgomery: Oh, thank you all for joining us.
Hopefully there is… a,
hopefully the recording is available so people who missed the first little bit can catch up. I did see a question here, was there an update on the anticipated ETA of WCAG3 release?
So Wendy, this is actually up on the screen now, I think, with the schedule. So we are, getting the draft out for comment, the first developing draft out in January of 26.
The last major draft for comment, we're aiming for January of 28, with publication in 2029. Likely at the end.
Mark Boyden: And yes, there will be a… this recording will be made available and posted to our Be A Digital Ally webpage. Everybody who registered will get an email when that's ready and available, along with a copy of your slides and a transcript of this session.
Rachael Bradley Montgomery: And then there's a question about the ASL experts. We're looking for people who, can speak to and write and identify the requirements needed from a technology side to support ASL within media.
I think that's the… I think there's a wide range in that.
So…
Mark Boyden: If that is of interest, let us know.
I have a couple more for you.
Samantha asks, what's the best way professionals can begin to prepare ourselves and clients for this change and advocate for adoption?
Rachael Bradley Montgomery: The number one thing to start with is to acknowledge and make sure people know WCAG 2 is not going away, because if people postpone doing accessibility work against WCAG 2 and waiting for WCAG 3, it is counterproductive for all of us.
We… and by meeting WCAG 2, you're taking huge steps towards WCAG 3. So that is, by hands down, the first and most important thing that you need to do.
After that, I think the…
thing to be thinking about is those processes, those assertions. What processes can people be doing to help improve accessibility? Take a look at the draft, keep an eye out on what's coming, but please, again, it's developing, it's still going to change some, so don't…
assume it's going to be there. Think about, think forward, keep an eye out on it, but until we get to the refining stage, I wouldn't be recommending to people that they start making changes based on WCAG 3. It is still in process. So, first, you know, focus on WCAG 2, keep an eye on WCAG 3. When we get it later in that 2028-2029 area.
you'll start to see things really being refined, mature. Those are the pieces to start really focusing on.
To help people prep.
Yes, there will be a crosswalk.
even question, will there be a crosswalk from 21 to 2-2? We actually have a draft one already, and we will be publishing that as part of the supporting documentation.
Mark Boyden: Roger says, kudos. My frustration with WCAG has always been that it says the target accessible experience must have parity with something as undefined.
The assumption is that the main UX works well for people without disabilities, but that is an assumption that may not be true. Without defining what a successful experience is for the mainstream, defining parity to that is dubious.
The only way to fix this is to define successful interaction in terms of universal design. In this, people with disabilities are simply part of the audience, not outliers or afterthoughts. Where this leads us to… I'm sorry, where this leads us is toward more of a Nielsen 910 heuristics.
So, the 12 categories appear to be just that. Thank you.
Rachael Bradley Montgomery: But we… I am hopeful that they are. They are certainly moving in that direction. Again, a standard, sadly, can never force, equity when we talk about
conforming, we talk about conforming to a standard. We don't talk about making it perfectly accessible, because we try, even from the group's perspective, to recognize that just because you conform doesn't mean you're truly…
Providing the best experience, but we're… we are doing our best from a standards perspective to help encourage that as much as possible.
Mark Boyden: Rochelle, we're at the end of our time. If somebody has questions and wanted to follow up with you, is there a way for them to get in touch with you?
Rachael Bradley Montgomery: You can reach me, I'll put it in chat, at rmontgomery at lock.gov.
Or at Michelle at accessiblecommunity.org, or you can reach the chairs.
Oh, I'm gonna forget. At the bottom of, WCAG3, there is an email for reaching us from public comment as well, and I think it's also with the slide deck. But if you want to reach me directly, those are my direct emails.
Mark Boyden: Great. Thank you again so much, and again, this will, recording will be shared with everyone. You guys have a great weekend, and for those who, celebrate, have a good Thanksgiving.
Rachael Bradley Montgomery: Thank you all.
Mark Boyden: Thank you all.