RE: FW: Proposals for revision of the Plain Language SC proposals for WCAG 2.1

Hi Lisa / Mike,

I’ve finally come up for air…

SC 30 isn’t actually that huge as most of it is explanation and exceptions. The key to understanding the intent of this SC is in its scope: it is used where the user encounters a situation where, without a response, the user is completely stuck.

Looking at the base criteria:


·         Is there a role for reading ability when we are talking about complexity of language? So, “Use words or phrases that are most-frequently used for the current context, unless it will result in a loss of meaning or clarity.” could become:

“Use words or phrases that are most-frequently used for the current context, unless it will result in language that exceeds primary school reading ability.” I’m not sure what the actual reading age definitions are, but I’m thinking about the age of 11 / 12.

Given that both the word frequency and the reading age can be tested (and automated?) this seems a little cleaner, clearer and less subjective.

·         “This includes not using abbreviations, words, or phrases, unless they are the common form to refer to concepts for beginners. Where word frequencies are known for the context, they can be used.” With the exception of abbreviations, isn’t this covered by the above when we include the read age?

·         On the subject of abbreviations, given the scope of this proposals, they should not be used. I know I’m probably in a minority of one with this.  but surely creating a mechanism where either selecting or hovering over an abbreviation either replaces it with the full text or provides an explanation could be possible and not too difficult – especially when we are doing something like this for non-literal language? This deserves a bullet point all of its own.

Looking at the exceptions:


·         I think the first exception is made redundant by the second:


o   When a passive voice or a tense (other than present tense) is clearer. Other voices or tenses may be used when it has been shown, via user testing, to be easier to understand, friendlier, or appropriate.

o   In languages where present tense and active voice do not exist, or are not clearer in the language of the content, use the tense and the voice that are clearest for the content.

Unfortunately I think that this can only be human testable and it will require testers who are fluent in the language being tested. I suspect that this will be too complex to use reading age based testing.

·         “Where less-common words are found to be easier to understand for the audience. Such findings are supported by user testing that includes users with cognitive disabilities.” I don’t think substituting reading age will capture this, they easy out for the developer is to use common wording and this exception takes account of developers who have users with cognitive disabilities in mind when they are creating.

We also need to clean up the definitions a bit too around concrete wording / concrete language and literal and non-literal language. I did some of this when I revised the text (which I can’t seem to get uploaded) but more needs to be done in conjunction with the original author to make sure that the semantics aren’t being subtly altered.

The reference also need cleaned up, especially since a few of them are no longer available – alternate sources of information may be available, but the author would need to confirm that they are adequate replacements.

Much of this can be carried forward into SC 41<https://rawgit.com/w3c/coga/master/extension/plain-language-aa.html> as the major change here is in scope around the error messages and a reduction in the base criteria but I still think abbreviations need to be addressed here too.

As for SC 42<https://github.com/w3c/wcag21/issues/42> – I wonder if this should be retired as much of it is covered in SC 24<https://github.com/w3c/wcag21/issues/24>. 42 was always going to end up a AAA (if it got though at all) and while I can’t comment on the intentions of the AG, as far as testers and authors are concerned, unless it is easy and relatively quick, AAA is ignored. Rewriting the language of an entire site or constraining the language used, unless it is the specific purpose of the site just isn’t going to happen.

I can copy this into the GitHUb comments but want to make sure that I’m not going off on a tangent or getting this completely wrong.

Jim

From: lisa.seeman [mailto:lisa.seeman@zoho.com]
Sent: Wednesday, February 08, 2017 5:19 PM
To: Michael Pluke <Mike.Pluke@castle-consult.com>
Cc: public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org>; Jeanne Spellman <jspellman@spellmanconsulting.com>
Subject: Re: FW: Proposals for revision of the Plain Language SC proposals for WCAG 2.1

Hi Mike

 I agree we should do everything we can to reach the bar. I do not think they need to be more testable then the WCAG requirement or then the current WCAG 2.0 SC.

The base criteria (not the exception) is 100% testable.   The untestable parts you said are only exceptions.

The bench mark for human testability is that 8 out of 10 experts in the topic are reasonably confident. If 8 out of ten accessibility testers would not agree that it is clearer or using a more common word may results in a loss of clarity then use the more commen word. It has to be completely obvious that this is clearer and easier to understand before you use an exception. That is exactly what we want

The base criteria (not the exception) is 100% testable

note that in many success criteria in wcag part of it is testable and part is less so. For example in 1.1.1 an alt tag needs to serve the same function or purpose as the image.
In fact it never can because part of the images role is aesthetics.  When it first came out you did not often had consensus about the full 1.1.1 was fulfilled. You could get consensus easily whether there was an alt text. But that is all that is fully testable and that is not what wcag requires.

We do not need to be more testable then wcag 2.0. If the rules are unevenly applied, that that seems unfair to me. Also I realy do not think there is much to be gained by a low reading age on navigation. the formula will not work on these case.


All the best

Lisa Seeman

LinkedIn<http://il.linkedin.com/in/lisaseeman/>, Twitter<https://twitter.com/SeemanLisa>



---- On Wed, 08 Feb 2017 15:42:12 +0200 Michael Pluke <Mike.Pluke@castle-consult.com<mailto:Mike.Pluke@castle-consult.com>> wrote ----
One thing I forgot to add to my lengthy email below is that I am not suggesting that we completely replace #24<https://github.com/w3c/wcag21/issues/24> with what I proposed and then forget about all of the other good stuff. My suggested way forward is to break down these mega-SCs into smaller SCs that might be acceptable in terms of their scope, testability, technology independence etc. We can then try to propose feasible ones, hopefully get them accepted, and then move on to identify other plausible SCs that may have been hidden in the mega-SC. All those managing the process of getting the first Working Draft of 2.1 seem to say that adding things in later iterations is a possibility. I guess that maybe we just have to trust that this will happen in practice.

I think we really need to escape the mindset where we believe that the reason that our SCs are being rejected is simply because people don’t understand or care about the real user needs. Although that might possibly apply to a few people, I’m strongly convinced that the reasons are entirely due to the mismatch between what we have proposed and how WCAG 2.0 is used today and how WCAG 2.1 will be expected to be used when it is available.  If we continue to believe that we are dealing with a hostile (or ignorant) set of anti-COGA people we will just end up endlessly crying on each other’s shoulders and not doing what needs to be done to get some successes!

Sorry if this sounds very harsh – but I fear that if we don’t accept the real situation we will get nowhere. That would not be good for cognitive accessibility.

Best regards

Mike

From: Michael Pluke
Sent: 08 February 2017 13:05
To: 'lisa.seeman' <lisa.seeman@zoho.com<mailto:lisa.seeman@zoho.com>>
Cc: public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org<mailto:public-cognitive-a11y-tf@w3.org>>; Jeanne Spellman <jspellman@spellmanconsulting.com<mailto:jspellman@spellmanconsulting.com>>
Subject: RE: Proposals for revision of the Plain Language SC proposals for WCAG 2.1

Sorry, catching up on a major email backlog!

I could go with 3 in principle, but only if we heavily amend what we request. I’m not sure that simple reading level is the answer – we can cite several examples where it is probably not. The problem is that our current text includes so many things that are, in my opinion, completely untestable (except with extensive and very well designed user testing).

For example, in #30<https://github.com/w3c/wcag21/issues/30> we have “unless it will result in a loss of meaning or clarity”, “unless they are the common form to refer to concepts for beginners”, “When a passive voice or a tense (other than present tense) is clearer.” and several more.

We could only begin to expect WCAG approval of some of our mega-SCs (like #30) if they are dramatically cut back to include a very few elements that are testable. This clearly means that meeting the SC will completely eliminate a large problem for everyone with a cognitive or learning disability, but it should ensure that they would have less problems. Almost all of the existing WCAG SCs are like this. There are no single SCs that, if met, will eliminate all the reading issues for blind users (for example). Even the full set of SCs will not do that.

The task we have of trying to improve things for people with cognitive and learning disabilities is infinitely more difficult than trying to address the needs of blind users (in my opinion). I think that all that we can realistically expect is to make some improvements in 2.1. If we are too ambitious then we will fail to do that.

An example of what I mean is #24<https://github.com/w3c/wcag21/issues/24>. The original tried to give detail as much as possible about how to reduce the cognitive load associated with dealing with “important information” in either textual or other media form. I think that there is no way that this vastly ambitious SC proposal could be edited to make it acceptable to the WCAG WG. I have made a proposal, which the SC Manager John Rochford seems to like, to only relate to “statements which instruct a user to make a choice or take an action”. Whereas we could, as Jeanne proposes, specify the appropriate reading level for such statements, I suggested just three bullets which I think are quite testable:

  *   have only one instruction per sentence, except when two things have to be done simultaneously;
  *   use sentences of no more than 15 words;
  *   should have no more than one relative pronoun per sentence. [with a glossary entry that lists all the relative pronouns]

I have sources to say that all three of these are known to be effective (but I have so far failed to find the time to specify them, which I should). Arguably sticking to these might be more effective than just specifying a reading level for these vitally important statements. I doubt that there is a great body of research that links the effectiveness of instructions (as such) with reading level. However, if we had to go with reading level I still think that it would make a positive contribution to improving the possibility that many users with cognitive and learning disabilities would find that they could understand instructions much better.

Best regards

Mike



From: lisa.seeman [mailto:lisa.seeman@zoho.com]
Sent: 06 February 2017 21:34
To: Thaddeus. <inclusivethinking@gmail.com<mailto:inclusivethinking@gmail.com>>
Cc: public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org<mailto:public-cognitive-a11y-tf@w3.org>>; Jeanne Spellman <jspellman@spellmanconsulting.com<mailto:jspellman@spellmanconsulting.com>>
Subject: Re: Proposals for revision of the Plain Language SC proposals for WCAG 2.1

I am changing my vote to 3 as well.
The SC as it  is incredibly easy to write testing tools for. there are a few open source  language processing tools that you can use to count cluses actureltys. Testing against a word list is also something that exists already in restricted language tools and is very easy to program. It cant be that we need to have a worse SC and use archaic reading level tools because WCAG are to set in their ways to accept any new technology.
All the best

Lisa Seeman

LinkedIn<http://il.linkedin.com/in/lisaseeman/>, Twitter<https://twitter.com/SeemanLisa>


---- On Mon, 06 Feb 2017 21:55:36 +0200 Thaddeus .<inclusivethinking@gmail.com<mailto:inclusivethinking@gmail.com>> wrote ----

I vote 3
On Feb 6, 2017 11:08 AM, "lisa.seeman" <lisa.seeman@zoho.com<mailto:lisa.seeman@zoho.com>> wrote:
We had issues with reading level , for example the word "mode" is a lower reading level than "hot or cold" . the lower reading level is much harder to understand.
The reason to go with Jeanne's proposal is because wcag _might_ find it more testable. This would only be, in my opinion, because they have not bothered read the whole proposal and testability section  (or they do not want new tools) Also i am not sure it is more testable in different languages and that is essential for WCAG. Wordlists requiremnts however, can work easily in any language and wordlists can be automatically generated by parsing a few sites.

I agree that the "unless..."  clause is only human testable but that it very typical for wcag.


I want to suggest three options

1 -  we retract our current pull requests and put these in instead

2 - we go with the current pull requests. If they fail and the comments are hard to address then we go with Jeanne's

3 -we go with the current pull requests. we can revisit this if needed

My vote is 3, to go with the current wording and see what happens

All the best

Lisa Seeman

LinkedIn<http://il.linkedin.com/in/lisaseeman/>, Twitter<https://twitter.com/SeemanLisa>


---- On Mon, 06 Feb 2017 20:00:24 +0200 Jeanne Spellman<jspellman@spellmanconsulting.com<mailto:jspellman@spellmanconsulting.com>> wrote ----

A group of us at The Paciello Group (TPG) have been meeting every week in January to comment on the WCAG 2.1 proposals.  Because we test WCAG 2.0 all day, every (business) day, we have a lot of experience with both the language of WCAG and the testing of WCAG.  What we decided this week is that we want to focus our efforts toward helping COGA TF draft success criteria that will get into WCAG 2.1 and will accomplish most of what you want -- even if it is phrased differently.

We started with the proposals that we thought would be the least controversial to the WCAG WG to include.  I looked at the Plain Language proposals and did my best to look at the needs identified by COGA TF, and craft language that I thought would be acceptable to the WCAG WG and be included in the first draft version of WCAG 2.1.

The wording is quite different, but in my opinion, addresses the needs identified.  I chose reading level, because it is internationally standardized, and there are automated tests already available.  When I look at Technique  G153: Making the text easier to read  https://www.w3.org/TR/WCAG20-TECHS/G153.html , it covers most of the items that the COGA TF identified.

Issue 30 Proposal:

Understandable Labels:  Navigation elements and form labels do not require reading ability greater than primary education level.  (A)  [link to WCAG’s definition of primary education level from UNESCO standard]



Issue 41:

Understandable Instructions:  Headings, error messages and instructions for completing tasks do not require reading ability greater than lower secondary education level.  (AA)  [link to WCAG’s definition of lower secondary level from UNESCO standard]



Delta 3.1.5 (rewrite of existing WCAG 3.1.5)

Understandable Content: Blocks of text either:  (AAA)

·        have a reading level no more advanced than lower secondary education, or

·        a version is provided that does not require reading ability more advanced than lower secondary education. [links to WCAG’s definitions of lower secondary education and blocks of text]