Re: Response from Accessibility Lawyer on Plain Language in Silver

Reply from Cyborg:

This is very much in line with what I was suggesting.


The "Get Started" page could be as plain language as possible, ideally 
for a general, public audience, including people with disabilities who 
may feel that the digital product or website is not accessible and want 
to consider options about how to address it.  This is an accountability 
and transparency feature that is important.

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.  This also reduces the burden 
on regulators as they then don't need to hire a big expert just to 
understand what's expected.  They can ask anyone with technical 
competence.  The technical experts can then weigh in on the impact of 
conformance or lack thereof -- in other words, to provide analysis and 
interpretation, rather than basic translation.

It is of course important and necessary to ensure that plain language 
does not reduce clarity or precision of intent. Therefore the 
arrangement that Shawn offered, for example -- that someone focused on 
plain language such as myself (and others) could draft it, and then 
someone like him could verify that it's accurate/precise -- is probably 
best.  The Style Guide should reflect that two-step review for the "Get 
Started" page.  I think the ideal writers for the methods tabs should be 
those who are teachers/mentors/supervisors who implement WCAG and 
routinely have to explain it to others they work with.  It doesn't 
matter too much if the general public understands the methods, as long 
as the team leads are able to communicate about them with their teams 
and they are able to hire a broad enough sample to get it done in a way 
that is financially accessible for a range of product owners.

I hope that helps.

C.
On 11/14/2018 10:42 AM, David MacDonald wrote:
> Hi All
>
> I asked Joshua Stein with whom many of you may be familiar, who's been 
> an accessibility lawyer on many ADA cases, the following question.
>
> *"*Do you think that the  wording in WCAG 2.x is frustrating to legal 
> proceedings, and that it would be better if we moved to a model that 
> is plain language ? "
>
> Joshua's unedited response which he has given me permission to share 
> with our groups.
>
> ================
> 1)     From a legal perspective, the courts are currently focused on 
> the end result of website accessibility (i.e., is a website in 
> substantial conformance with the applicable WCAG  success criteria and 
> does it offer individuals with disabilities the same experience as 
> individuals without disabilities?).  Using active vs passive voice 
> within the Guidelines should have a limited direct effect on the legal 
> application of the WCAG as, to-date, the courts are not hearing 
> specific challenges to the WCAG language.  This is likely due to the 
> fact WCAG has not been formally adopted by a government regulator 
> (e.g., DOJ) and, therefore, the Guidelines are not subject to the same 
> legal scrutiny given to Standards promulgated by the federal 
> government that places of public accommodation are required to 
> follow.  Should the legal landscape change, a WCAG Silver “Guidance” 
> document could be created to help clarify any specific legal 
> challenges to the original text/prior versions.
>
> 2)     I spoke with our in-house website accessibility team and, from 
> a programmer/tester perspective, the use of plain language within the 
> WCAG would likely improve its overall understandability to a broader 
> audience (developers and designers).  The current WCAG 2.1 language 
> contains a lot of ambiguity which can make it difficult to determine 
> if an issue can/should be categorized under a specific guideline 
> and/or success/failure technique.  However, we also acknowledge some 
> of the technical language currently used is necessary to identify 
> success criteria issues and to describe the steps required to fix the 
> issue.   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.  Plain language examples of possible remediation 
> options would likely prove beneficial as well.
>
> ===============
>
> Cheers,
> David MacDonald
>
> *Can**Adapt**Solutions Inc.*
>
> Mobile:  613.806.9005
>
> LinkedIn
> <http://www.linkedin.com/in/davidmacdonald100>
>
> twitter.com/davidmacd <http://twitter.com/davidmacd>
>
> GitHub <https://github.com/DavidMacDonald>
>
> www.Can-Adapt.com <http://www.can-adapt.com/>
>
> /Adapting the web to *all* users/
>
> /Including those with disabilities/
>
> If you are not the intended recipient, please review our privacy 
> policy <http://www.davidmacd.com/disclaimer.html>