Re: What should we do with a long success criteria?

good point

if all in one — and you miss one bit — you fail the SC

Also- as you point out-  each requirement is its own provision in a standard  

finally, you can’t do sufficient techniques for an SC like this unless the technique would satisfy all of the parts (which won’t be true for any technique I know of) 

Also - evaluation sheets -  advice - etc are all complicated 

gregg

> On Aug 8, 2016, at 2:36 PM, lisa.seeman <lisa.seeman@zoho.com> wrote:
> 
> Hi WCAG Folks
> 
> We have a long success criteria (3.3.3)
> 
> In other standards (such as ETSI) they each bullet point  as separate criteria in a section on the use of language. 
> We could do the same thing and add 11 success criteria, (and then add another 10 on the other long one).
> 
> An advantage of having them all in one success criteria are:
> 1. The wording enables a blanket exclusion for a lot of content - by saying "Instructions, labels, navigation and important information are provided with a clear writing style that includes". This excludes a lot of things like blogs etc. If we make each bullet point a separate success criteria we will need to reuse a lot of language and text.
> 2. We have exceptions that includes all the bullets at once - for example - the success criteria bulleted items may be replaced for a location or type of content were user testing has shown a more effective writing style to aid comprehension for people with cognitive disabilities. Such as for content written in a specific language.
> 2. They all belong together. And if you are using simple clear langage you are conforment to all the bullet points. So I think it makes it easier to conform and understand rather then braking them into separate items
> 
> 
> Disadvantage is it is a long list.  It realy is. We can make each item testable but it is still long.
> 
> SO - How would you suggest we handle it?
> 
> Here it is....
> 
> 3.3.3 Instructions, labels, navigation and important information <https://rawgit.com/w3c/coga/master/extension/index.html#dfn-important-information> are provided with a clear writing style that includes:§ <https://rawgit.com/w3c/coga/master/extension/index.html#instructions-labels-navigation-and-important-information-are-provided-with-a-clear-writing-style-that-includes>
> (simple text version: Use a clear writing style)
> 
> An easy to understand tense and voice. Please refer to the exemptions for changes for a defined scope such as a different location or language.
> The main task of each page is clarified though the presentation, main heading and page title. Extraneous information is separated or progmatically determinable.
> Use short clear sentences with a maximum of one conjunction and two commas.
> Choose words that are in general use for the context. Use word or phrase from the most commonly used 3000 words <https://rawgit.com/w3c/coga/master/extension/index.html#dfn-most-commonly-used-3000-words>, unless this will result in a loss of meaning. Note we may change the number
> Avoid hyphenated words and acronyms unless they are the common form to refer to the concept. -http://www.fltr.ucl.ac.be/fltr/germ/etan/bibs/vocab/cup.html <http://www.fltr.ucl.ac.be/fltr/germ/etan/bibs/vocab/cup.html>
> Clearly differentiate between facts and less substantiated opinions. Was rewritten from "Clearly differentiate between opinions and facts "
> Reduce ambiguities by:
> metaphors and non-literal text <https://rawgit.com/w3c/coga/master/extension/index.html#dfn-non-literal-text> are not used or can be automatically replaced via an easy to set user setting and standardized technique. All meaning must be retained when non-literal text <https://rawgit.com/w3c/coga/master/extension/index.html#dfn-non-literal-text> are replaced.
> identifying each step in instructions,
> using specific and concrete wording <https://rawgit.com/w3c/coga/master/extension/index.html#dfn-concrete-wording> in instructions,
> the meaning of each word should be clear from the word's context, or programmatically determinable.
> On controls, links and buttons use words that identify their function. Function can be
> the default term used for the function on the user platform or
> the function of the button or link (such as "search" in place of "go") or
> the destination of a link (such as "home" or "contact us")
> In menus with sub menus:
> the text of each main menu item is easy to understand.
> each sub menu item is clearly associated with the main menu item under which it falls (This can be due being an industry or platform default)
> Double negatives are not used
> A summary is provided. For pieces of content with less then 200 words the heading may act as a summary.
> Exemptions:
> 
> There are times when passive voicing or other tense can be clearer. Other voicing may be used when it has been shown via user test to be easier to understand, more friendly or appropriate.
> The present tense is not required when describing or discussing past or future events.
> If the writing style is an essential part of the main function of the site, such as a literary work.
> Where less common words are found in user testing to be easier to understand for the audience (user testing should included people with cognitive disabilities that could e in the target audience - need further definition )
> The writing style items may be replaced for a location or type of content were user testing has shown a more effective writing style to aid comprehension for people with cognitive disabilities. Such as for content written in a specific language.
> The content will be penalized for not conforming to a given writing style (such as a dissertation or PHD proposal) 
> 
>