Scheduling Approach Alternatives #322
Replies: 13 comments 70 replies
-
Option 1 - This approach focuses on getting as much possible done at the same time, in stages. It prioritizes maturing Foundational and Normative content.Phase 1 (2027)
Phase 2 (2029)
Phase 3 (2030)
Phase 4 (2031)
Phase 5 (2033 and onward)
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
Option 2 - This approach prioritizes reaching similar coverage to WCAG 2.2 AAA and providing an opportunity for public feedback before fully maturing content. It then builds off that work.Phase 1 (2027)
Phase 2 (2029)
Phase 3 (2031 and onward)
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
I don't think either option is acceptable. Option 1 means WCAG 3.0 won't get to recommendation until at least 2031, and option 2 means we'll have a rec by 2029, but it will pretty much just be WCAG 2. All the new things people have been hoping we'd do in WCAG 3.0 still won't be released until well into the 2030s. AGWG needs to figure out how to deliver WCAG 3.0 incrementally. Figure out which proposed solutions are most impactful and urgent, and spend the next charter getting that work into a recommendation. In the group should continue to work on things for its next charter. That way people would start to benefit from this work much sooner. |
Beta Was this translation helpful? Give feedback.
-
|
On the later comment:
I think that under-estimates the initial work that would be needed to revise the conformance model and the re-writing required for criterion that otherwise aren't changing. I.e. if we revise "web page" and add assertions; a lot of re-writing is needed across criteria. There is also the problem that picking a few assertions for the 1st round means that you might want to revise how assertions are included with the second round. Without a rounded view from a variety of assertions, we might structure it in a way that has to be revised when we add more. Not that I'm suggesting we'd add everything at once in the options outlined at the top, but we'd be aiming for a good range of things. |
Beta Was this translation helpful? Give feedback.
-
I agree with you. That's what I'm suggesting. Focus on getting the most impactful / promising work ready and combine that with WCAG 2.2 content. The new content may need to be a new section, for example after principles, have an outlines or an assertions section. Where the new content replaces existing WCAG 2.2 criteria, they can be left out. That gets you to a full spec without the problem of having no new guidelines until at least 2031.
I'm not suggesting to fully rewrite the conformance model. Precisely the opposite, I'm suggesting you don't do that. Figure out what's most impactful / promising and prioritize those. I don't agree with you that changing web page is that complex, but if that's the expectation than don't make that change. Work on other things and prepare what that new web page definition looks like for the 2029 or 2031 charter. There are quite a lot of issue opened on the conformance model that you can consider here. |
Beta Was this translation helpful? Give feedback.
-
|
Please see option 3 below. |
Beta Was this translation helpful? Give feedback.
-
|
In the past, we worked topic wise. Therefore I feel that each of the named options 1, 2, and 3 breaks with what we already achieved and the working mode we found. I feel if we go for slicing it in a way that we obtain width first (covering all topics somehow) and then going into depth like in Option 1, we on one hand set aside what we already have and in addition take away the chance to decide on the obligation level (fundamental, supplementary) in an overall context of all outcomes for one topic. When proceeding with WCAG 2 in mind (Options 2 and 3), I think we loose the out of the box achievements we already made, the benefits we gained from thinking out of the settled boxes. Therefore I suggest to slice topic-wise. agree which topics we finalize first, getting the outcomes together, defining the fundamental and supplementary outcomes and then putting together all material, prioritizing the fundamentals. This way, we one one hand can crosscheck the fundamental-to-supplementary approach while doing it on a specific scope, on the other hand we can easily work in what we did during the recent past. |
Beta Was this translation helpful? Give feedback.
-
But the impactful changes require structure changes.
The plan on the WCAG2AAA-comparable is by 2030. Some of those would be new, the rest would be equivalent to WCAG 2.
You edited the summary of Option 3 to add:
I don't see how you get to that without rewriting the conformance model. Call it an alteration or a re-write, but we cannot have asasertions in the same category as criterion in the WCAG 2 model, which means adjusting the leveling. If assertions are in their own level, and that isn't required, what's the point? The proposed model in WCAG 3 has a mechanism to encourage their usage. Overall, I think what would happen is that we start with this incremental approach, hit all the cascade and re-writing issues and end up doing option 2, but taking longer. |
Beta Was this translation helpful? Give feedback.
-
Option 3 - Incremental ApproachThis approach starts from WCAG 2.2 and incrementally addresses items issue by issue through notes, changes to groups of guidelines, limited sets of assertions, conformance updates, or other small bounded changes. Notes
Examples of small bounded changes
Phase 1 (2027)
Phase 2 (2029) and onward
|
Beta Was this translation helpful? Give feedback.
-
|
Why is the start of phase 1 suggested to be in 2027, eg two years from now, and not before that? |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, that's an "end of" date. Phase 1 ends in 2027, so it's (end of) 2025 to 2027. Our re-chartering is every two years, and the next re-charter is Oct/Nov 2025. |
Beta Was this translation helpful? Give feedback.
-
|
Ah thanks, that clarifies! |
Beta Was this translation helpful? Give feedback.
-
|
Can this incremental approach guarantee that cognitive and low vision will be prioritized and included for publication in Phase 1? |
Beta Was this translation helpful? Give feedback.
-
|
what guarantees are in phase 1 for user testing as acceptance criteria and assertions as acceptance criteria in phase 1, and less pressure on automated or widely applicable ? |
Beta Was this translation helpful? Give feedback.
-
|
There is so much bias in wcag 2. The only reason to not to strongly object to any legislation that references it is because we are working as fast as we can on WCAG 3. And Wcag 3 is designed to undo the organization discrimination in WCAG 2. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @WilcoFiers, I'm confused, the starting point for option 3 is WCAG 2.x, that's how you outlined it when we talked unless I missed something. The point of that option was to start with WCAG 2 and incrementally update. I think it is fair to point out a disadvantage of that approach. I wouldn't put it in quite the same way (I wouldn't be as harsh on WCAG2, and WCAG3 isn't going to be a miracle), but I see Lisa's point as user-advocacy. |
Beta Was this translation helpful? Give feedback.
-
That's not what I said. Rachael put that in because she felt that this was a way COGA would understand it. I don't think that's explaining the option well. It's clearly leading to even you being confused about it. I should have insisted that be changed. I apologize for the misunderstanding there. I'm not proposing we update WCAG 2 content. What I'm suggesting is we write WCAG 3 incrementally. We focus on the outcomes, assertions, and conformance questions that can have the most impact, and publish that as a recommendation by the end of the next charter. Because we want to publish a "full" recommendation, we'll need to include parts of WCAG 2 that aren't covered by the new content. We'd need to spend some time figuring out how to do that.
I don't think that's a good characterization of it. This isn't proposing to write WCAG 3 content by updating WCAG 2. WCAG 3 content is written from scratch, as we've been doing for a while now. The difference between option 3 and option 1 & 2 is that we'd use existing WCAG 2 content until we have the WCAG 3 part of it ready. There are a lot of advantages to that. Most importantly, people with disabilities can benefit from our work much sooner than they could in option 1 and 2. Instead of COGA folks having to wait until at least 2031 we can get some of it out by 2027. This also allows AGWG to react more quickly to changes in technology. You also get a shorter feedback cycle, and it's better risk management too. One particular thing not working out can't hold back all of WCAG 3 for years if you can release it incrementally. |
Beta Was this translation helpful? Give feedback.
-
|
So if I understand this (and I'm not sure), you're proposing that:
|
Beta Was this translation helpful? Give feedback.
-
Although I am also struggling a bit to understand exactly what is being proposed, @WilcoFiers, I think that this above statement is at the crux of the issue:
So in some ways, I don't care so much what is scoped for the subset. The overriding concern is to publish something solid and mature, earlier. |
Beta Was this translation helpful? Give feedback.
-
|
@mbgower (Chair-hat off) The other side of the coin, is that for each iteration:
Given that cascade effect, given that a re-structure = rewrite, and the overhead of publishing, I think the iterative process would get you to 20% change relatively quickly, but the rest would be longer than option 1 or 2. |
Beta Was this translation helpful? Give feedback.
-
|
I cant help noticing that some of these proposals are good for the business models of many of the organisations in AG and not helpful for the disabled user who are under supported in wcag 2. |
Beta Was this translation helpful? Give feedback.
-
|
if I understand it correctly the first proposal seems ok. |
Beta Was this translation helpful? Give feedback.
-
Can you please explain what you mean? Given the relatively abstract high-level options and the fact that the organizations involved in AG are diverse (everything from private businesses whose main focus is a11y to multinationals in different sectors), I don't see how any could be competitively advantageous in a demonstrable way. |
Beta Was this translation helpful? Give feedback.
-
|
oh I believe Lisa's point is that anything the group does is tainted by the fact that participants in AGWG have commercial interests, and that will always be in the way of real accessibility. which ... sure, is a take. we may as well close up shop then... |
Beta Was this translation helpful? Give feedback.
-
|
@patrickhlauke @lseeman ::chair hat off:: I think we need to balance business interests with the needs of people with disabilities. The group is made up of a mix of representatives to try to ensure that balance. I believe both questions are valid:
In order to succeed, I believe we have to answer both of these with a yes as well as produce the spec at a time where it is impactful and relevant. |
Beta Was this translation helpful? Give feedback.
-
|
I might have missed some points and this cannot be an Option, but this is another possible plan I had in mind. Option X: WCAG 2.2 into WCAG 3 format
Phase 1 (2025-2027)Target 1: WCAG 2.2 A & AA
Phase 2 (2027-2029)Target 2-1: WCAG 2.2 A & AA
Target 2-2: WCAG 2.2 AAA
Target 2-3: New requirements (Not in WCAG 2.2)
Phase 3 (2029-2031)Target 3-1: WCAG 2.2 AAA
Target 3-2: New requirements (Not in WCAG 2.2)
|
Beta Was this translation helpful? Give feedback.
-
|
@yatil We aren't writing requirements for user-agents, but it helps to differentiate between platforms if the user-agents (or just the platform) provides more access features than another platform. E.g. Text is more manipulable on the web than some other platforms, the authoring requirements could (and probably should) be different. |
Beta Was this translation helpful? Give feedback.
-
|
@alastc Okay, then I don't understand why that is an argument that it needs to be done this way. I can see the internationalization angle slightly. But in the end, WCAG should concentrate on the constituents that matter most: Disabled people and content authors. |
Beta Was this translation helpful? Give feedback.
-
|
@alastc My point is to start small by limiting the scope to web content and WCAG 2.2 A/AA and build the core structure and framework at first. |
Beta Was this translation helpful? Give feedback.
-
|
@yatil - It is to enable WCAG 3 to work better across platforms that WCAG2 is already being applied to (via the EN and/or WCAG2ICT). @MakotoUeki - I don't think we are very far apart on this. I agree that we need have a scope that is the same level of work (for us writing it, and implementors using it) as WCAG 2.2. |
Beta Was this translation helpful? Give feedback.
-
This is still the World Wide Web Consortium and other specs can have different approaches. I find it not too useful to change requirements for the most accessible platform out there to make it easier adapt to less accessible platforms. We don't write ramp criteria so that they can be more easily applied to stairs. I wonder if that's unnecessary scope creep. |
Beta Was this translation helpful? Give feedback.
-
|
@alastc I followed your hint and read through text appearance. I admit I struggle to see how this aggregation of numerous independent but also intersecting requirements could ever become one (or a small set of) testable outcome(s). See, for example, the decision tree where you find the step
must? So clearly testable whether it does? So I check the glossary and find, in the definition of "user-manipulable text":
...folllowed by no less than 11 possible attributes! With so much variability at play, how is a user of the standard ever going to decide whether text can be considered "user-manipulable"? (is that even a word?) So to put in my 2 cents, my gut feeling is that a 1:1 transposition as a first step in WCAG 3 might be a useful step. So I would tentatively support @MakotoUeki's suggestion. As to more fine-grained, foundational / supplemental requirements: This is not so different from AA /AAA and sufficient vs. advisory techniques that it could not be added to each transposed requirement. Many things in 2.2 are basically fine and just need tweaks (like „down to 320px“ in 1.4.10) rather than the melting pot treatment. And things that are new / to be added (like readability beyond size/contrast) could then be put to the test - is it reliably testable, or is it likely to remain a best practice recommendation? After a first transposition we could then earmark those SCs that should be merged because they became independent SCs for historic reasons (like 1.4.10 reflow ursurping the resize part of AAA SC 1.4.8). I think it will be less work, because we will much more quickly arrive at a structure that provisionally holds together and gives us some leverage. |
Beta Was this translation helpful? Give feedback.
-
That is very 1st draft, but the principle should be clear: Can the user manipulate the text? On the web we take this as a given, but it isn't something that can be assumed across platforms (particularly kiosk type things). WCAG 2 is missing the basics in this regard, because the assumptions are different. Text size isn't really covered in WCAG 2 because it assumes the user can adjust the size, which is now an inccorect assumption. That's the danger of a migration, the same assumptions get baked in. |
Beta Was this translation helpful? Give feedback.
-
|
@detlevhfischer I also love how this requires you to (basically) test each word separately to meet the requirements. And then there are so many decisions that it will potentially double testing time. With few actual advantages. I don’t see how anyone would use this practically. |
Beta Was this translation helpful? Give feedback.
-
|
So given the user-requirements (in the doc), what would you suggest? |
Beta Was this translation helpful? Give feedback.
-
I haven't participated in the discussion in the subgroup but it seems difficult to fit this into one decision tree that would work independent of given platform / user agent constraints, and what is doable at all in these. At cursory glance, it seems to me that some attributes are lot more important than others; the most important might be:
...while things like adjustable margins or hyphenation seem to be at the lower end of the scale. Any kind of rating should reflect that. At any rate, if WCAG 3 is to extend to things like native apps or kiosk systems, text customisation requirements will need to be a lot more finegrained than the current blunt 1.4.4 approach - 200% for ALL text (which does not account for the drawback of huge headings, or behaviour of labels in space-constrained sections like navigation bars). And it remains to be seen whether the (degree of) support for less well supported attributes can be shaped in any testable manner at all. |
Beta Was this translation helpful? Give feedback.
-
I am of the opinion that regulatory uptake (e.g., EN 301 549, 508, ADA) is determined by factors which are indifferent to WCAG versioning. I think mature parts of the contents will be incorporated into design systems and testing tools because that provides competitive advantage. On a recent call, @goodwitch mentioned that aspirational assertions, such as usability testing, can have a noticeable impact to business. From the 2013 ACAA final rule Summary of Major Provisions
This is is codified at 14 CFR 382.43(c)(2):
|
Beta Was this translation helpful? Give feedback.
-
Summary 23 June 2025We discussed Options 1-3 at the 17 June 2025 Meeting. Based on discussions on this list, we've updated slides to capture additional suggested options for discussion on 24 June 2025. These are also listed below with links to the relevant comments. Option 3 DiscussionWilco clarified that option 3 does not start from WCAG 2.x. Instead, “I’m suggesting is we write WCAG 3 incrementally. We focus on the outcomes, assertions, and conformance questions that can have the most impact, and publish that as a recommendation by the end of the next charter. Because we want to publish a "full" recommendation, we'll need to include parts of WCAG 2 that aren't covered by the new content. We'd need to spend some time figuring out how to do that…. The difference between option 3 and option 1 & 2 is that we'd use existing WCAG 2 content until we have the WCAG 3 part of it ready.” Option 4 Topic centeredI suggest to slice topic-wise. Agree which topics we finalize first, getting the outcomes together, defining the fundamental and supplementary outcomes and then putting together all material, prioritizing the fundamentals. This way, we on one hand can crosscheck the fundamental-to-supplementary approach while doing it on a specific scope, on the other hand we can easily work in what we did during the recent past. Option 5 WCAG 2.2 into WCAG 3 Format)Starts Phase 1 with WCAG 2.2 SC at Level A and AA so that the existing WCAG 2.2 SC is available in the WCAG 3 format as soon as possible. Focuses on web content at the first Phase for each Target, and then adds non-web content at the following Phase. Each Target/Scope will be completed with Mature by the end of each Phase. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @gundulaniemann, I think that we can try and apply topics to how we work whichever option we choose. It isn't always possible, and I do think we'll need to work in parallel to some degree, but we can try to arrange by topic. |
Beta Was this translation helpful? Give feedback.
-
|
What I miss from all these options discussions is a fixed, reliable schedule for Working Drafts, not limited to FPWD, and a concrete REC deadline. I think this is the second or third charter that says, “WCAG 3 will be done at some point next charter – maybe”, and if I were a W3C Member, that would not be enough for a re-charter again. |
Beta Was this translation helpful? Give feedback.
-
|
@yatil The charter lays out the goals and our timeline lays out the detailed schedule. The current charter is the first one where the working group (not a taskforce) was dedicated to WCAG 3. It does not say we will have WCAG 3 done. Part of our goals for the current charter, which this discussion supports are to:
Our current timeline aims to publish drafts every 6 months and have been doing so with only a few weeks slip. We would aim to continue publishing 2 drafts a year in any of these options. The current conversation is essentially a tradeoff discussion between scope, impact, time to any publication, and time to an adoptable publication. Once the group decides which option to move forward with, the chairs will put a timeline together. That is then linked in the charter. |
Beta Was this translation helpful? Give feedback.
-
|
Fair. |
Beta Was this translation helpful? Give feedback.
-
|
Since you are publishing the drafts as drafts. And these can always a) be used for getting feedback and b) used by those who would like to implement the new ideas we do - and even c) give us feedback from the experience of those using it as (b) ---- I think we should always say "publishing as Rec" instead of just saying "publishing". the only thing "publishing as a REC" does that the drafts do not do -- is allow it to be cited by regulators. And if we publish as a REC in pieces - they will never adopt in regulation (so there is not purpose in that ). And if we publish too often then they will tend to just "wait for the next one" Since updating a regulation is infinitely more work than publishing as a REC (and costs money) they would find that they could not get one version adopted before you came out with the next -- so they think "lets just wait til it all calms down" and just go through this regulation update once. ALSO if incomplete - then they have to require WCAG2 as well as the partial WCAG3 and that is a mess and finally, if there is anything in WCAG3 that is not in harmony with WCAG2 then you can't do WCAG2 + partial WCAG3 -- and you can't do WCAG3 replacing WCAG2 because WCAG3 is incomplete... so you end up having to ignore WCAG3 until it can replace WCAG2 anyway. BOTTOM LINE
One caveat to my last point is that we might a) get a WCAG3 out the door that covers 1 and 2 well -- it might get regulators moving and by the time they are ready we could add our WCAG3.1 tweaks and have them included. but we will need to have 1 and 2 covered well in order for regulators to take it up. AND it will need to be at a time when they are open to changing things. Key will be having it both be complete (can replace WCAG2 ) and enough better than WCAG2 that it is worth the effort., in the meantime getting good DRAFTS of key parts of WCAG3 that can supplement WCAG2 will be good progress. |
Beta Was this translation helpful? Give feedback.
-
|
Hi All, Hopefully a slightly different and useful perspective. My work is in the trenches so to speak, working with lots of orgs big and small to build accessible things. I don’t think any of my clients care much about the version number or name of the document. Beyond anything they need something that is easier to digest and use, even if it’s partial… for the gaps it doesn’t cover, they can go look at WCAG 2.x. With that in mind, i suppose a path where WCAG 3.0 is incremental. Starting small and growing often (maybe yearly?) and for anything not covered in WCAG 3, then the user is directed to WCAG 2.x… but the WCAG 2.x items are not part of the new document itself. At some point WCAG 3 then covers enough to replace WCAG 2.x. Hope this is a useful suggestion. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @JamieKnight, I guess the question (with the above options in mind) is whether it would be helpful for those increments to be transforming WCAG 2 into WCAG 3, or whether it's ok for them to be side by side until WCAG 3 is ready to replace WCAG 2? IMO the incremental transformation approach would provide something "official" earlier, but it would take longer to get to the full replacement point. That's because we'd have to cross-reference things at each iteration, and go through the publishing process at each iteration. Keeping WCAG 2 as-is, and working on WCAG 3 would be faster to get to the replacement point, but wouldn't have anything "approved" until that point. (Although drafts would be available as we went along.) |
Beta Was this translation helpful? Give feedback.
-
|
Hi @alastc, I think for my clients the second option would great. They keep up with WCAG 3 drafts as it goes and then in time it replaces WCAG 2. The name and the ‘official mess’ isn’t as critical as it being helpful and easier to use. If the stand alone 3.0 drafts are useful they will find an audience very quickly. Hope that’s useful feedback. As always I’m amazed at what you all do. This stuff is hard and complex. Lion is sending big hugs to you all for being awesome! |
Beta Was this translation helpful? Give feedback.
-
|
I am sorry to dive into this conversation so late, but I see in these discussions that some of the work of the Publications sub-group is missing, and I think some of what we discussed is worth exploration as well. We seem to be making three assumptions about the development of WCAG3 that I think may be what is steering us wrong:
In the publication sub-group, we explored a lot of different ideas for how to progress with WCAG3, and one that kept coming up was to move to a module-based publication model, where we would focus on and publish focused "modules" that would include requirements for specific accessibility topics like forms, motion, multimedia, etc. There were pros and cons, which I'll share here:
I think all of the cons can be overcome with strong editorial leadership. The pros will be significant, and we can get feedback and new specs into the hands of the community far faster. People can choose how they integrate and interact with the modules, but we can make a positive impact. |
Beta Was this translation helpful? Give feedback.
-
|
I think the feedback portion can be handled in communications. This was another area the Publication subgroup discussed, how do we get more feedback, how do we solicit it in a more useful way (tbh getting feedback at the REC stage is almost frustratingly too late because revisions are a pain). |
Beta Was this translation helpful? Give feedback.
-
Admirable. I hope that that works out. I'm pretty involved and I couldn't even make time to really look at it until last minute with WCAG 2.2. It's just very difficult to gather data from real projects. |
Beta Was this translation helpful? Give feedback.
-
|
The notes thing as well would only be for modules, I am imagining two streams more or less, modules get published as notes, as we write new/updated requirements for modules we copy those into the "main" WCAG3 rec-track document, which can be updated as a working draft when modules are published. Saves the major pain of the process currently where notes are really hard to "elevate" to the rec track, and means we'd have a fairly routine draft publishing cycle for the "main" document. |
Beta Was this translation helpful? Give feedback.
-
It sounds a lot like option 2, with Gundula's suggestion of tackling a topic at a time? I might be over-sensitive to the complications that came up in WCAG 2.1 and 2.2, even just adding criteria was really hard if you can't adjust the previous ones. Also, given that there is no perfect categorization of access-requirements, I strongly believe that each addition / update will bring with it changes to previous material. Leaving useful notes in the wake of WCAG3 development seems like a reasonable compromise, allowing enthusiastic folks to take up new guidance as soon as possible. |
Beta Was this translation helpful? Give feedback.
-
|
we publish Drafts all the time. Can people please say "Publish as a recommendation" or "Publish as a Note" or "Publish as an editors draft update" each time they use the word publish? It is hard to understand what is being proposed when the word "publish" is used alone Much of this above makes no sense if it is one type of publish rather than another. For example, if modules are being published as notes for information -- that is fine - but seems like a lot of work when the same information is in our Editors Drafts (but I guess a case could be made for an informative document if it was complete and stable) But publishing a module as a Recommendation is a lot of work with no real benefit. It won't replace anything. And no regulatory body is going to pick it up unless it has no relation to anything in WCAG2. (if it did overlap with WCAG2 then they can't say do WCAG2 and this because the collide. And they can't say do this instead of WCAG2 beause it is only a piece) So --it would be great if comments would right now I hear people advocating for things -- but not what the purpose is or why it would do that any better than our draft working docs thx |
Beta Was this translation helpful? Give feedback.
-
Summary of 24 June MeetingThe group discussed different options for approaching the rest of WCAG 3 along with pros and cons. A few key notes:
|
Beta Was this translation helpful? Give feedback.
-
|
thanks for the helpful summary. Re the last bullet: from the minutes the suggestion appears to be that we can optimise human-written content for training of LLM's. Was it also suggested we could write spec content with LLM's (as the bullet seems to say?)? |
Beta Was this translation helpful? Give feedback.
-
|
From memory, the suggestion was for both. I'm skeptical an LLM can help with writing novel content. I'm also skeptical that we can usefully write for AI, as it's such a moving target. |
Beta Was this translation helpful? Give feedback.
-
|
+1 to both points. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Below we have two possible approaches to finishing out WCAG 3. (previous presentation) Please review these and consider tradeoffs such as:
For either approach, we could stand up task forces to create notes for content that can be pulled out of WCAG 3 and stand on it’s own. The two candidates from previous conversations are the assertions and color contrast guidance.
The purpose of this discussion is to get a sense of support for each of these approaches and capture additional possible approaches.
To make this a bit easier, we have included draft dates. Please note that all dates are still tentative.
Please:
Beta Was this translation helpful? Give feedback.
All reactions