- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 19 May 2021 08:30:46 +0100
- To: w3c-wai-gl@w3.org
On 19/05/2021 07:34, jake abma wrote: [...] > Personally I do not have the perfect answer, but it would be great to > have a thorough discussion about the critical notes from the community. > It might be that we can do more than only wait a couple of years till > SIlver might be mature enough to use, *and IF Silver solves the critical > notes!* Anecdotally, I've had conversations in the last year or so with developers, including people who used to be more involved in WAI-IG discussions and the discussions on github etc - and sadly, a lot of what I hear is that people are frustrated by long-standing gaps in documentation, lack of clarity in some of the non-normative documentation that has been around since WCAG 2.0 days (2008!), lack of *live* examples of some of the trickier asks of SCs, and just examples that they can actually relate to common patterns and practices of modern web development. And most of the time, they need answers/clarifications *now*, not in some "we'll fix that in the next version, and if not, in Silver". And this frustration, and the feeling of things not actually getting any better, is only increased when they then see the backlog of issues/pull requests that seem to be going nowhere. More than once I've suggested to people that they should file an issue for a specific suggestion/question, and they've just told me outright "what's the point?". And I won't lie, even I often ask myself the same question in my occasional bursts of activity, filing issues/PRs ... knowing that they'll end up with a lengthy flurry of back-and-forth discussion...and then don't seem to go anywhere after that. Or that they spark page-long soul-searching discussions on points that are surprisingly foundational ("what IS color, really?" etc), which just underline how some of the "fudges"/handwaving definitions of SCs that came from the 2.0 era (and have just been rolled into 2.1, and soon 2.2, and then 2.3) may not stand up to close scrutiny and poking after 13 years of developers trying to grapple with them and trying to apply them to real-world diverse content. But, probably to the annoyance of many people, I persevere - and yes, often with fairly strong and stubborn opinions - because I want to make sure that WCAG and its non-normative resources can become clearer, more easily understandable, and not some exercise in reading between the lines ("I think what the WG meant to say at the time is..."). And I try (and sure, sometimes miss completely) to make the explanations/examples in the non-normative explanatory documents make some kind of pragmatic sense - because developers are more likely to follow advice/rules when they can understand better *why* they should do it (and not just as a box-ticking exercise of "well, you have to because that's the law"). > For me it feels like the WCAG WG and all related sub-groups > are exponentially growing (too ?!) fast and this might result in even > more cluttered documentation and it is very hard to keep track on things. To this point, I'd add: I know the desire is to show progress by ... creating more and more SCs. As a way to show that WCAG is "agile". But the risk here is that we end up with a "quantity over quality" outcome. And particularly when there's a desire to move quickly and push new things out at speed, there's a danger that things are less than polished, and more fudges/handwaves are done just to get an SC over the line in time. The result is, just like after 2.1 was released, that edge cases and unforeseen outcomes bubble up later on, when there's no chance anymore to properly address them, because at that point focus is already on the next batch of new SCs. That's not "agile". That is simply adding to "technical debt" of the spec and its documentation. > Don't shoot the messenger ... :-) Love you all, and hope this > positive critical note helps us steer into the good direction! While my abrasive style is probably harsher than Jake's, the motivation behind it is the same. I *want* WCAG to be a good set of guidelines. I *want* them to be understandable, and as comprehensive as can be. I would love to be able to paper over/address many of the vagueness, gaps, and overlaps that we found over the years (which become even more obvious when you spend time trying to explain things to other auditors/developers ... that's when you get those "but *why* is this not covered? but what about *this* scenario?" questions, and you'd want to have a logical and understandable answer that goes beyond "it is what it is, it doesn't have to make sense, you just have to interpret it this way and move on". P -- Patrick H. Lauke https://www.splintered.co.uk/ | https://github.com/patrickhlauke https://flickr.com/photos/redux/ | https://www.deviantart.com/redux twitter: @patrick_h_lauke | skype: patrick_h_lauke
Received on Wednesday, 19 May 2021 07:31:46 UTC