Re: UPDATED AGENDA and Survey - AGWG & Silver joint Meeting May 18th 2021

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