Skip to content
This repository has been archived by the owner on Jun 30, 2018. It is now read-only.

Plain language (Enhanced) #41

Closed
lseeman opened this issue Nov 27, 2016 · 8 comments
Closed

Plain language (Enhanced) #41

lseeman opened this issue Nov 27, 2016 · 8 comments

Comments

@lseeman
Copy link
Contributor

lseeman commented Nov 27, 2016

Current versions of SC and Definitions


Not the discussion for AA is at issue #30
Full proposal is at Plain language AA
Note we have been asked:

  • not to worry about formatting at this point.
  • Testability is to show that the proposed success criteria is potentially testable rather than be intended as rigorous test

More information and explanations are available on request.

@DavidMacDonald
Copy link
Contributor

Seems to be a duplicate of #30

@lseeman
Copy link
Contributor Author

lseeman commented Dec 2, 2016 via email

@lseeman lseeman changed the title Plain language (AA) Plain language (Enhanced) Dec 14, 2016
@joshueoconnor
Copy link
Contributor

Assigned to Jim Smith (@jim-work) https://www.w3.org/WAI/GL/wiki/SC_Managers_Phase1

@joshueoconnor
Copy link
Contributor

@jim-work Is there a PR ready to go for this?

@jspellman
Copy link

This is difficult to measure and to implement. I recommend looking at using reading level. It isn't perfect, but it addresses most of the user needs identified, especially when paired with existing Technique G153. Reading level has international support, it has automated tests, and it has a variety of formulas (Flesh-Kincaid is the oldest and best known, there are many others.)

Proposed revision:
Understandable Instructions: Headings, error messages and instructions for completing tasks do not require reading ability greater than lower secondary education level. (AA)

[link to WCAG’s definition of lower secondary level from UNESCO standard]
Techniques should include G153 Making text Easier to Read.

@lseeman
Copy link
Contributor Author

lseeman commented Feb 15, 2017

Hi Jeane. This has been fully addressed both on the coga thread and in the A version. As you know the revision does not to the task we need as reading levels make it easier to read but NOT easier to understand. Each statement is fully testable and although the accessibility tools do not currently address this issue, tools are easy to make and already exist in other industries.

@cstrobbe
Copy link

This proposal has many of the same issues as #30. Should I repeat them here?

With regard to the wording of the first sentence: this should be worded as a characteristic of the content instead of an instruction to web content authors, e.g.:

Plain language (enhanced): Headings, error messages and important information use language that fulfils the following criteria: (...)

I left out terms like "plain", "clear" and "simple" since these terms are vague (in the absence of definitions) and the actual criteria are expressed in the bullet points. However, if the plan is to have several SCs about plain language, the SC can also be worded as "Headings, error messages and important information use plan language", where "plain language" links to a normative definition that contains the bullet points.

@eadraffan
Copy link

I have read some of the comments on the review about the lack of examples of core vocabularies. Those using Augmentative and Alternative forms of communication depend on core vocabularies in their own language and there have been several versions of these types of vocabularies developed in many languages. These lists are often made up of function words that can be used as alternatives to complex words that might link important /specialist words which are usually nouns in all languages. These lists have been collected by professionals working in the field and it should be possible to collate samples.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

8 participants