Assigned to Jim Smith (@jim-work) https://www.w3.org/WAI/GL/wiki/SC_Managers_Phase1

@jim-work Is there a PR ready to go for this?

Pull request #106

This is difficult to measure and to implement. I recommend looking at using reading level. It isn't perfect, but it addresses most of the user needs identified, especially when paired with existing Technique G153. Reading level has international support, it has automated tests, and it has a variety of formulas (Flesh-Kincaid is the oldest and best know, there are many others like the Dale-Chall list, which provides 3000 common simple words.)

Proposed revision:
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] Techniques should include links to the Dale-Chall list.)

Short Text

and error messages, which require a response to continue

I’m curious about this qualification. It suggests that an error message that doesn’t require a response is an exception. What is the rationale for this?

(See exceptions for different context and language.)

I don’t think it is necessary to have this ‘see exceptions’ text here. Perhaps it's an editorial comment for the review?

Concrete language: Non-literal language is not used, or can be automatically replaced, via an easy-to-set user setting. All meaning must be retained when non-literal text is replaced.

Is there a reason to describe what you don’t want instead of what you do want? How about “Words are used according to their proper meanings or definitions. Metaphors and figurative language are not used unless they can be automatically replaced with literal text based on user settings.”

The words on controls and labels identify an element's function.

G131 already covers this to meet both 2.4.6 Headings and Labels and 3.3.2 Labels or Instructions. I do not see the point of regurgitating this.

Also on instructions: Each step in instructions is identified, and literal wording is used.

As with the control material, I question whether this isn’t already covered elsewhere – or if it could be incorporated into current SC without significant impact. As well, I would argue that regardless of the potential to work any new requirement into 2.4.6, this also seems to be fully covered by the criteria you are proposing in Task Completion. There should be some level of normalization between techniques – ideally only one technique should capture an issue, not many.

easily available

Not sure why this SC is defining "easily available" since it is not used anywhere in the text except listed as a possible technique

Testability

Tense and voice are objective, and hence are verifiable. (It is expected that natural language processing algorithms will be able to conform to this automatically with reasonable accuracy.)

I don’t think it would be accurate enough that one would be able to automatically indicate a Violation from an automated test. I suspect such triggered failures would need to be Potential Violations, still subject to human review. I also question many web-content creator’s abilities to fully understand tense and voice.

Testing content against these word lists

There are many word lists. Which one is the one someone needs to test against? Which one is the one that will fail? We know that any measure that can be disputed will be, and that it can lead to risk. No solution offered, but this will be a hard sell. Also, are “frequently used” words 100% correlated with “clear” or “simple” words?

Techniques

Failure of SC 3.1.x due to replacing words with pronouns, as this decreases clarity; or
Failure of SC 3.1.x due to requiring users to learn new terms or new meanings for terms or symbols; or

Troubled that there are techniques listed for pronouns and symbols, when neither are mentioned in this SC.

agree with @mbgower on the wording changes. Small change:

Words are used according to their common meanings or definitions. Metaphors and figurative language are not used unless they can be automatically replaced with literal text based on user settings

@jspellman this has been discussed. the reading age thing does not work in this context and makes it easier to read but nt understand. It will not solve the cases and examples brought in the discription. This may require accessibility experts aquiring new skills and buying new tools. I feel that is OK

full new proposal

Plain language: Provide clear and simple language in instructions, labels, navigational elements, and error messages, which require a response to continue, so that all of the following are true.

For instructions, labels, and navigational elements:

Simple tense: Use present tense and active voice. 
Simple, clear, and common words: Use words or phrases that are most-frequently used for the current context, unless it will result in a loss of meaning or clarity. 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.
Double negatives are not used.
Concrete language: Words are used according to their common meanings or definitions. Metaphors and figurative language are not used unless they can be automatically replaced with literal text based on user settings

Also on controls:

The words on controls and labels identify an element's function.

Also on instructions:

Each step in instructions is identified, and literal wording is used.

Exceptions:

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.
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.
When describing or discussing past or future events, the present tense is not required.
If the writing style is an essential part of the main function of the site, such as a game, a literary work, or teaching new terms.
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.
The writing-style items may be replaced for a location or a type of content in which user testing has shown a more-effective writing style to aid comprehension for people with cognitive disabilities. Example: content written in a specific natural language.
The content will be penalized for not conforming to a given writing style (such as a CV, dissertation, or Ph.D. proposal).

How can you close this? You've barely responded to any of the points raised.

Words are used according to their common meanings or definitions.

You now have "common" used in two separate bullets. I think I get why you would not want to use "proper" but it creates overlap to use "common" twice. As well, many metaphorical uses of words are common uses. I suggest using "literal" instead, or finding a better alternative.

This may require accessibility experts aquiring new skills. I feel that is OK.

I believe this is your response to Jean's "This is difficult to measure and to implement" comment?

Without going into a discourse, I'll just say that many of the COGA candidates are not resolvable at the stage where most accessibility scrutiny currently takes place. Trying to improve and broaden the accessibility of content is our key goal, but let's not downplay the challenges posed by some of the candidates in their present form. A whole lot more than accessibility experts will need to acquire new skills to achieve and verify ones such as this.

I think there is a fundamental issue with all the plain language success criteria that have been proposed which has nothing to do with the availability (or lack of) of automated tools.
Instructions:
I have great concerns that mandating active voice is far too rigid.
Take these examples that use the passive voice in (hypothetical) instruction type texts:

• If you are asked in a mail to pay an invoice, be careful. Often this is an attempt to trick you.
• If you are bitten by a dog, see a doctor immediately.
• If you are bullied at work, call the helpline number below.

The good thing about using passive voice here is that the main person (you, the one receiving the advice) is clearly in focus grammatically as being the subject of the sentence.
Of course you can rephrase these examples by introducing the implied subjects of the action ("If a dog bites you, see a doctor immediately.") but arguably this does not improve and may in many cases complicate the sentence.

Take another example that could appear in an instructional text:

• Not much is known about this disease.

Turning this example into active voice "Scientists do not know much about this disease" arguably makes the sentence more complex because it forces the appearance of a subject that is not helpful - the same might be true not just for scientists but also for doctors, policy makers etc.

So what is the problem? Testers identifying passive voice may feel encouraged to fail content if they are not sure that one of the exceptions applies.

Also:

• Exceptions may never be exhaustive - it will often be difficult to determine whether or not an exception applies.
• It is difficult to determine whether "a passive voice or a tense (other than present tense) is clearer" in the absence of user testing (and it might still be inconclusive after testing).
• It is not at all trivial to correctly identify a passive clause - Pullum shows many cases where even professional advisers got it wrong. http://www.lel.ed.ac.uk/%7Egpullum/passive_loathing.html

Controls:
In yesterday's telco, I have emphasized that we already have two 2.0 success criteria that together should cover what plain language applied to controls is supposed to achieve for sighted users (another couple of SCs, 1.1.1 and 4.1.2, mainly adress non-visual use cases):

• 3.3.2 Labels or Instructions: Labels or instructions are provided when content requires user input. (Level A)
• 2.4.6 Headings and Labels: Headings and labels describe topic or purpose. (Level AA)

I think we agreed in yesterday's telco that controls might therefore be taken out of the scope of this SC because of that, but that is up to the COGa TF to decide.

Detlev

@mbgower The pull request was made before the most of the comments were made. We were just late closing the thread and then the discussion started again. The discussion is meant to move to the pull request - at least I think so. TO be honest I find it all quite confusing.

@joshueoconnor @marcjohlic @detlevhfischer I would like to continue discing this on the lisr and on the coga call tomorow. You are invited to join us, so we can work out the right wording.

@lseeman

The pull request was made before the most of the comments were made. We were just late closing the thread and then the discussion started again.

Looking over the thread, it looks like the pull request was made before there was any discussion. I don't see the value of trying to move something forward without any vetting. There seems to be an element of panic going on in trying to push the COGA candidates through, sort of an 'Anything is better than nothing' attitude. That's a false dichotomy. Scrutiny and conversation will advance and refine the issues towards incorporation. Trying to move draft proposals in bulk to the next stage without addressing contentious and unresolved issues ("kicking the can down the road") is not a good strategy.

The discussion is meant to move to the pull request

It looks like the pull request has also been closed. Where are we supposed to post questions and issues for this topic now?

TO be honest I find it all quite confusing.

I share some of that confusion. But I don't think either of us give up easily, so let's adapt the system for ourselves to make it work.

@lseeman, now that you've introduced the idea of a 1500 word list as a key measure, I'd like to get back to @jspellman's suggestion about using something like Dale-Chall reading level as at least a partial solution there. Here are your starting bullets:

• Simple tense: Use present tense and active voice. (See exceptions for different context and language.)
• Simple, clear, and common words: Use words or phrases that are most-frequently used for the current context, unless it will result in a loss of meaning or clarity. 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.
• Double negatives are not used.
• Concrete language: Non-literal language is not used, or can be automatically replaced, via an easy-to-set user setting. All meaning must be retained when non-literal text is replaced.

What would happen if you retained the double-negatives and (reworded) concrete language, and swapped out the reading level in place of the "simple, common" words, to be something like this:

• Simple words: Words do not require reading ability greater than primary education level.
• Double negatives are not used.
• Concrete language: Words are used according to their literal meanings or definitions. Non-literal language is avoided.

You'll note that I've removed "clear" and information on present tense and active voice. I believe they have had enough feedback that they can be addressed in the Understanding document without forming part of the starting language. If you think clarity is a crucial measure that is testable, attention can be focused on helping solve that item specifically. You can also work your idea of "common" into exception language based on the context.

I have removed the following part, as I would argue it is overly prescriptive. This can be introduced as a technique, involving personalization.

or can be automatically replaced, via an easy-to-set user setting. All meaning must be retained when non-literal text is replaced.

Still lots of space for wordsmithing, but I think these three items do go a ways to achieving the goal.

In regard to your starting text

Provide clear and simple language in instructions, labels, navigational elements, and error messages, which require a response to continue, so that all of the following are true.

I would still like to understand the rationale for appending "which require a response to continue". What scenario are you avoiding? However, if you feel it is necessary, at the least the comma should be removed after "messages" so that the phrase is clearly qualifying error messages and not the rest of the sentence.

I think there has been enough discussion about the relevance of existing SC language that you do not need the additional specific items for "also on controls" and "also on instructions".

@mbgower it precludes logs, and warning etc. It makes it only stuff that stops the user from continuing. In other words, it reduces the scope towards the absolute essential stuff that you need to use an app or website. Considering the resistance it should be clear why we need to do that.

Latest draft has got rid of the also on controls, and has intergrated in instuctions are clearly identified.
I have no idea where the latest draft is meant to sit but have asked the chairs for guidance on that.

Okay, so by "response" you mean acknowledgement, like having to click "okay", etc. Removing the comma will help with that, then. Thanks.

Updated the issue description to reflect the FPWD text and reopening issue.

Similar to logos being exempt from color constrast requirements, I would expect product and brand names to be exempt from plain language requirements.

@CharlesBelov yes, that makes sence

@cstrobbe Thank you for your well reseached comments. - and for finding the word frequency scripts. i had it on my to do list to write one, but now I do not have to.
I am tempted to only recommend a corpus but not require it. That way we will not run into difficulties with dialects and sites that are for a specialist audience.

new proposed language that adresses most of the comments

Error messages that require a response to continue, instructions, labels and navigational elements use language , so that all of the following are true:

• Double negatives: Double negatives are not used to express a positive statement.
  -Common words:Use the most common 1500 words (including word roots in agglutinative languages) or phrases or, provide words, phrases or abbreviations that are the most-common form to refer to the concept in a public word frequency list for the context.
• Concrete language: Non-literal language is not used, or can be automatically replaced, via an easy-to-set user setting. All meaning must be retained when non-literal text is replaced.

@jim-work @jmcsorle I made a small change ti the first sentence. it is a bit clearer (I think)

For error messages that require a response to continue, instructions, labels and navigational elements all of the following are true:

I am wary of setting a standard to "double negative" due to either negative polarity ( of Latin and German-bsed) languages verses the negative concord of languages uch Portugese, Russian Spanish. Therefore internationalization would become an issue with this standard seemingly.

https://en.wikipedia.org/wiki/Double_negative

Maybe this could be addressed?

@CityMouse the Negative concord is allowed with the new wording. You only can not make a positive statements using double negatives. That is the change to support internationalization .

a new sources http://www.minspeak.com/CoreVocabulary.php#.WQ8EzuUrI2w

On today's call (in the extended time), I proposed a departure from the current approach to Plain Language, which I was asked to draft. Here it is:

Proposed SC

Clear Instructions: Instructions describe the topic or purpose.

Background

This is a direct use of existing SC language in 2.4.6 to plug a hole between 2.4.6 and 3.3.2 that results in labels needing to be present and descriptive, but instructions just needing to be present.

Headings and labels describe topic or purpose.
Labels or instructions are provided when content requires user input.

There can be a lot better language than the short description I've supplied. (e.g., "Instructions describe the desired user action or behaviour.)" I simply lifted the existing 2.4.6 language since it already passed at 2.0, and therefore should be serve as a sample of a simple and relatively vague goal which nonetheless has existed in WCAG SC langauge for the past decade.

What it addresses

By focusing on the lack of a requirement to make instructions descriptive (or clear), this SC immediately opens up the possibility of introducing a bunch of techniques that can be used to address COGA TF objectives.
In example, the techniques for 2.4.6 state

The objective of this technique is to ensure that the label for any interactive component within Web content makes the component's purpose clear.

The techniques are very high level and undeveloped for 2.4.6. So, all the points that were trying to be given the weight of an SC requirement could become techniques that can be employed for both 2.4.6 and this new Clear Instructions SC:

• employ word lists
• use concrete language
• use present active tense
• avoid double negatives

It could also draw on neglected parts of the following proposed SCs to add additional techniques:

• Clear Text and Voice #27 Clear Text and Voice ("punctuation")
• Clear purpose #55 Clear Purpose
• Manageable blocks #24 Manageable Blocks

And the following are somewhat related, and could again offer possible techniques:

• Extra help #45 Extra Help (detailed instructions 'enhanced')
• Section headings #40 Section headings (added text)
• Help #32 Help (transform text)
• Support Personalization #6 Support Personalization
• Feedback #54 Feedback (written)

Summary

What I'm proposing is essentially a beach head that covers the ability to consider the content of instructions as an SC. It allows many of the COGA 'wants' to be baked into 2.1 as techniques. Since techniques are not normative, they can be added to and enhanced more iteratively and help drive COGA adoption.

Do you think it would be possible to include navigation links? I could see that helping to cover more of the use-case from COGA without needing the complexity of word lists.

Do you think it would be possible to include navigation links?

Depending on what you are talking about, I would have thought those would more likely be labels, and any techniques could fall under either 2.4.6 or one of the Link Purpose guidelines. I personally would advocate moving the Link Only SC to AA from AAA, and doing an edit on the Understanding doc content. In Context is at level A, so it seems like a simple and obvious way of eliminating the "read more" kibble that litters some sites.

NB: I think people might be missing the actual SC text you're proposing, it's very short and in bold at the top, maybe reformat that to:

Clear Instructions: Instructions describe the topic or purpose (level A/AA)

In the Plain language SC it applies to error messages (that require a response to continue), instructions, labels and navigational elements. I was wondering if it would make sense to have:

Instructions, navigation elements and error messages describe the topic or purpose.

(As labels and heading are already covered).

However, at that stage it feels like we'd want to combine them all. (Headings, labels, instructions, nav elements, error messages...)

I think it could include error messages, since 3.3.3 Error Suggestion is pretty loose about making the suggestion clear -- and it is a form of instruction.

I'm still waiting to figure out what exactly is covered by navigational elements. Can you provide examples?

I'd say it's the same as WCAG 2.0's Navigation mechanisms, which is to say I'm not sure we have a definition!

Maybe it would be best phrases as "terms within navigation mechanisms" to match.

In terms of examples, anything you would put in <nav> or role="navigation", tabs, menus. The black bar at the top of this page, the tabs at the top etc.

Clear Instructions: Instructions describe the topic or purpose.

This makes a new requirement above the proposed SC, it requires authors to add instructions. What I think it is trying to say is:

If instructions are present, they describe the topic of purpose

I get if we want to hold things up to some higher standard for 2.1 than 2.0, but it is still a wee bit frustrating using the exact wording of an existing SC and having reasons listed for why that text is unacceptable :)

That said, your suggested change is fine. I'm also going to alter the text to make it more relevant to the topic and incorporate Alastair's error message (still trying to figure out how navigational elements isn't covered by labels).

Clear Instructions and Messages: If present, instructions and error messages describe the expected user action or issue.

I think Mike's is a good stab, and the idea to thereby create a hook to introduce various Coga concepts as Techniques a smart idea.
David, I do would not read the proposed SC handle "Clear Instructions" as requiring instructions but as something applying as soon as they are used, so I don't think the If-construct is necessary.
As to including navigation / links: It might be difficult to clearly draw the line between navigational elements (sitting in nav constructs) and links in general. 2.4.4 Link purpose seems to cover 'descriptive' for links as that is roughly the same as conveying "link purpose", and that applies also to links in navigational constructs that are often given context implicity by being part of a nav menu. For brevity, that is often a good thing, and asking navigation links to meet 2.4.9 Link Purpose (Link Only) would IMO often lead to bloat and a deteriation of usability.