Publication Approach to WCAG 3 #33
Replies: 25 comments 90 replies
-
|
One idea discussed previously is to apply the new format of WCAG 3 to the existing WCAG 2.2 criteria. To some degree the existing requirements are going to be subsumed into WCAG 3. Is it feasible to release a 'swizzled' 2.2 that adds nothing 'new' but is migrated into the WCAG 3 Guidelines, Outcomes, Methods, and Tests format? Obviously, it's an open question about how much additional effort would be involved to do this. |
Beta Was this translation helpful? Give feedback.
-
|
We will have data to calculate a velocity in the upcoming year, and I believe that this data will be very useful in assessing our approach and determining what (if any) adjustments need to be made. |
Beta Was this translation helpful? Give feedback.
-
This assumes that WCAG 2’s foundations are not allowed to change, which… it’s the group’s standard. You can do whatever you like with it. If the group says “we remove SCs now”, boom, done. This is not a dogma. You make the rules, you can change the rules. |
Beta Was this translation helpful? Give feedback.
-
Those 15 years of knowledge didn't prevent us from having more than 2 years of delays on WCAG 2.2, which you had originally estimated was going to take 18 months. I appreciate Chuck weighing in on this. And I appreciate that he's not suggesting we already know the velocity we can get from this new process. It's great you feel optimistic about it, but optimism isn't a plan. What I think is still far more important, which I'd really like one of the chairs to respond to, is that we don't know how much work it will be to get to WCAG 2.2 parity with WCAG 3.0. Even if new tools somehow make us twice as efficient as we were a year ago (and that's a pretty big IF), that doesn't tell us that 4 years is a realistic timeline. The real problem is all those unknown unknowns that we'll end up hitting. In the past those have resulted in years of delays on other versions of WCAG. What happens if we hit those, and 3 years from now we learn it'll be at least another 3 years before we reach parity?
That's an interesting comparison. I don't think that analogy speaks in favour of taking large steps though. In machine learning smaller steps are more likely to end at a local maximum, sure. But large steps are more likely to end up with no predictive power at all. The algorithm just ends up bounding around more or less randomly. (Actually that's not a bad comparison to how WCAG 3 work feels sometimes. (that's a joke)) As Eric pointed out its our document, we can do anything we like to it if we don't have to worry about backward compatibility. But I do appreciate that in breaking the work up into increments, we could end up doing it in a way that is less optimal than if we'd done it in one big 6 - 10 year project. We've never tried this, so we really don't know. I'm not suggesting we immediately pivot the whole project. I'm suggesting we try it. Spread our risk. As project manager, that feels like my responsibility. Risk management. We shouldn't gamble the success of WCAG 3 exclusively on our ability to deliver in record time on a project with an unknown amount of work, using an unproven process. |
Beta Was this translation helpful? Give feedback.
-
|
This thread has entirely gone off its starting topic, and the only way to understand some of the sudden twists in discussion is to read all the threads.
Personally, I can't imagine a faster way to revamp the standard than this. The other two main proposals I've seen stated in threads are:
I don't see how either of these gets us more quickly to something that can be used to report compliance. The first just seems obvious to me. It's producing stuff in the same format as this proposal, but is proposing to produce MORE stuff, ergo more time. |
Beta Was this translation helpful? Give feedback.
-
|
Wilco wrote:
That is the plan (and the project plan) which you are aware of, which includes buffer time. As Chuck said, we don't know our velocity yet, but all the bits needed to get there are in the plan.
I don't think it's fair to compare progress when you are adding something to an already stable standard (e.g. focus-appearance) to migrating WCAG 2 content into WCAG 3. Until WCAG 3 gets to PR, we would be able to make fairly sweeping changes, particularly if (as is the plan) we publish the guidance early and often. The big factor for me is that changing the fundamental defintions (e.g. page, how inputs are defined/referenced) means the SCs would need re-writing anyway. Instead, we can take what we've learned in the last 15 years and put better foundations in place, which makes the job of finishing the guidelines easier. Back on topic for this thread, that local maxima idea is why I'm not keen on "reswizzle WCAG 2.x to the structure of 3.x, and release it as a transition document". Since it wouldn't be adding new criteria, a restructuring couldn't (properly) take into account future criteria. |
Beta Was this translation helpful? Give feedback.
-
|
A lot of people would feel better to know that the work they have done for 2.x will be aligned with 3.0 - so this or some sort of mapping table would be very helpful. But if we just did a straight transposition it could cause confusion in terms of what is required as 3.0 seems like it will have additional requirements. |
Beta Was this translation helpful? Give feedback.
-
|
I agree that 3.x will have additional requirements as compared to 2.x, and that a straight transposition could cause confusion. I did not read @mbgower proposal as necessarily being a MVP. We might port over only those 2.x requirements which are relatively easy to reformat, while keeping 3.x requirements already started. That could result in a strong proof of concept, but also make it straightforward to track 2.x SC which are not include with 3.x. |
Beta Was this translation helpful? Give feedback.
-
|
@mraccess77 It might be better to describe what I was suggesting as 'WCAG 2.2.1'. It doesn't change the requirements of 2.2; just the delivery. What I think is valuable in this approach is that there does not seem to be anything preventing us from adopting the structure of WCAG 3 while preserving the content of WCAG 2.x. That gives us a stepping stone to the transformation of the requirements; WCAG 2.2.1 would only require current users to learn new terminology and organization of content. That seems like a reasonable step, in which we could validate that a team reporting the same product for 2.2 and 2.2.1 would end up with the same relative conformance between the two. That could give policy makers confidence that all the new methods, outcomes, etc. in this approach form a continuum. When it comes to revamping the actual requirements (as opposed to their structure), I completely agree that some of the things @patrickhlauke is talking about make a lot of sense for 3.0 ( assessing 'input' and 'output' instead of 'mouse' or 'pointer', etc). But my sense is that it will be a lot easier to digest those kinds of changes if we are already familiar with the new organizational model. |
Beta Was this translation helpful? Give feedback.
-
WCAG Ship of Theseus proposalWhat I would love to see this group try is instead of replace WCAG 2.2 all in one go, try to do it one step at a time, and once a year release whatever is ready in a new recommendation. I personally really like the process that is TC39 uses for ECMAScript. I feel it is worth trying something similar for WCAG. The way they works is that groups of people put together proposals for changes to the standard. Those proposals go through 5 stages (0 - 4), for each stage there are criteria the proposal needs to meet. Once it enters stage 4 the proposal is accepted for release in next year's edition. ECMAScript releases every year, and uses the year as its version number. Anything like that for WCAG would have to allow non-backward compatible changes. We can't replace without that after all. Using the year as its version number seems like a good way to communicate that. So you'd get a WCAG 2025 rather than a WCAG 3. There are other possibility too. The most important part there is just to be very clear and up front about what can change, and how changes can be identified so that organizations that need to, can conform to multiple versions of the standard. Essentially, instead of asking the world to make due with the aging WCAG 2 ship for another decade while we build a new one, we should replace it one plank at a time. I know people want to dramatically improve on WCAG 2; Make it easier to read, reorganize the criteria, replace the conformance model, updated it for AI-powered assistive tech, introduce user-tested assertions, etc. I can't think why any of those things would be possible in a full rewrite but not in an iterative approach. Even if an approach like this overall would take longer (which we can't possibly know if it will), I think the advantages of this are so significant we really should figure out if this can work:
|
Beta Was this translation helpful? Give feedback.
-
|
On backward compatibility (@mbgower). I think its a compliance question. Organizations will need to comply to different versions of WCAG, just like they do now. You have a site that needs to comply to WCAG 2.0 in the US and to 2.1 in Europe. In some places it may already be 2.2. Backward compatibility is important because you don't want to have to double up on your audits to make sure you comply. If you need to conform to both WCAG 2.1 and 2.0, since WCAG 2.1 is a superset of 2.0, you only need to test for WCAG 2.1 in order to check conformance to both. If we want to release versions of WCAG that aren't supersets of the previous version, I think the way to do it is that that version identify the differences between it and its predecessor, and have a conformance model that includes either just the current version, or the version plus the previous one. I don't know what such a requirement would look like. Might just be a copy of the old SC, or maybe its a slimmed down version with just the difference. We'd have to try to see what works. If we want to avoid the inflexibility of WCAG 2's update model in WCAG 3, we're going to need to do something like that eventually. Not having an x.y version number helps communicate that, but that's far less relevant than for us to actually just figure out how we can update things more incrementally. @alastc: If we can update the conformance model to match, absolutely nothing prevents us from breaking up success criteria, shuffling them around, renaming them to outcomes, introducing decisions trees, rubrics, assertions, whatever is necessary. |
Beta Was this translation helpful? Give feedback.
-
Agreed. And it's worth nothing that despite valiant attempts at harmonization, the reality is that conformance already involves such considerations, so such a move would not be novel. Anyone trying to conform to both the EN and 508 at the moment is already managing this, since they must identify additive and differentiated requirements between the three. IBM's current requirements, which do this differentiation, have almost twice as many requirements as there are WCAG 2.1 SCs at the A/AA level. |
Beta Was this translation helpful? Give feedback.
-
|
Some thoughts with chair hat off:
I think this is good way to manage WCAG 3 after we reach a point where we have a base standard (aka enough content in a revised structure to be comparable to WCAG 2.2). I also think this is a way to improve WCAG 2 if enough people want to work on it. I do not think we can use this method to get to WCAG 3. In order to handle the rapidly changing technology landscape, we need to rework how the standards are written. We can't have a few SC written as outcomes and some not, so we have to reach a point where we have a comparable amount to WCAG 2.2 rewritten in the new outcome based structure.
I agree that we need to rethink backwards compatibility and how WCAG handles it. It may be that we redefine backwards compatibility or that we set it at a higher level than we currently have it set.
We may be able to create a note on assertions or break apart guidance and conformance but I don't think we can iterate off of WCAG 2 as a starting point for the fundamental changes. For example:
|
Beta Was this translation helpful? Give feedback.
-
I struggle to see how that can work: Once you start changing the granularity and the assmptions/definitions, you are coming up with a completely different set of guidelines. The bits you worked on would not be compatible with the bits you hadn't worked on. Plus Rachael's point about outcome based model, and how to make things technology specific (thus opening up the guidance to apply to non-websites more effectively). |
Beta Was this translation helpful? Give feedback.
-
|
Something I just thought of that I don't want to lose: If we decide to go this route, we don't have to publish at the end of the year. It might be fun (and raise awareness) to publish on Global Accessibility Awareness Day or an accessibility anniversary. That would also be good because people get swept up in the holidays at the end of the year so WCAG might get swept up and forgotten or glanced over. |
Beta Was this translation helpful? Give feedback.
-
|
with both the "can we just reorganise 2.2 SCs into an apparent 3.0 structure" and "bit by bit morph 2.2 into 3.0" approaches, I have some concerns. I think many people - myself included - have been acutely aware of some of the absolutely antiquated cruft that 2.x has had as baggage (going right back to 2.0 definitions for things like "web page", which worked well in 1999-2000, but are now showing their age and inappropriateness when it comes to the reality of modern web applications, almost 25 years later). the hope was that with 3.0, we'd have a clean slate, and a chance to avoid most of the corners we painted ourselves into (hence my strong push for a more fundamental rethink on things like keyboard/pointer to a much more holistic structuring into "input", "output", etc groupings to work on user needs/requirements). my concern is that with both those approaches outlined above, we're just (one way or another) just going to perpetuate the exact same mistakes and be tied down by them before we even properly start to work out what the actual shape of 3.0 should/could be... |
Beta Was this translation helpful? Give feedback.
-
|
though i have to say, out of the two, i'd be much more comfortable with Wilco's proposal, which essentially jettisons the backwards compatibility shackles we've had (which forced us in some cases to build ever more elaborate "patches" on top of fundamentally inadquate/outdated SCs, and always in an additive way, rather than being able to make needed fundamental fixes instead). then, we can just abandon the concept of the big "WCAG 3.0" revolutionary step, and instead accept that WCAG will be a living and evolving standard instead (though some changes will then be much harder to institute, such as fundamental restructurings) |
Beta Was this translation helpful? Give feedback.
-
|
I think we need a better compromise between on the one side people who feel a full rewrite is the only way we can fix the problems with WCAG 2, and on the other side people who are worried about how time consuming and costly a completely new WCAG will be. That's what I'm hoping my suggestion could do; Yes we can rewrite the whole thing, but we'll do it incrementally to avoid the problems and risks of not having any improvements to WCAG for the foreseeable future. |
Beta Was this translation helpful? Give feedback.
-
|
By this do you mean using 2.2 as a start and incrementally rewriting that, or incrementally publishing what we have of 3? |
Beta Was this translation helpful? Give feedback.
-
|
I think @patrickhlauke's point (about user/functional needs) needs serious consideration, and that @WilcoFiers also makes a very good point. If we get the user/functional needs bit right it will increase the longevity of 3.0 (because although technology often changes, user needs rarely do). If we couple that with a regular release cycle, we end up with a set of guidelines that can adapt and evolve in response to changes in technology. |
Beta Was this translation helpful? Give feedback.
-
|
@u9000-Nine I mean we start from WCAG 2.2 and rewrite it in steps. Each year whatever was finished in the last 12 months goes into another recommendation. We incrementally replacing more and more parts of WCAG 2.2. I agree with @LJWatson that everything new we write needs to be based on functional needs. If we try this approach I feel that needs to be part of the acceptance criteria. Along with it needing to be based on research, reliably testable, etc. We'd have to figure out what those criteria are. |
Beta Was this translation helpful? Give feedback.
-
|
Folks, when responding to a comment, use the reply instead of starting another thread. Keeps things organised. Thank you 😄 |
Beta Was this translation helpful? Give feedback.
-
|
+1. But for +1 are we favoring the "up vote" or "thumbs up" feature? |
Beta Was this translation helpful? Give feedback.
-
|
(You can also always check if you forget by typing in |
Beta Was this translation helpful? Give feedback.
-
|
Two thoughts
1). I think that releasing a 3.anythign that only has 2.2 in it would be misleading and very controversial
2). Instead I think we should think about how we want to do 3.0 structurally — in detail
If we know - we should do a few example provisions showing how all the pieces would fit together
If we have a couple different thoughts we should do the set for each different approach
This will take a bit of time — but it is the only way to see what it might look like
(When I proposed moving the POUR organization in w2 Ben Caldwell and I redid the entire set of guidelines in the new format to be sure it would work. It was a LOT of work —but it made it easy for the group to decide between approaches.
Lot of things sound like good ideas until you try to implement them
… On Nov 7, 2023, at 4:18 PM, Léonie Watson ***@***.***> wrote:
I think @patrickhlauke <https://github.com/patrickhlauke>'s point (about user/functional needs) needs serious consideration, and that @WilcoFiers <https://github.com/WilcoFiers> also makes a very good point.
If we get the user/functional needs bit right it will increase the longevity of 3.0 (because although technology often changes, user needs rarely do). If we couple that with a regular release cycle, we end up with a set of guidelines that can adapt and evolve in response to changes in technology.
—
Reply to this email directly, view it on GitHub <#33 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXXCXUT2H52DYNDYCI3YDK6T3AVCNFSM6AAAAAA7ADDMFGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TKMBUGI4TE>.
You are receiving this because you are subscribed to this thread.
|
Beta Was this translation helpful? Give feedback.
-
|
Wilco - I’m not sure how many are ready to acknowledge the time it will take. Everyone wants it sooner. But I think your comments are very accurate.
OH - and this does not take into account that I think AI and other advances will change AT in major ways - that will require us to rethink some of 2.2. MOSTLY they are written to account for advances but not all.
And if someone(s) making browsers put some of that AI into the browsers - or made it an easy add on - what authors may have to do may be greatly reduced since the browers would do much of it for them. Sort of the way 4.1.1 was needed until AT and Browsers interacted differently - an then it wasn’t. But on a whole new level. What if Browsers “repaired” all pages that had heading with no markup and tables with no markup so that what was presented to at was all properly marked up HTML. The “programmatically determined” would be met for all AT (but it would not be done by authors but by the browser)….
This is very possible - and I think before we can get 3.0 out.
There are also things that can’t be required today by authors in the cognitive, language, and learning disabilities area that I think we can solve with intelligent helpful browsers….
Just something to think about
… On Nov 8, 2023, at 9:14 AM, Wilco Fiers ***@***.***> wrote:
It took almost 10 years to rewrite WCAG 1 to WCAG 2. Writing just the 8 new success criteria of WCAG 2.2 took 4 years. I can't see how this group would be able to do this in under 6 years. I would expect 8 to 10 years is more likely, and at the end of it we wouldn't have tackled any of the quite urgent issues that many of us are so eager to work on.
—
Reply to this email directly, view it on GitHub <#33 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXRB2Z3K4KIDLDNMRNLYDOVVVAVCNFSM6AAAAAA7ADDMFGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TKMJSGYZDE>.
You are receiving this because you commented.
|
Beta Was this translation helpful? Give feedback.
-
|
I like the idea brought up in #18 of pushing out minor levels (n.m) and then bundling them into a WCAG 3 release once we're fully done. This would allow us to get new recommendations out to developers even if we haven't finished the entire WCAG 3 yet. No matter which option we choose, though, I think this question is critical because if we publish in 10 years we won't have kept up the technology improvements. |
Beta Was this translation helpful? Give feedback.
-
|
To me, the hardest bit of creating the guidelines is that, when taken as a whole, is it reasonable to ask people/organisations to accomplish all this? The balance between user-requirement and feasibiltiy is the really tricky bit. It isn't that hard (although very time consuming) to create guidelines for meeting user-requirements. It's harder to create tests. But it's really hard to create one package and say to everyone: "you need to do all this". The time needed to get to that point in WCAG 3, where it is a replacement for WCAG 2, is probably about 4 years (plus/minus one), IF, and only IF it is the main focus and we don't get drawn into other work. To break that down more, and get "something useful" out earlier, I'd propose that we have two streams of work:
The guidelines can be published quarterly, or even just as an ongoing thing as they increase in maturity. It wouldn't be easy, I find it hard to write guideline content without knowing how it's going to fit into a model, but I think that's the most possible of the options. The point at which WCAG3 has sufficient coverage and a means of conforming is when it reaches the 1.0 (or 3.0) state. I think that has most of the advantages that Wilco outlined above as well. |
Beta Was this translation helpful? Give feedback.
-
|
I agree with focusing on WCAG 3 (my thoughts on timing are at #33 (reply in thread)) though I think we should aim for 4 years and anticipate a year or so slip. I think in addition to creating conformance agnostic guidance and a conformance model, we should consider publishing a Note on assertions within this charter period that could be used as a supplement to WCAG 2 but would also move WCAG 3 forward. |
Beta Was this translation helpful? Give feedback.
-
|
I agree with Alastair's concern about 'But it's really hard to create one package and say to everyone: "you need to do all this".' One approach that was proposed years ago (so unfortunately, I can't remember where it came from) is to have a small set of "you must do this", but then a large set of guidance where we say you must "do xx% of this". It allows levels (bronze, silver, gold) that have different xx% amounts. It gives the flexibility to have requirements that actually apply to the project being evaluated and gives organizations that want to do a better job with accessibility the guidance and recognition that they are working toward it. |
Beta Was this translation helpful? Give feedback.
-
|
You still need to meet 100% of Bronze level to meet that level. That's equivalent to meeting 100% of A or AA. It's just new names for stuff. And we gain nothing when we say 85% of images need to have alternative texts because then we're hustling always counting images, it's a huge burden and does not make the web more accessible. The issue of web accessibility is not the guidelines and that there are requirements. The issue is inconsistency with AT, requirements that are hard to learn and implement, and that all the responsibility is shifted to developers. Why don't have browser dev tools accessibility tooling that works by default? Why do you need three pages of explanations for every SC? Those are the issues that make it hard to impossible to reach developers. Nobody cares about WCAG, people care about the accessibility of their stuff. WCAG is only a tool, and the wording and structure does not matter if it is unnecessarily hard to follow the guidelines and SCs. Build a WCAG-EM for any bronze/silver/gold processes. That all should not matter for the user needs and for what needs to be done. |
Beta Was this translation helpful? Give feedback.
-
Summary 28 November 2023The options discussed are listed below and in comments which we encourage you to thumbs up (+1), thumbs down (-1), or eyes (0) the comments before the meeting:
Part of the conversation focused on how long it would take to write WCAG 3. The Chairs believe we will have a better idea of our velocity in a few months as we have only just started using our new process, so we will being this part of the conversation to the group in a few months when we have more data. (Thread of timing conversation) Part of the discussion was on creating a mapping table between WCAG 2.2 and WCAG 3. Chairs believe this should be part of the final deliverable but wouldn’t occur until WCAG 3 is (almost) ready for adoption.(comment on mapping) |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
WCAG should use modules, like CSS does. Eventually these modules could then come together into a numbered version (be it date numbered or version numbered). Consider splitting the spec up into two parts: Guidelines that formulate squishy best practices (“make text easy to read”) and tests (basically what is the SCs now). Testers and implementers have different needs, but we see over and over again that implementers take WCAG SCs as targets. Consider removing AAA criteria (put them in the modules and incubate them into more practical criteria that can make the cut). Consider removing the distinctions between A and AA criteria. It’s rarely used in practice, not clearly defined, and only adds another level of structure to the guidelines without a tangible benefit. Many AA criteria that were AA in WCAG 2.0 times should now be A criteria. I have talked and written about the evolution of WCAG that is needed (and not the revolution that is aspirational but unknown) several times over the years.
I hope the working group finds a way forward that builds on the foundation that we have, and addresses the issues that are apparent. We have 15 years of experience finding all the weirdness in WCAG 2. Addressing them seems to me a better use of time than creating a new specification that potentially has many unknown unknowns. |
Beta Was this translation helpful? Give feedback.
-
|
There are aspects of this that I don't agree with but I think a modular approach has potential. (Chair hat off) One question with a modular approach is how to divide the modules and then later combine them in order to present inter-related outcomes and tests together. This is something that the group has noted as important to make it more apparent how different pieces interrelate and encourage designers and developers to go beyond the bare minimum. (Chair hat on) |
Beta Was this translation helpful? Give feedback.
-
|
A couple of thoughts (chair hat off): I'm not sure how a modular set of requirements would work for regs/legal use? If we split up requirements for different groups (or interface types, or whatever categorisation) so they are at different levels of maturity/completness I think we'd be open to critisism. Splitting by baseline / best-pratices is inevitable, it's just how we prioritise working on the best-practice aspects and how we present them. We do have 15 years of finding all the "weidness" in WCAG 2. What we find is that updating WCAG 2.x (with it's current assumptions and restrictions) makes change harder than re-structuring things from scratch. As soon as you update concepts like 'page', or how inputs are described, it ripples out across everything. You spend more time managing the changes than improving the docs. We can of course use & migrate things from WCAG 2.x, but as soon as you change the foundations you have to re-structure, re-formulate, and adjust everything. |
Beta Was this translation helpful? Give feedback.
-
That way:
Don't do that. |
Beta Was this translation helpful? Give feedback.
-
|
Replying in this thread, because I think it strongly aligns with some thoughts that popped up. I see there's a lot written and said already. I hope I can add something to this conversation nonetheless. 🤞🏿 Starting with the original question:
👏🏿 I think we can conclude from all versions of WCAG so far: things can take a while. Development has been quite monolithic. The idea to break things apart is "trendy" in a way, but I like it a lot. I enjoy iteration. I prefer lots of small steps over few big steps. Just like I prefer small mistakes with little damage over big mistakes with more catastrophic impact. I think it's "the thing" in many fields these days: iteration, working agile, micro commits, components, etc. There are a lot more examples than I can mention here. All aimed at avoiding monoliths. 1️⃣ So yes, break it apart! All for it! But how? I think a more modular approach would be fitting. Don't release a whole new version. Release modules that follow the WCAG3 procedure or way of work. 2️⃣ Then start working on a module. I don't know how these should be split or categorized. I think that's a practical question beyond the initial structure I'm coming up with here. But maybe it's based on the type of content. Maybe there should be a module for time-based media. And a group of people start working on that; a team of people with specialists. Multiple smaller groups can go more in-depth while moving faster than a big all-encompassing group like currently. (Modules could also be structured to benefit specific groups of people with disabilties. I think that can be hard to categorize, and there's lots of overlap) 🔢 At some point another group of people starts working on another module. And another. One might be published before the other. Some move quick. Some move slow. Some might get a second version before another gets its first. Maybe a module stays in "beta" for a while, because of lots of debate and feedback? A module might be an evolution of some WCAG 2.2 criteria. Another is entirely new. And maybe after several modules and versions, new modules are thought up. And while these modules get developed, they give continuous feedback to the "core group". Ways of working can be improved by experience. Glossaries can be extended and shared. Needs for modules can arrise. 📝 Trying to summarize this unstructured train of thought:
🙋🏿 How does that work with compliance? 🏁 |
Beta Was this translation helpful? Give feedback.
-
|
It's remarkably difficult to follow the threads of this discussion, so apologies if this has been said already and I missed it, but I fear we're over-thinking this. One of the biggest problems with 2.x is that it's framed around technologies not people, and where technologies change, people tend not to so much. If we start by extracting the functional user requirements that are implicit in 2.x, then create new ones to close any immediately obvious gaps, we'll have an initial set of requirements (AKA "guidelines") to use as a framework. For example:
We could then document the common circumstances in which each functional user requirement is relevant. Continuing the example:
We use this as the definition of done for the next step, which is to write conformance objectives covering each of the common circumstances. For example:
NOTE: these examples are illustrative, please don't let's get into the weeds of the words! When we have conformance objectives for all of the common circumstances for each functional user requirement, we should have a critical mass that will let us define an appropriate conformance model. When we have a conformance model, and conformance objectives for all the common circumstances for each of the initial set of functional user requirements, we'd be in good shape to go to Rec (for the first time). As/when we want to add new functional user requirements, we rinse and repeat the above steps. As/when we want to add new/more common circumstances and conformance objectives, we do so until we have enough to justify updating the Rec. |
Beta Was this translation helpful? Give feedback.
-
|
I agree that we should start with user needs - and use user needs to check our work throughout but I'm not sure I follow what you mean by "we should structure by user needs while WCAG 2.x did not. WCAG 2.0 is all about user needs its overall organization is that users (all users) need to perceive, operate, and understand content - and have it work with their assistive technologies today and tomorrow (Robust). It then provides general advice on different things that must be true for different people with different disabilities to be able to do this. these are then (and only then) broken down into testable things that must be true of the content -- all of which are independent of devices or technologies. so this is user need based. using different user needs as a way to explore whether we have them covered is a great idea. Organizing WCAG by them would not work. Best |
Beta Was this translation helpful? Give feedback.
-
|
Hi Gregg, I understood Léonie's comment to mean the structure of the 2.x guidelines is based around the 'content' (which from a certain perspective is the technological thing that is presented to you).
Maybe, but we're going down that route and it doesn't appear to be a problem. If and when we get redundant requirments under different guidelines we can list them in two places (linking to one outcome or method), or work out another way of removing the redundancy. When Léonie said:
That is pretty much what we are doing now... |
Beta Was this translation helpful? Give feedback.
-
|
yes My comment was that when we do the final organization - if we do it by disability many provisions will apply to many disabilities so would need to be repeated. Perhaps we are falling into the trap Léonie warned us against -- getting lost in the weeds of wording. Even in WCAG 2.x if you look closely you will see that when dividing things even by generic user need (POUR) we have things in P that would also qualify under O and U and vice versa. |
Beta Was this translation helpful? Give feedback.
-
|
I think this is an interesting question as there will always be overlapping techniques that address various user needs. WCAG 2 strikes a balance of having very broad principles that generally make sense. I think broad categories are more useful or at least less restricting than precise categories. Perfection cannot be the enemy of the good here. |
Beta Was this translation helpful? Give feedback.
-
A Tale of Two WCAGsAs documents, the bottom-up approach of WCAG 2.x and the top-down approach of WCAG 3 create an inherent incompatibility. This not necessarily a bad thing, but a year ago, WCAG 3 started nearly from scratch again, throwing into question when it will arrive. In the meantime there are pressing issues, including existing weaknesses in WCAG 2.x and rapidly emerging technologies. These must be addressed sooner rather than later to maintain relevance. 1) WCAG 3 should not be abandonedThe top-down approach of WCAG 3 embodies substantial improvements, such as the focus-first on user needs. The fact that there may be developmental issues is because it is an ambitious undertaking. That something is difficult or taking time to develop is not a reason to abandon. The existence of internal/external political issues is also not a reason to abandon. 2) WCAG 3 should not "absorb" WCAG 2.xWCAG 2.x and 3.0 are different enough in approach and structure that it would be a mistake to attempt to shove WCAG 2 SCs directly into WCAG 3 in the name of expedience. Certainly, an equivalent coverage is needed, but that does not require a forced one-to-one relationship of 2.x SCs to 3.0 needs/outcomes. 3) WCAG 2.x should increment on a separate trackRather than push WCAG 2.x SCs into 3.0, it makes more sense to increment WCAG 2.x, in some cases including a version of mature WCAG 3.x guidelines. This allow WCAG 2.x to evolve at its own pace, and even provide an early test-bed for WCAG 3 concepts, while still promoting a current, relevant guideline. A few needed changes to support this are largely administrative, such as document name and semantic versioning considerations. The idea of a 2.3 has been floated by others before, and it's worth revisiting. WAG the DogThis leads us to the topic of WCAG 2.x and separate WCAG 3. Among the challenges here are semantic versioning and backwards compatibility, which is presently blocked by a naming/initialism issue, which itself has been the source of confusion for the public. 4) WCAG 3 ⇨ WAG OneI know I am not the only one who feels that WCAG 2, the Web Content Accessibility Guidelines, is confusing relative to WCAG 3 being the W3C Accessibility Guidelines.
5) Remove Backwards Compatiblity MandatesA backwards compatible mandate the way it is considered for WCAG 2 is untenable in this field of emerging technologies. Particularly when forward compatibility is the greater concern, and forward compatibility is not at all available here. I.e. if forward compatibility breaks, why is there concern regarding backwards compatibility?
CLICK for deeper discussion regarding backwards/forwards▼ ▼ ▼ ▼ ▼
In the common understanding of back/fore compatibility:
Of these, it is forwards compatibility for documents that is most important, so that all legacy documents can be accessed; Why should WCAG be different? Users/companies/sites tend to have one major version of software, but many legacy versions of documents. Does this require a flag to be set as to the conformed version? For sites that have varying/multiple conformance/compliance versions? Two ways to fix this, that also promote upgrades and forward movement following technology.
<meta name="access" content="wcag-2.3" http-equiv="content-type" />Semantic Versioning: ▲ ▲ ▲ ▲ ▲ 6) Semantic Versioning for WCAG 2.xThe established means to "break" backwards compatiblity is with standard semantic versioning, MAJOR.Minor.patch, where incrementing MAJOR indicates a break in backward compatibility, and in the case of WCAG, a Minor version increment here would be expected to break a forward compatibility (as established). A patch increment shouldn't break anything. 7) Optional HEAD ID (all)A flag in the page/view head that indicates the conformance target(s) for automated testing. <meta name="access" content="wcag-2.3" />The added benefit here is that it defines the set of SCs/guidelines the page was designed around/for. They should be stackable if the content satisfies each of the sets. <meta name="access" content="wcag-2.3" />
<meta name="access" content="en-301-549" />
<meta name="access" content="wag-one" />Summary
|
Beta Was this translation helpful? Give feedback.
-
|
Putting the naming aspects to one side and focusing on what the groups work would be, I'm intertpreting this proposal to mean: Split work between WCAG 2.x and 3:
|
Beta Was this translation helpful? Give feedback.
-
|
Hi Alastair @alastc Yes, but also this:
This doesn't mean that WCAG 3 shouldn't have similar coverage—far from it—it just means/recognizes that the fundamentals of 2 vs 3 are unique enough that such a brute-forced merging will be counter productive. And
If I didn't mention it, any continued work on 2.x should have separate leadership from work on 3, to the extent that it might be useful to split AGWG into two working groups to acheive a more objetive outlook for each. Continued work on 2.x presents a conflict with work on 3, if conducted by the same leads/team. |
Beta Was this translation helpful? Give feedback.
-
|
My thoughts:
- please do not split the working group into these two tracks, 2.x and 3,
again - this is a distraction has lead to the stalemate we have found
ourselves in for too long
- releasing 3 as only a re-statement of 2, without any new content, seems a
very weak product for a technical standards specification - even for one
that has most always tried to provide solutions for user needs
- modularization may appear practical in ITC space but does not represent a
clear comprehensive specification that can be referenced in regulation space
My thoughts here are not new and it may be that my view is what is stale.
…On Mon, Dec 4, 2023, 12:59 PM Alastair Campbell ***@***.***> wrote:
Wilco wrote:
we don't know how much work it will be to get to WCAG 2.2 parity with WCAG
3.0...
That is the plan (and the project plan) which you are aware of, which
includes buffer time. As Chuck said, we don't know our velocity yet, but
all the bits needed to get there are in the plan.
The real problem is all those unknown unknowns that we'll end up hitting.
In the past those have resulted in years of delays on other versions of
WCAG.
I don't think it's fair to compare progress when you are adding something
to an already stable standard (e.g. focus-appearance) to migrating WCAG 2
content into WCAG 3. Until WCAG 3 gets to PR, we would be able to make
fairly sweeping changes, particularly if (as is the plan) we publish the
guidance early and often.
The big factor for me is that changing the fundamental defintions (e.g.
page, how inputs are defined/referenced) means the SCs would need
re-writing anyway. Instead, we can take what we've learned in the last 15
years and put better foundations in place, which makes the job of finishing
the guidelines easier.
Back on topic for this thread, that local maxima idea is why I'm not keen
on "reswizzle WCAG 2.x to the structure of 3.x, and release it as a
transition document". Since it wouldn't be adding new criteria, a
restructuring couldn't (properly) take into account future criteria.
—
Reply to this email directly, view it on GitHub
<#33 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABL6VSQQZBP2T5DTJINRC7DYHYFQXAVCNFSM6AAAAAA7ADDMFGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TONJWGA4TO>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
Hence, modules would be combined into a comprehensive specification at milestones. Imagine two new or updated SCs every year instead of 8 at once every five years. And therefore that means that ideas that “miss the boat” do not need to wait for another 5 years until they can get into the standard. Plus, as the modules are individual deliverables, that will at some point be added to WCAG, regulation could say WCAG 2027 plus modules already released in 2028. I found the presentation from the CSS WG in Lyon super insightful, and I think more accessibility people should see it. It shows how it can work where you have many more modules and a much more complex standard.
I agree that this feels like a pointless exercise. Either WCAG 2 is good, and we can build on top of it, or it is bad, and we must have something new.
Also agreed, the AGWG has been underresourced and overworked for a long time. And splitting the attention into two did not help. That’s IMHO also one of the biggest points for a WCAG 2.2 evolution. People know it and can work with it. Changing the approach completely means for many starting from a disadvantageous position. Plus, WCAG 2.2 does not go away. It will hang around for a long time, so “committing to WCAG 3” means splitting attention at least somewhat. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @Ryladog
I agree in that having one working group and one leadership attempting to handle both 2.x and 3 is counter productive, which is why I mentioned the need for separate leadership and separated groups for each. Both could be under WAI, but AGWG for 2.x and then a new separate NSWG—New Standards Working Group for 3. And importantly, separate leadership & project management for both. |
Beta Was this translation helpful? Give feedback.
-
Summary 9 January 2024 meetingWe spent the meeting exploring options.
Outstanding questions
Outstanding questions
Both approaches need work to clarify exactly when something is in a state to be picked up by lawmakers and how updates/modules could be layered onto WCAG 2 (replace, supplement, etc?). One suggestion to explore was managing conformance at a smaller level than overall. |
Beta Was this translation helpful? Give feedback.
-
|
(Chair hat off) Say that today is point A in our timeline. Point B in the timeline is where the current WCAG3 approach would get to something we agree is ready to replace WCAG 2.2. I think it would take a lot longer to get to point B with the one-step-at-a-time approach, for one main reason:
If you have to publish every year, the whole has to to be consistent, and you'll be spending at least half the time making everything else in a new version consisent with the change you are making that year. Whereas if everything is in draft until the whole is ready, you can make larger changes more easily, not worry too-much about the whole, make other large changes, then make the whole consistent when all the peices are approaching ready. Overall, I agree with the incremental update approach, I'd just like to start that approach from a different place! |
Beta Was this translation helpful? Give feedback.
-
|
@alastc I have similar concerns. During the call, several people expressed concerns about annual releases to be too frequent for users of the standard, including designers/developers and policy makers. In addition to the consistency overhead you describe, I think there is also process overhead -- W3C publications are hard and require a lot of effort. We would spend 2-3 months of the year on the publication process rather than on updating the content, which seems quite wasteful to me. I wonder if we can redefine "publish every year" to mean "close work on particular items" as opposed to "publish as formal W3C standard". Maybe there is an opportunity for a version between 2.2 and 3.0 but I currently don't understand the benefit of an annual/living standard in the context of WCAG. I do, however, like the incremental update approach based on a backlog of issues and time-boxed iterations. We can decide to not formally publish a W3C standard after each annual iteration. |
Beta Was this translation helpful? Give feedback.
-
|
Can anyone talk to the CSS WG who is already working in a modular way to see how they do it? (FWIW they do not publish yearly, but their modules need to be consistent as well.) The nice thing of doing yearly summaries is that you take all modules that have been completed and put them into one document, which you label “2025”. The modules have all gone through review stages and the process, a process which, of course, includes checking and addressing incompatibilities with other modules. But there would be no additional publication process needed. Because the publication process has already happened for each module completed after the 2024 edition. And just to say this again, the yearly editions are a concession to the “what would become legislation” crowd (which has a point). For any practitioner, you would just add modules as they finish to your process. We do that with current WCAG SCs all the time. Finished looking 2.1 SCs went into consideration (as best practices) in 2.0 audits long before 2.1 was finished. This was harder with 2.2 because it was changed until last minute. |
Beta Was this translation helpful? Give feedback.
-
I'd be happy to, but I'm skeptical we could use a similar approach, the scenarios are different. Examples: They are working with several implementations (browsers), rather than millions of authors. They have a backwards compatibility requirement, but we're looking to break that. If new CSS doesn't get used it doesn't cause any extra work for the site developers, but extra requirements create work for everyone.
The inter-dependancies are difficult in WCAG 2.x now, adjusting definitions or even SCs is tricky as there are assumptions built into other SCs that rely on them (e.g. for coverage). |
Beta Was this translation helpful? Give feedback.
-
|
I agree with the timescale concerns in regards to replacing 2.2 one step at a time, but I do find the idea of starting with areas 2.2 does not cover/does not cover well first compelling. Tackling the sections that are the hardest first might help us solidify our processes ahead of the sections that are generally well-defined. I don't want to dismiss the valid concerns of the legislation perspective, but I think from a practitioner perspective, having a yearly summary of new modules that are delivered at the same time would be beneficial. We should be mindful that new modules shouldn't completely invalidate existing standards, or if they do, call those differences out, but I think it's a mistake to hold back valuable new recommendations out of concern for legislation. It's fully possible to keep one eye on legal standards whilst also focusing on genuine improvements to accessibility. Having a yearly publication schedule creates a really good opportunity for setting up a feedback loop with industry outside of standards. Much like people expect and plan around yearly software releases, they can do so for a yearly WCAG mini-update. That feedback cycle could allow us to improve already-published modules in preparation for the inevitable full release of the version that legislation would use. |
Beta Was this translation helpful? Give feedback.
-
Summary 16th Jan 2024 meetingIn the last meeting we had a good discussion of the options. There seem to be 4 main questions to resolve in order to progress. The statements below are phrased to provide the ability to agree/disagree, so you can thumbs up/down. The are listed below and in comments which we encourage you to thumbs up (+1), thumbs down (-1), or eyes (0) the comments before the meeting. You may need to 'show more comments' under this message to see the individual items.
NOTE: To vote, expand the comments using "Show X previous replies" and add a thumbs up or thumbs down to the first 4 comments from Alastair. |
Beta Was this translation helpful? Give feedback.
-
|
Legislators, having a lot going on beyond a11y, will tend toward adopting "the thing to fill an immediate need" that they feel they can reasonably point to as being "pre-vetted" by someone, somewhere. That said, most standards orgs divide things up into fairly granular chunks, with each chunk usually being narrow and of high specificity. As for how to divide: some considerations include the amount of dependency among different chunks and relatedness to a specific feature/task. Legislators on the other hand would rather there be a one-stop "oh hey this checks off all the boxes" solution. Among other things, it makes writing statutes much easier. None of this is to suggest that a voluntary guideline such as WCAG 2 should be elevated to statute law—it arguably should not—but I'll reserve my further comments about such inappropiate copy-into-law by expedient legislators for another day. |
Beta Was this translation helpful? Give feedback.
-
That's kinda what I wrote above, isn't it? |
Beta Was this translation helpful? Give feedback.
-
|
(I don't know how to thumbs up/down individual questions) On Q2, I don't think we can afford to put conformance aside for a couple of years. In a previous call, the chairs suggested the Evaluation Criteria for Conformance Models as a consideration for assessing WCAG. Whatever we score on any of the listed criteria, we currently score 0 on validity and sensitivity -- any one error on an entire website means the website does not conform, regardless of the actual impact of that error. This does not reflect reality. Accessibility is not a yes/no and not all accessibility barriers are equal. It only leads to headings such as 96.3% of the top million websites are inaccessible, which seriously hurts the credibility and acceptance of WCAG. We can keep rewriting the guidelines (or adding as many new ones as we like) but I don't think this will improve accessibility as much as finding a conformance model that better reflects reality. It should reward good practice and motivate people doing accessibility. Right now people tend to get overwhelmed and frustrated by scoring 0 even for minor issues, and having all their efforts towards accessibility not being adequately recognized. |
Beta Was this translation helpful? Give feedback.
-
|
(FWIW, the linked website does not have the heading ”96.3% of the top million websites are inaccessible”, and I don’t think quoting misleading article headlines as evidence is useful. WebAIM says “96.3% of home pages had detected WCAG 2 failures!”) I’m strictly opposed to a conformance model that makes us bookkeepers, counting images, for example, because 85% of accessible is good enough, but 84% is bad. I think pass/fail criteria can be an asset when they are granular and specific. Some WCAG SCs are, some are not. |
Beta Was this translation helpful? Give feedback.
-
|
doesn't "96.3% of home pages had detected WCAG 2 failures!" mean that they don't meet WCAG conformance, which is generally used to define accessibility? In any case, I'm definitely not suggesting a high complexity model with endless counting of images and other page structures (which would also open the doors for number games). I feel we can do better than yes/no, even if it's non-normative guidance accompanying WCAG, and I don't think this is less important/timely than rewriting existing guidelines. |
Beta Was this translation helpful? Give feedback.
-
Each question is repeated as a comment directly below the summary so you can give it a thumbs up or thumbs down. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, now I see them! For everyone with similar issues: GitHub might be hiding these comments under a "show more" link. |
Beta Was this translation helpful? Give feedback.
-
|
The full explanation is long, unpacking what I think are our goals, and how that influences the way we work toward them. Even the TL;DR: may be a bit philosophical for some, but I encourage you to read at least that: TL;DR:
The long story: I see our work serving 3 different goals, and I have in mind a prioritisation of them:
This is pretty core, and really important. Because the world is complex, in many cases different approaches depend on each other in practice, but I think it is really important that we continue to identify problems that can arise and explain the various ways to fix them, and how to avoid that causing other problems. For those who are aiming to resolve accessibility problems, this kind of guidance is crucial. This community has long been "The Reference". Note that this isn't just about the guidelines - the WAI IG forum is a place where people deal with the realities they are facing and how to manage them, but that is heavily informed by the work on Guidelines - and should be informing that work. Participation by various people in both groups is important in that regard, and I am glad that it happens. (Same applies to the work in APA, and work on ARIA, IMHO).
This is almost as important, although it is sometimes mis-used by people who want to claim accessibility by reaching some recognised level with a minimum possible cost - rather than actually make sure they have solved all the problems they can. This is also what makes WCAG a technical specification, rather than just a collection of knowledge that people can use as they see fit. Setting up conformance levels involves making decisions that prioritise some things over others. For example, should we move towards "perfect" accessibility, or towards making it easier for people who only care about risk management to decide that they will reach a conformance level that we know leaves some people facing still real barriers? The fact that we make such trade-offs in this aspect of the work is why it isn' the most critical part.
This is real, and has value in so far as it motivates people to make accessibility better. But different places and organisations have different approaches to how they do this, and different tolerances for how much accessibility they think is required. Related to the trade-offs we make in setting conformance levels, there is always pressure on this group to match its work to some organisation's intended use, whether a government or a company. I think it's really harmful for us to focus too heavily on this. As well as the technical trade-offs in setting conformance levels it puts us in the position of making what amount to political decisions over whose needs matter or don't. Explanation and History: This thinking is based on concrete experience, starting from pressure on WAI in the 1990s to produce simple minimal requirements that closely suited the needs of the US government as it then understood them. Instead of that being our primary goal, we aimed at fulfilling the goal of describing everything that we could work out about how to remove barriers, and then trying to sort it into some sort of conformance levels for convenience. The US government put a lot of effort into requiring a particular subset of that as "section 508". Meanwhile other governments such as Australia set much more flexible and higher bars for what was required, using the overall knowledge represented by our work as a reference for deciding in any given case what was reasonable based on the particular circumstances. And others set a far lower bar than the US. Overall, the last quarter-century has seen a significant increase in how many barriers have been removed on the actual Web (noting that is a moving target as new things are constantly created), and in the level of requirements expected (although those levels are still wildly different globally, and there is still a lot of work to do on the Web as a whole). Without the extensive work aiming at providing as much technical guidance as we could, I think there would have been far slower progress in the general rise in accessibility across the web. I don't think setting the bar lower meant that people moved any faster, but it would have left a lot more barriers by not providing a higher level target for those who wanted to do well. In my experience the level set by requirements is a bit better than the current average, but crucially that is based on having a target to point to. There are many different organisations, governments, companies and individuals trying to set themselves targets. A consistent set of guidance about how to meet them "all" is a very valuable tool to minimise "dead-end work" where decisions are taken that make it harder to do better in the future. Working within W3C, publishing, ... There are multiple ways to publish at W3C, with the most stable thing being a W3C Recommendation. Historically, we have made more complex process for ourselves than any other group at W3C - so the barriers to publication are primarily about us, not "W3C process". Some of the review steps are because we want to be inclusive, which is good, but some of them seem to be about managing our fear and mistrust of each other and what people will do with our work, and that is not good IMHO. We cannot stop people "misusing", or misunderstanding, our work. (I put "Misusing" in quotes because even among ourselves we have differing goals and different assumptions about what the "right" use is). To a certain extent we can make things more or less complicated or usable, but there are always trade-offs involved, and in my observation we generally continue to work on this long after we reach the point where the benefit of more work no longer justifies the effort it takes. There are no hard rules I can offer to help judge this better, but thinking about it and making it eaasier to decide we have reached "good enough for now" seems important. W3C Recommendations are useful. They provide a clear, well-understood message that their content is reasonably stable, has reasonably wide consensus that it is the best we can do for now, and it is worthwhile following. They don't have to be "complete". It is perfectly reasonable for them to identify areas that need more work in the future, especially if we make a commitment to revising them, ideally with some given time frame. (In my experience, a year or so is a good cadence). In addition, other organisations are used to working with W3C Recommendations, even when there are versions. We can't tell the world what to do, so we cannot force people to use the most recent version, but depriving the world of an earlier version when not everyone is ready to use it doesn't seem helpful to the goal of advancing the state of accessibility. Knowing that there is a later version, it also makes little sense to fix anything but seriously impactful errors in earlier versions - if people aren't ready to move to a later version, and aren't following the changes that are published in them, it seems unlikely that the effort of fixing the earlier version will make a worthwhile difference compared to making the new versions easier to adopt and implement (because they are simpler, better written, provide more value, ...) Because our audience and their work is incredibly diverse, I agree with @yatil - specifying that e.g. "84% is not good enough but 85% is" seems inappropriate in our work. We are stuck with having to provide guidance on how to decide what is good enough. The clearer that is, the more likely different people will reach the same conclusions, but in the end what is important is not that everyone agrees exactly, but that the disagreements are small enough that more energy gets spent solving problems than arguing over exactly where the boundaries of conformance are. Our audience wants guidance on everything (that they care about), immediately. They are very diverse, and so are their needs and interests. Meanwhile, there are a large number of active, talented and productive people in this community compared to most W3C Working Groups. So rather than just setting ourselves one giant enormous long-term task (produce the ultimate technical guidance on web content accessibility, which is a legitimate goal we have), we should also aim to produce things that fit together as well as we can make them do so, and publish those things as soon as we reasonable can. Each of these bits of work helps people, each bit will be taken up enthusiastically by some and ignored completely and unreasonably by others. So long as we are confident that each bit is more or less right and we can explain roughly how it fits in to the bigger goal, publishing it is a service to the community. Finally, I have said before that setting priorities for what other people should do is an exercise that isn't necessarily very valuable. People will decide what they work on, and as a group it is important for us to work out how to manage that in a way that maximises the value we produce, and helps us continually be as close to our goal as we can (however far away that is). This group is big enough to have significant disagreements, but also lucky enough to have great goodwill and thus the ability to manage them and still get a lot done. We cannot solve every problem (although that doesn't mean we should not try), and we are unlikely to achieve unanimous agreement and be good at what we do on meaningful timescales. Again, there are not obvious rules I can show about how to make specific decisions here, but being aware of the balance is IMHO helpful to the group in working out how to do as well as it can. |
Beta Was this translation helpful? Give feedback.
-
This is especially evident when looking at WCAG 1.0. There are only 14 guidelines, and many of them are phrased pretty loosely and broadly. |
Beta Was this translation helpful? Give feedback.
-
|
I think these questions (including the responses and ensuing discussion) is highlighting a core tension of WCAG (all versions). @chaals highlights some of this with the goals he mentions but I believe we need to identify where the tension is more explicitly. There are three main constituencies involved in how we currently view development of WCAG:
We all want the best experience for the end user, that's non-controversial. Where the tension seems to arise is whether WCAG should be written in a way that empowers the implementer or the regulators. We have tried to do both, keep trying to do both, and it's creating a lot of frustration. It's creating frustration because the needs of those two groups are often in opposition. Regulators need accessibility guidelines that are strictly measurable, pass/fail, and broadly applicable. Something that holds up to scrutiny without too much variability. Implementers need accessibility guidelines that are driven by user research, have room for variability, and provide clear recommendations for meeting the needs of the users. The conformance conversation we've been having is the best example of the tension, because many of the outcomes we've discussed in WCAG3 are challenging or near impossible to test. Inevitably when we run into this, it becomes a question of whether we can include it, because regulators can't use untestable requirements. If we're focused on ensuring that WCAG3 works for regulators, our first project should be finalizing the conformance model, and then we can make the outcomes conform to that model. If our focus is on the implementers, starting with outcomes/modules is the best approach, because our focus would be on writing the clearest and most comprehensive set of guidelines for making the outcome possible. Just to pre-empt any comments pointing out that implementers want testability too, they do (I do!), but it's not the goal. Testability benefits implementers only to a certain extent, and is often related to meeting legal requirements. WCAG also has many testable criteria, and that testability should be factored in, but we also know there are a lot of recommendations and guidelines we want to introduce that aren't as testable. If we want to focus on writing recommendations that improve accessibility but also satisfy regulators we will put ourselves in the bind we see in WCAG2. I think before we answer the questions, we need to determine our goals and who we are trying to impact most. We aren't going to make everyone happy. |
Beta Was this translation helpful? Give feedback.
-
My assumption from the conversations so far is that the structure should (somewhat) solve this tension. I.e. Within a guideline all the guidance should be available, with a variety of (categorised) methods for meeting the outomes. Those outcomes will be at different levels (e.g. baseline, silver, gold), and regulators can choose an appropriate level for thier region (or even better, for types of organisation within that region). E.g. Alt text could have a method that relies on automated descriptions at baseline, but a regulator might specify silver or gold level (requiring human-written alt text) for educational material. (Chair hat off) It is one of the reasons I think changing the structure is one of the key reasons to start from WCAG 3 outcomes, rather than 2.2. |
Beta Was this translation helpful? Give feedback.
-
So, in this case, WCAG 3 would allow for a lower standard than WCAG 2, right? And the group would be OK with that? My understanding was that WCAG 3 “baseline” was considered at least equivalent access to WCAG 2, not less access. (Considering the Chair hat comes off later, I just want to double-check if such a reduction of the standards has consensus or not.) |
Beta Was this translation helpful? Give feedback.
-
No, we haven't got to those decisions, it was a hypothetical example. Where we draw a line (or if we draw a line at all) will depend on a few factors. The point I was trying to make above is that if we have a better way of doing levels, we could provide hooks to regulators to acheive different things for different orgs. The current situation where a personal blog and national organisation are held to the same line is one of the reasons why it might feel "unambitious". |
Beta Was this translation helpful? Give feedback.
-
|
RE wareid one thing to add. Without regulation we have seen that accessibility guidance has had little uptake. and with regulation - it has both gotten advocates into companies and given the advocates the rationale they need to get attention in companies. And that has led to building teams and to companies doing things beyond the guidelines (at least some companies). WCAG is the force that it is because it was picked up and used by regulators. If it hadn't - it would be another accessibility note. This is one reason that COGA, that has a really excellent document on cognitive accessibility, is really pushing to have their advice made mandatory in WCAG3 - because it will then be picked up by regulators. But that requires that WCAG3 work for regulators. So Bottom line. Everything we do to make it work for regulators - is work to make it work better for user. nice post |
Beta Was this translation helpful? Give feedback.
-
|
While splitting guidance from rules does seem appealing - I do worry that it won't be practical. For example, once we get to writing the rules after the guidelines are written we will likely find that the guideline as written is problematic for a rule and then we will have to re-write guideline into a rule with differences and then we'll end up with two versions of similar content. It won't be just layers - layers would be ok - but likely other differences that would be difficult to reconcile. This could cause confusion and delays as well. |
Beta Was this translation helpful? Give feedback.
-
|
Yea - but no matter how you try to do it -- it will have to be iterative. So they will need to be written in parallel and feed back and forth informing each other |
Beta Was this translation helpful? Give feedback.
-
|
I think yes, it would need some coordination, but it might also help to make many unconscious decisions more visible. |
Beta Was this translation helpful? Give feedback.
-
So would this be "Guide W3C Accessibility Guidelines"? If we're splitting it into two documents and changing the name, I think we should have one "WCAG" (W3C Accessibility Guidelines) and one "WCAC" (W3C Accessibility Criteria) (or something similar) |
Beta Was this translation helpful? Give feedback.
-
|
@u9000-Nine The names were illustrative, not literal propositions. |
Beta Was this translation helpful? Give feedback.
-
|
+1 to chaals We do need to keep a couple things in mind though as well
best |
Beta Was this translation helpful? Give feedback.
-
|
@GreggVan Can you speak a little more about your "wont to adopt it until it settles down" comment? I know EN 301 549 is one of those, no? But it updates more or less every two years. If W3C was to decide that WCAG 3 was going to be a living standard, with a snapshot published every year, why would EN 301 549 not pick up the latest version whenever it does its update? |
Beta Was this translation helpful? Give feedback.
-
|
Actually EN 301 549 generally will update less often. In this case there was a new law that asked for changes.
Whenever it has updated - it has picked up whatever is latest — which is why I suggested that we watch for when it is updating and push to get a new version out then. But it does not update BECAUSE there is a new version and a new version of EN 301 549 will not be mandated every time WCAG updates. There was an interesting confluence of events for the last two - but they also were quite a bit apart.
Note also that EN 301 549 is more than web — so the WCAG2ICT work is key.
Finally, it is important to note that the structure of the WCAG2’s were used to structure the EN 301 549. Since 2.1 and 2.2 followed that same structure - they were easy to incorporate into EN 301 549. WCAG 3 is expected to be completely different. This would cause EN 301 549 and all of its support tools and everything else to be restructured and re-thought. I would not expect a complete overhaul of EN 301 549 to be even attempted until Wcag3 is very mature and very complete. Because it would mean a complete switch from 2 to 3 and 3 would have to be complete before that made sense.
|
Beta Was this translation helpful? Give feedback.
-
|
The 2.x failed. It did not promote equity, and did not have due accommodation for all people with disabilities. |
Beta Was this translation helpful? Give feedback.
-
|
(apologies, this wasn't meant as a direct reply, more as a general "as part of the main thread" musing) While this won't provide any new insights, I'll just mention that I'm torn on the topic (and the related discussions on evaluation methods and outcomes). The discussions are, at their core, all interconnected and come down to a soul-searching exercise of "what do we want WCAG to actually be?", combined with a "how can others - developers, legislators, etc. - actually use WCAG in a sensible way?". There are very idealistic goals of making sure WCAG covers all possible scenarios, and include very subjective / hard to pin down objectives/goals. Others pushing for (for better or worse) fairly binary and testable outcomes, because pragmatically they know that guidelines can't work if it's not possible to reliably use them to come to either a "yes, this conforms" or "no, this doesn't conform" assertion at the end. This last point has been one of constant tension already in WCAG 2.x - trying to somehow come to a pass/fail when subjectivity is involved. And unfortunately, even with "those will just be evaluated with user testing" also doesn't guarantee consistent evaluation outcomes. And, against this backdrop, there's then of course the problem discussed here about how 3 will be published...and finding the answer to the soul-searching questions will influence this in large part. The various considerations have already been hashed out at length in this thread, but pragmatically I'll just say: as a developer, I won't engage with WCAG if it appears to be in constant flux; as an auditor/tester, I would be very worried about being asked to provide an assessment of whether something conforms or doesn't conform with a standard that is built on shifting sands/moving goal posts; I will guess that legislators will also not want to simply defer to a standard that is in constant change/development - instead of including things by reference/abdicating responsibility for determining if something is or isn't deemed "accessible" in a legal sense, they may well just handwavily point to WCAG, but then actually build their own interpretations (which may then diverge) on top of it, or only pick out certain "modules" (if going for the modular approach), or any other number of ways that in the end could result in differences across different legislations. That would then make the job of developers and auditors/testers even more challenging, as they'd then need to navigate these differences as well. I don't have a clear solution/preference here, but ... whatever gets decided here will potentially have deep repercussions on the viability of WCAG as a point of reference. And yes, part of me wishes that WCAG had not been so deeply enbroiled/intertwined with the "legal" dimension, as it would certainly provide a lot more room for the more subjective ("fluffy"/"handwavy") criteria to blossom. But also, as an auditor/tester, trying to have at least a modicum of stability and clarity (as imperfect as it currently is) on what is and isn't conformant, has been quite essential. |
Beta Was this translation helpful? Give feedback.
-
|
The question is how to move the sand in a way that prevents the whole structure from being unsound.
I have heard that, but the main consideration seems to be: WCAG does not tell me what to do, it only tells me what not to do. (Especially if people are looking at SCs only, which happens a lot.) I don’t think a new WCAG necessarily changes that, especially as most devs don’t engage with a stable WCAG, too. I don’t think there is a clear and easy way here. (At least not within the constraints of a W3C Working Group.) I think we all agree that WCAG needs to change, the fundamental question is revolution (throw out WCAG 2 and build WCAG 3) or evolution (continuously build WCAG 2 into something better). That’s for the WG to decide. |
Beta Was this translation helpful? Give feedback.
-
|
This is the final summary, based on the discussion in the last meeting (Jan 23rd). The first topic of discussion from the last summary was the starting point. Should we carry on with the WCAG 3 approach (outcomes etc) or switch to a starting point of WCAG 2.2 and iterate from there? There was broad consensus (with some objections) to continue with the current WCAG 3.0 approach. There were four risks added to the risk register as things to keep under review we go along. There was some discussion of the time-boxed vs modular approach, there was some support for investigating publishing modules, but we needed more time to define what that would mean. It will be discussed soon based on this new discussion page for Proposed modular approach to WCAG 3. |
Beta Was this translation helpful? Give feedback.
-
Some participants articulated a goal during charter discussions to avoid a 6-10 year gap between WCAG 2.2 and WCAG 3. They would like to explore what we could publish in shorter time frames that would help mature the industry.
Question for discussion: What are ways to break apart or stage WCAG 3 that would allow earlier publications?
Beta Was this translation helpful? Give feedback.
All reactions