Re: Response from Accessibility Lawyer on Plain Language in Silver

Part of the purpose of the Silver prototype functional testing we are 
currently doing is to see how far we can push the plain language ideal 
until we run into the difficulties Alastair has been raising.  At that 
point we can refine the prototypes and the Silver style guide to 
accommodate them.  I suspect that we will end up with plain language for 
the Guidelines and more technical language for the Methods, but we won't 
know that until we get more functional testing results.

I hope that all of you responding to this thread are working on 
following the template and Style Guide to test the plain language 
prototype for Silver.  Personally speaking, I would prefer feedback from 
people who are actually testing the prototype than more theoretical 
speculations.  Instructions and links to the template and style guide 
are here: 
https://lists.w3.org/Archives/Public/w3c-wai-gl/2018OctDec/0060.html. 
(For Silver list readers:  I have a ToDo item I hope to get to today to 
send out a more detailed invitation for all of you to test the 
prototypes as well.)

For those who are new to Silver: when we did the Silver research, we did 
in-depth interviews with lawyers and regulators. We received input from 
lawyers and regulators during our public presentations and surveys.  We 
included 2 lawyers in the Silver Design Sprint.  There is a lawyer who 
is active in Silver Community Group.  They have been encouraging about 
using plain language in Silver because it makes accessibility guidance 
more understandable to regulators, legislative bodies, and judges.

We welcome more advice from specialists, and I appreciate that David 
reached out to get advice from another lawyer.  I don't see a conflict 
in his response with the general direction we are pursuing with Silver 
plain language.



On 11/14/2018 7:23 PM, Alastair Campbell wrote:
>
> I’m going to stick to the Silver email list for this, it will cause 
> duplicates for people otherwise.
>
> **
>
> Dale wrote:
>
> > I'm really curious about this suggestion: "We would suggest using a 
> mixed Plain Language and Technical language rather than settling on a 
> one-size-fits all model for creating WCAG Silver."
>
> > I'm curious why that is. Couldn't plain language benefit everyone?
>
> Unfortunately plain (or at least clear) language is different 
> depending on your experience and the meaning you attach to certain words.
>
> For example, a “heading” is a “label” for a “section” of content. You 
> can use all those words in a plain language version of something, but 
> a web developer will attach different meanings from a project manager, 
> a lawyer, or even an iOS developer.
>
> Using the term ‘label’ when talking about headings for content would 
> be ok for the general population, but confusing to a web developer who 
> thinks of labels and headings as very different things used in 
> different situations.
>
> I use the example of developers as I’m sure anyone who has run 
> accessibility training can relate to this: You explain a guideline 
> simply, and the project manager & designers nod along. The developer 
> nods, then asks with 50 questions working out /how/ to implement it… 
> they need the details, the technical accuracy that they understand 
> based on domain experience.
>
> Cyborg (autocorrected?) wrote:
>
> > The other tabs need to be plain language enough to reduce the costs 
> of having to hire specialists and to make methods achievable for even 
> entry-level employees as much as possible.
>
> There is an assumption that if a guideline is clear and understood, it 
> is achievable.
>
> Unfortunately that is rarely the case, I’d equate that to: running a 
> marathon is simple (easily understood), but it is not easy.
>
> A simple guideline would be to audio-describe every video. However, if 
> it doesn’t have exceptions for live video, or videos without spaces 
> for the description, that would cause a massive burden. Each guideline 
> can have a cost in terms of doing the work to achieve it, regardless 
> of the clarity. Sometimes the complexity comes from trying to reduce 
> the work needed to achieve the goal.
>
> Also, whether a method is achievable by any level of employee is at 
> least as dependent on the organisation’s systems as the accessibility 
> guidelines.
>
> That doesn’t affect the main point about separation of language, but 
> I’d be careful about selling plain language guidelines as reducing the 
> burden, that may not correlate.
>
> What I am concerned about is where the ‘testable’ bit goes, which is 
> important for policy & laws.  It would be particularly difficult to 
> make the testable aspect plain-language without writing an essay [1], 
> but including it as part of the methods doesn’t seem right either.
>
> Cheers,
>
> -Alastair
>
> 1] https://lists.w3.org/Archives/Public/public-silver/2018Aug/0034.html
>