Re: Plain Language / Support Personalization

Hi Alastair,

Re: Plain Language - maybe I'm missing something else, but when I go to
reference the Github Issue for Plain Language
<https://github.com/w3c/wcag21/issues/30>, it states:


   The intent of this success criterion is to ensure people can understand
   and use navigational elements, user interfaces, and instructions. Clear
   language for all content is an important accessibility principle. However,
   if the user does not understand words and terms in these critical areas,
   the whole application or web site often becomes unusable.

   A real-life example is a person, with mild dementia, trying to use an
   application to turn on a heating and air conditioning unit. The menu item
   for selecting heat or air conditioning is labeled "mode". The user does
   not know that "mode" refers to heat or to air conditioning, and thus cannot
   use the whole unit because of this one term.

I thus deduce that the issue is that the button's label (above), far from
being "uncommon", is, in fact, simply *lacking context *(and the referenced
text above is also why I included Plain Language in the Subject Line, as
that is where the quote is derived from).

My concern is that surfacing a "common words list" (in-and-of-itself) is
not solving the problem statement (user did not understand that Mode =
switch between cooling and heating).

Arriving there, I then ask myself "how could we address that problem
statement?" and the possible solutions that come to mind are almost
identical to those we have discussed regarding Personalization / Purpose Of
Controls (because the "intent" as outlined for Plain Language,
references navigational
elements, user interfaces, and instructions)

You wrote:


I saw the use-cases as:



   1. Easily identify *common*/conventional controls (either by using the
   conventional term, conventional description, or including the conventional
   name programmatically so icons can be associated by AT).

   2. Easily get an extended description of *uncommon*/conventional
   controls (a visible or visible-on-demand explanation in text).

   3. Important *text* (headings, instructions etc.) is written in plain
   language.


I see a bit of a conceptual difference between us, albeit slight. For #1
(*common* as opposed to *uncommon* controls) I would (personally) also be
satisfied to get an extended description (i.e. that is an acceptable, if
baseline-minimal-way of meeting the problem statement - something your
sample code alludes to here):

<label for=”input1”>Your Family Name</label><input type=”text”
id=”field1” *title=”Family
name, surname, or last name”*>


(in other words, for your Use Case #1, using @title would also be a success
technique)

I mentioned Plain Language in the subject line, as it WAS a topic of
discussion <https://www.w3.org/2017/08/03-ag-minutes.html#item02> on
Thursday's call, and as we discuss the user need, to my mind it again comes
down to using something of a fixed taxonomy: simply providing a "public
word list" does not (I argue) in-and-of-itself solve any problem, because
(again) "Mode" is, and would be, a common word used on many applications
where a configuration switch to change from one "mode" to another would be
offered. What is actually required (to my mind) is a "list" of both words
AND what they mean (another set of pairs - a taxonomy).

You offered a 3rd use case:

3. Important *text* (headings, instructions etc.) is written in plain
language.


...which is in scope for "Plain Language" (although the user-story there,
the one about the "Mode" button, is not the right story to illustrate the
need for headings, but *could* be rolled into the "instructions" bit of
your use-cases 1 & 2, when we use techniques like @title - and I am sorry
if I seem fixated on that attribute...)

Even here however, the Plain Language SC is ultimately asking for a "public
word list"

<lisa> Use the most common 1500 words or phrases or, provide words, phrases
or abbreviations that are the most-common form to refer to the concept in
the identified context.


...but without any clear indication of how that word list would be
associated to the page/content in question (and so here there are a tonne
of testing issues), nor how using that common word list helps solve any
problem (as, again, "Mode" would likely show up on a common word list for
control switches).

So... while I agree that there is likely some space between the 2 emergent
requirements, I don't think it is as wide as others may think, as
ultimately, in all of the use cases you brought forward, the 'need' could
be summed up in "I need more context/information to understand what to do
with this thing" (which *could* potentially be addressed in some instances
by swapping text for icons).

Is this making sense?

JF

On Fri, Aug 4, 2017 at 4:50 AM, Alastair Campbell <acampbell@nomensa.com>
wrote:

> Hi John,
>
>
>
> The ‘plain language’ was included in the subject line, but I don’t think
> you covered it in the listing?
>
>
>
> I saw the use-cases as:
>
>
>
>    1. Easily identify *common*/conventional controls (either by using the
>    conventional term, conventional description, or including the conventional
>    name programmatically so icons can be associated by AT).
>
>    2. Easily get an extended description of *uncommon*/conventional
>    controls (a visible or visible-on-demand explanation in text).
>
>    3. Important *text* (headings, instructions etc.) is written in plain
>    language.
>
>
>
> So those equate to:
>
>    1. Purpose of controls #6
>    2. Updates to 3.3.2/3.3.5 (I think, we discussed that on the call
>    focused on SC)
>    3. Plain language (#30 / #41)
>
>
>
> The difference between 1 & 2 is that WCAG provides the terms for
> conventional controls, but 2 is for non-conventional controls.
>
>
>
> I missed the end of the call yesterday, but it doesn’t look like we got to
> purpose of controls?
>
>
>
> Since the purpose-of-controls call we’ve moved to name/description pairs
> for at least some of the items:
>
> https://rawgit.com/w3c/wcag21/support-personalization_ISSUE-
> 6/guidelines/sc/21/support-personalization-minimum.html
>
>
>
> E.g.
>
> name                     | “Full name”,
>
> family-name         | “Family name, surname, or last name”
>
>
>
> I thought it would be worth providing a few examples that would be
> sufficient techniques to see if we agree?
>
>
>
> So for purpose of controls where “….the conventional name of conventional
> user interface components can be programmatically determined.”
>
>
>
> I’m suggesting all of these would pass for ‘family-name’, I’ll use bold to
> highlight the key element in each case hopefully that comes through:
>
>
>
> <label for=”input1”>Your Family Name</label><input type=”text” id=”field1” *title=”Family
> name, surname, or last name”*>
>
>
>
> <label for=”input1”>Your Family Name</label><input type=”text” id=”field1”
> *title=”family-name”*>
>
>
>
> <label for=”input1”>Your Family Name</label><input type=”text” id=”field1”
> *pref-field=”family-name”*>
>
> (This is currently: <label for=”input1”>Your Family Name</label><input
> type=”text” id=”field1” *coga-field=”family-name”*>)
>
>
>
> <label for=”input1”>*Family name, surname, or last name*</label><input
> type=”text” id=”field1”>
>
>
>
> <label for=”input1”>Your Family Name</label><input type=”text” id=”field1”
> *aria-describedby=”famname”*>
> <p class=”hidden-or-not” id=”famname”> Family name, surname, or last
> name</p>
>
>
>
>
>
> These are all in the category of identifying conventional controls from
> the set listed in the SC definition, either by the token (i.e.
> “family-name” which would be the same across languages) *OR* the
> description, which would need translating.
>
>
>
> For this example:
>
> <button title="Switch between Cooling and Heating">Mode</button>
>
>
>
> I thought we were talking about updating 3.3.2/3.3.5 to cover that
> use-case?
>
>
>
> We should have a non-title attribute method of achieving that as well, so
> we could allow for something like:
>
> <button aria-describedby=”desc”>Mode</button>
> <a href=”#” id=”desc” class=”show-when-selected”>Switch between Cooling
> and Heating</a>
>
>
>
>
>
> > And so... my question is, do I understand the use-case(s) correctly
> here? If yes, then are the emergent SC addressing those use-cases properly?
>
>
>
> I would differentiate “conventional controls” from “extra descriptions”
> more, because they have different solutions.
>
>
>
> Of course, I’m in the same position of trying to understand this
> second-hand, so I’m very open to Lisa correcting either/both of us!
>
>
>
> -Alastair
>



-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion