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

I think Jake and Patrick make good points, particularly about doing our 
best to make WCAG "clearer, more easily understandable, and not some 
exercise in reading between the lines".

If there are known improvements that can be incorporated into 2.2, and 
given that there are 116 open pull requests, it's hard to imagine there 
are not, we really should be doing all we can to make 2.2 the best 
version of WCAG to date.

It's also worth looking ahead to the time when 2.2 goes to the AC for 
endorsement. If there is not a good explanatory narrative, it may not 
play well.


Léonie.


On 19/05/2021 08:30, Patrick H. Lauke wrote:
> 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

-- 
Director @TetraLogical
https://tetralogical.com

Received on Wednesday, 19 May 2021 09:39:27 UTC