Re: might be last option for plain language

I think this is the ISO9000 model isn't it? They certify that a process was
followed. I think it's interesting.

Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd

GitHub <https://github.com/DavidMacDonald>

www.Can-Adapt.com <http://www.can-adapt.com/>



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>

On Tue, May 16, 2017 at 1:57 PM, White, Jason J <jjwhite@ets.org> wrote:

> 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
>
>
>
> Hi
>
> 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 <john.foliot@deque.com>>* wrote ----
>
> 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
>
>
>
>
>
> ------------------------------
>
> 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.
> ------------------------------
>