RE: proposed change for simple words in labels etc.

I think the idea of an easy-to-read or coga-easylang tag is the best option as there are many languages that do not have large word frequency lists and they are all very dependent on the era in which they were collected and the setting as Gregg suggested.  But simple words in "instructions, labels, navigational elements, and error messages which require a response to continue", would help us all!

Best wishes
E.A.

Mrs E.A. Draffan
WAIS, ECS , University of Southampton
Mobile +44 (0)7976 289103
http://access.ecs.soton.ac.uk<http://access.ecs.soton.ac.uk/>
UK AAATE rep http://www.aaate.net/


________________________________
From: John Foliot [john.foliot@deque.com]
Sent: 20 February 2017 16:06
To: Michael Gower
Cc: lisa.seeman; Gregg C Vanderheiden; public-cognitive-a11y-tf; GLWAI Guidelines WG org
Subject: Re: proposed change for simple words in labels etc.

> What happens with multi-language pages - is it 1500 words per language present?

I continue to have serious reservations here around internationalization: this proposed SC currently feels very "western-centric" in its approach.

Mike Pluke previously noted 5 languages (English, French, German, Italian and Spanish), but what of other languages? (and which "Spanish"?) What of Asian-based languages (Japanese, Chinese, Korean, etc.) or Russian, Arabic or Hebrew languages (to name a few others)? How does this proposed SC scale there?

As others have noted as well, which 1500 words (or phrases) are we using as *The Standard*? Is the intent to leave that list undefined at this time? Why?

What happens when variants of a language 'conflict'? (For example, in North America a car has a "trunk" and runs on "gas", while in the UK an automobile has a "boot" and runs on "petrol".. which of those words makes the 1500-word list? The US version, the UK version, both, or neither?)

My fear is that in an effort to be effective here, we are also being overly prescriptive. Additionally, while I look forward to future technologies assisting us with this need, reliance on them for the proposed SC is counter to how we should be writing SC - as Gregg notes both members of this WG as well as non-experts need to be able to use our emergent WCAG 2.1 to actually test WCAG 2.1 in a measurable and repeatable fashion today.

We need to be standardizing Requirements and Success Criteria, not specific solutions attached to hard-to-define variables.

JF

On Mon, Feb 20, 2017 at 8:32 AM, Michael Gower <michael.gower@ca.ibm.com<mailto:michael.gower@ca.ibm.com>> wrote:
Although the issue was closed in github, I've put more comments on this topic there since the context is clearer and discussion has been ongoing
https://github.com/w3c/wcag21/issues/30
Michael Gower
IBM Accessibility
Research

1803 Douglas Street, Victoria, BC  V8T 5C3
gowerm@ca.ibm.com<mailto:gowerm@ca.ibm.com>
voice: (250) 220-1146<tel:(250)%20220-1146> * cel: (250) 661-0098<tel:(250)%20661-0098> *  fax: (250) 220-8034<tel:(250)%20220-8034>



From:        "lisa.seeman" <lisa.seeman@zoho.com<mailto:lisa.seeman@zoho.com>>
To:        Gregg C Vanderheiden <greggvan@umd.edu<mailto:greggvan@umd.edu>>
Cc:        "public-cognitive-a11y-tf" <public-cognitive-a11y-tf@w3.org<mailto:public-cognitive-a11y-tf@w3.org>>, "GLWAI Guidelines WG org" <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Date:        2017-02-20 05:48 AM
Subject:        Re: proposed change for simple words in labels etc.
________________________________



Thank you Gregg. I think we are getting closer

Note that the Sc is only for instructions, labels, navigational elements, and error messages which require a response to continue.

SO there is no need to build a whole website along these lines. (That would only be a AAA conformance level)

 Also if  you can comply by using a title tag or coga-easylang, will make it much easier and less restrictive

I agree we will need a better term or clear definition of current context. hopefully then we will get there.

Any suggestions for reworking the current context part?

All the best

Lisa Seeman

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




---- On Sun, 19 Feb 2017 19:40:13 +0200 Gregg C Vanderheiden<greggvan@umd.edu<mailto:greggvan@umd.edu>>wrote ----

  *   Simple, clear, and common words:Use the the most common 1500 words or phrases or, provide words, phrases or abbreviations that are the are most-common form to refer to the concept in the current context.


This is a very interesting definition.  By adding context — it makes content self adjust.   For example — a physics site could have physics terms on it - which would clearly not be plain language.

My only concern as an author would be that several key things are not defined.

1)  what does “current context” mean.      If my website is the current context — it means everything passes because those are the terms in my context.    If the context is ‘science websites’  then I do not know what the most common terms are for them — nor do I know what the definition of ‘science website’ is.   (That is — if you define current context as being X context  then  X needs to be defined — and I need to know what the common words are for that context.

2) the most common 1500 words includes lots of prepositions, and articles  (Most or all of them)  but only a small percentage of nouns.    Very hard to write a website with only the most common 1500 words.    (I did word frequency studies in my earlier years)


I think the approach is clever — but still leads to an untestable SC since there is no way for the author  (or for testers) to know what “current context” means.         (and you can’t write WCAG with the most common 1500 words)


Gregg C Vanderheiden
greggvan@umd.edu<mailto:greggvan@umd.edu>



On Feb 19, 2017, at 3:33 AM, lisa.seeman <lisa.seeman@zoho.com<mailto:lisa.seeman@zoho.com>> wrote:

Hi Folks

Continuing the conversation on simple language, to address concern with testability (as user testing is not acceptable)  I want to suggest the following change to the clause on common words:

Change:

  *   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.

to:
  *   Simple, clear, and common words:Use the the most common 1500 words or phrases or, provide words, phrases or abbreviations that are the are most-common form to refer to the concept in the current context.


The scope is instructions, labels, navigational elements, and error messages which require a response to continue.

 Technique would include:
     *   Using a title tag to provide a simple language equivalent
     *   Using the coga-easylang attribute (prefered)
     *   Providing extra text via personalization semantics.
     *   Using simple words
Technology support includes: word frequency generator for a given context, (reads the URI's list and generates a word frequency list), existing word frequency lists, checker to test that words are in the most

There are also a list of exceptions that is quite long - issues 30 - and we are proposing to add a exception for long instructions (as per previous email) We could add an exception for user testing, but amazingly that is controversial.

The thinking is: the most common 1500 words is really trivial for testing tools to find and generate a warning. However using the most comment form to refer to something in the current context will, in this scope , take care of  the clarity issue and is also  testable with the tools above.

please do not bring up issues that are addressed in the exceptions or are out of the scope.



All the best

Lisa Seeman

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









--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com<mailto:john.foliot@deque.com>

Advancing the mission of digital accessibility and inclusion

Received on Monday, 20 February 2017 16:25:30 UTC