W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2017

RE: might be last option for plain language

From: White, Jason J <jjwhite@ets.org>
Date: Tue, 16 May 2017 17:57:56 +0000
To: lisa.seeman <lisa.seeman@zoho.com>, John Foliot <john.foliot@deque.com>
CC: Gregg C Vanderheiden <greggvan@umd.edu>, "w3c-waI-gl@w3. org" <w3c-wai-gl@w3.org>, public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org>
Message-ID: <BN6PR07MB345726C71C0F0F5871C73B96ABE60@BN6PR07MB3457.namprd07.prod.outlook.com>
I think we’ll probably have to recognize that some important accessibility issues that content authors need to address won’t fit well, or at all, into the WCAG 2 model of carefully specified, true/false, reliably testable success criteria describing the content.

For Silver, we should look at alternatives, whether in the form of design process requirements or of other ways of defining conformance that can deal with issues which don’t lend themselves to the WCAG 2 conformance model.

For example, “write in clear and simple language” is good advice, hard to specify precisely, but valuable if followed. If there’s a way to acknowledge that someone made design/implementation/writing decisions differently because they followed this advice (i.e., they wrote their content with this in mind) in the context of a conformance scheme, without imposing a pass/fail judgment on the content itself, I think we should explore it. Someone can take concrete actions (consult vocabulary lists, pay attention to grammatical complexity, and make thoughtful decisions in writing their content) that are likely to result in its being clearer and simpler than it would otherwise have been. I think we need to look at ways of acknowledging good accessibility-aware design processes in cases where there are no precise, testable criteria for the content itself. In other words, one way in which content can conform (with respect to certain requirements) would be in having been designed/written/implemented according to a process that meets reliably testable quality criteria. The authors took relevant considerations into account, which had a material impact on their design choices. They evaluated it with suitable tools/assistive technologies and addressed the issues they found, etc.

I know the above is a little speculative, but various issues are placing a lot of pressure on the WCAG 2 approach to conformance and success criteria. We need to investigate whether there are better ways of addressing these issues in the next major version. We may have to acknowledge that some issues simply won’t be addressed until then.

From: lisa.seeman [mailto:lisa.seeman@zoho.com]
Sent: Tuesday, May 16, 2017 1:35 PM
To: John Foliot <john.foliot@deque.com>
Cc: White, Jason J <jjwhite@ets.org>; Gregg C Vanderheiden <greggvan@umd.edu>; w3c-waI-gl@w3. org <w3c-wai-gl@w3.org>; public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org>
Subject: might be last option for plain language

we have at working draft semantics for personlization like coga-action and coga-easylang that would alow people to conform to the plain language proposal via personlization ( see https://w3c.github.io/personalization-semantics )

I understood from this group that they do not want to rely on this for conformance, however with the plain language sc as written you can either change the text or use the personlization semantics.  In other words the free speach is not an issue

Does this seem to be a way forward?

All the best

Lisa Seeman

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

---- On Tue, 16 May 2017 16:24:01 +0300 John Foliot<john.foliot@deque.com<mailto:john.foliot@deque.com>> wrote ----

  +1 support for the tightened scope
  -1 for "word lists" (Common Words)
  -1 for "easy-to-set user setting."

Details follow.


Hi Lisa, COGA TF members,

I strongly agree with the tightened scope to error messages, instructions, labels and navigational elements, although like others I think we need to tighten / supply a definition for "navigational elements", as in the abstract *any* link can be used for "navigation".

Do you actually mean content used in a 'menu'? In other words, instead of "navigational elements" perhaps "navigational menus" or "navigational menu items" (with a note in the Understanding prose that states that in HTML, menu is defined as content contained within either the <nav> element, or a container with role="navigation" applied)?  I suspect however that this is a minor and trivial point.

At the risk of this feeling like another pile-on however...

Common Words

> Provide words or phrases from a public core vocabulary

Provide how? Where?
n any specific format?
​ For what purpose?
A "word list" minus definitions is simply a list of 1500 words...​

As Gregg notes, myself and others have questioned the mechanics of this in a practical sense, and we're simply not at a point technologically t​o make this useful. For example the Draft, and your explanation further states:

​> Also using the coga-simplelang  attribute will allow people to keep uncommon words and allow AT to replace them.

While I share the enthusiasm of the work happening around the Proposal: COGA Semantics to Enable Personalization<https://w3c.github.io/personalization-semantics/>, we must accept today that this is still but a proposal, and not yet at the point where it is a stable, implementable W3C technology. Referencing it as a potential solution is optimistic, and additionally I think that is more appropriate in the Techniques section, but until such time as we have (two independent) robust implementations of the proposal, it remains simply an interesting and useful work in progress.

> Non-literal language is not used, or can be automatically replaced, via an easy-to-set user setting.

​ easy-to-set setting are you referring to?​ I am unaware of this feature in any commercial browser today, and while I think we all want browsers to do a better job in personalization and granular user-settings, the reality is that this is and will remain a user-agent requirement, and not an authoring requirement (unless the intent here is to force authors to create that easy-to-set setting, which I suspect will receive a TON of push-back).

​This is not to say​ that we should ignore the need for Non-literal language (especially in the context of the tightened scope), but I think we need to drop the exception for now as unworkable and unsupported.

I think we can safely say that (for) error messages, instructions, labels and navigational (menu) elements, (they) must not use non-literal language. (Period. And ensure that a definition exists for non-literal language.)

While testing for this requirement will still require some subjective determination (at the same level of determining whether an 'alt text' is appropriate or not), I will suggest that I think that would be an acceptable 'middle-ground' response, especially if/when we provide a good definition and examples of non-literal versus literal language. (i.e. saying that "it is raining cats and dogs" does not mean that animals are falling from the sky...)


On Mon, May 15, 2017 at 3:51 PM, White, Jason J <jjwhite@ets.org<mailto:jjwhite@ets.org>> wrote:
I agree with Gregg. Much as I wish it were otherwise, the sensitivity of this formulation to context is both necessary and disastrous to the testability of the proposal.

From: Gregg C Vanderheiden [mailto:greggvan@umd.edu<mailto:greggvan@umd.edu>]
Sent: Monday, May 15, 2017 4:45 PM
To: lisa.seeman <lisa.seeman@zoho.com<mailto:lisa.seeman@zoho.com>>
Cc: w3c-waI-gl@w3. org <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Subject: Re: changes to plain language based on the feedback

On May 15, 2017, at 2:47 PM, lisa.seeman <lisa.seeman@zoho.com<mailto:lisa.seeman@zoho.com>> wrote:

Common words
Provide words or phrases from a public core vocabulary; or the most common 1500 words or phrases (including word roots); or word, phrases or abbreviations that are the most-common form to refer to the concept in a public word frequency list for the identified context.

I do not think that this is possible.  I have spent year looking at this first in the 1990s and again in 2000’s.   I love the idea but see no way to do it.     It just isnt feasible.

There have been a number of other posting saying the same.

I have seen no answer to any of these postings that leads me to believe that there was any answer to the questions and problems raised.

Until there is — not matter how nice this would be — we cannot have a provision that is based on wishes and not reality.

Sorry to be blunt — but unless you can show that most any site provided to you can be reworded by an average web author into one that can meet this — we cannot have such a provision at any level other than AAA.

I know that this does not apply to the whole site - but only to

  *   error messages that require a response to continue,
  *   instructions,
  *   labels and
  *   navigational elements
But even those elements use words that are outside of any 1500 word vocabulary

If we are going to put something like this forward we should be able to show how it can be done on any page
For a sample to start with - try rewording all of those elements on these

  *   amazon
  *   a banking website
  *   WebMD
  *   W3C



PS  also need a definition of Navigation elements?   Does this include Links?


This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.

Thank you for your compliance.


John Foliot
Principal Accessibility Strategist
Deque Systems Inc.

Advancing the mission of digital accessibility and inclusion


This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.

Thank you for your compliance.

Received on Tuesday, 16 May 2017 17:58:34 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 21:08:13 UTC