Re: changes to plain language based on the feedback

Summary:

  +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?
​I​
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.

Which
​ 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...)

JF








On Mon, May 15, 2017 at 3:51 PM, White, Jason J <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]
> *Sent:* Monday, May 15, 2017 4:45 PM
> *To:* lisa.seeman <lisa.seeman@zoho.com>
> *Cc:* w3c-waI-gl@w3. org <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> 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
>
>
>
> Best
>
>
>
> Gregg
>
>
>
> 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.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion