Re: Plain Language Prototype for comments

Hi everyone,

I agree with David that we need accurate and testable criteria, we to solve these two issues (from the research) at the same time:
- Too Difficult to Read
- Ambiguity in interpreting the success criteria

The plain English prototype is solving the first issue at the expense of the second.

To solve that dichotomy [1] we need different types of language for different people, in the same ‘space’.

My suggestion is to bring in the technology-specific testing criteria as an optional display item.

Imagine that someone has ticked a box saying they are working in web-stack/HTML, and have a look at this version:
https://docs.google.com/document/d/1-ot09sSg7aUNqq25-Cd4LT9sooVEkEnuDNQddoyX6-Y/edit?usp=sharing

It is two examples (heading & name/role/value), with just the summary & testing bit shown. I’m assuming it is the same after the “Why?” heading.

The ‘Testing (HTML) section is essential drawn from the current techniques, and is a QA/developer friendly version of the testing method for that criteria. (And it’s a 5 minute thing to show the concept, it’s not complete.) Each point can link to a detailed technique.

If someone hasn’t selected a technology, then perhaps we hide that area. But if they do, then the accurate & testable versions could be shown prominently.

Cheers,

-Alastair

1] https://lists.w3.org/Archives/Public/public-silver/2018Aug/0034.html



From: David MacDonald

I think there are good ideas in there to make the Understanding simpler and easier to read. However, the rewritten Success Criteria themselves appear to deviate from the requirements of the actual Success Criteria. I'm concerned that having different versions of Success Criteria for different audiences will create more confusion than simply cleaning up the understanding documents and leaving the SC.

The new SC talk about "your text" and "your website". How do we know who's content it is and whose website it is, and whether the person reading the SC owns the content they are remediating? Devs I work with rarely own the content or the website. It was usually handed to them to code, or fix. That may create more confusion for someone with cognitive difficulties. They may not think the SC applies because its not "your text" or "your website".

The current WCAG 2.0 language for an SC is a statement about the content when it passes. We found telling the author to do something with a verb was problematic during the development of the WCAG 2.0. It might be a good idea for the plain language team to have a meeting with some of us who were involved in creating the SCs, to avoid duplicating efforts that were later rejected, or at least understanding why the current language is the way it is.

I realize that we will probably change the requirements for an SC (or whatever they are called) in Silver, but this document linked below might help us understand what the WCAG team were thinking when writing those Success Criteria and might answer the question I hear so often "What were they thinking when they wrote the SC like that?"

Any approach that doesn't solve the problems we were trying to solve (in hopefully a more elegant way), may run into trouble later and cause setbacks.

http://www.davidmacd.com/blog/what-are-WCAG-success-criteria.html



Cheers,
David MacDonald



CanAdapt Solutions Inc.

Tel:  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>


On Mon, Sep 24, 2018 at 10:06 AM Jeanne Spellman <jspellman@paciellogroup.com<mailto:jspellman@paciellogroup.com>> wrote:

Here is the plain language prototype ready for review:
https://docs.google.com/document/d/1BGr0XSQgjBSVDG_Xn9MoodEq01cJxgg_EE0bniXONXM/


Please provide comments on content, structure, readability.

The audience is intended to be general: every member of a product
development team to help them get on the same page, plus product owners,
policy makers, and the general public.  It should be readable enough
that someone without a background in either accessibility or digital
product development can understand the intent.  And the language should
be accessible and inclusive.

Please also provide comments on how to make it more accessible and
inclusive.

You'll notice that there is an embedded link to a mock-up of how this
may look.  The key point with this is that there will be separate tabs
for specific activities, such as developing, designing, planning,
usability testing, and auditing.  If you have content for these, please
indicate this clearly, ideally on the relevant mock-up page.  We are
trying to keep specific guidance for these roles off the main plain
language page (which you'll see in the mockup is called "get started").

If you would like to help draft those other plain language tabs, for a
specific activity, please let us know, as that is still work to be done.

If you would like to participate more in plain language writing and
editing, please let us know.  There will be a need to continue to test
this prototype with more guidelines in order to improve a Silver
StyleGuide to ensure clarity and consistency.

Thanks very much for your help with this and we look forward to your
feedback.