- From: John Foliot <john.foliot@deque.com>
- Date: Mon, 20 Feb 2017 10:35:51 -0600
- To: EA Draffan <ead@ecs.soton.ac.uk>
- Cc: Michael Gower <michael.gower@ca.ibm.com>, "lisa.seeman" <lisa.seeman@zoho.com>, Gregg C Vanderheiden <greggvan@umd.edu>, public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org>, GLWAI Guidelines WG org <w3c-wai-gl@w3.org>
- Message-ID: <CAKdCpxw8LXX=NLYn3FSUv3zK4HwCLkqxxNw2Y9rPMwMvfdHuYg@mail.gmail.com>
> But simple words in "instructions, labels, navigational elements, and error messages which require a response to continue", would help us all! Hi EA, I couldn't agree more, which is why I am 'active' in this discussion. Yes, I am pushing hard for a real, measurable SC that we can advance that supports this need, which means I am also pushing back hard on vagaries and 'holes' that I am seeing now. I know I ask hard questions, and it may seem I am resisting this SC, but that is far from the case. If we collectively cannot answer the questions I am raising now, internally among our peers, then what will happen when we go out for wider review to non-experts? JF On Mon, Feb 20, 2017 at 10:24 AM, EA Draffan <ead@ecs.soton.ac.uk> wrote: > 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:l > isa.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:l > isa.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 > -- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com Advancing the mission of digital accessibility and inclusion
Received on Monday, 20 February 2017 16:36:30 UTC