Re: Plain Language / Support Personalization

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