RE: Response from Accessibility Lawyer on Plain Language in Silver

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