Re: Plain Language / Support Personalization

> I thus deduce that the issue is that the button's label (above), far from being "uncommon", is, in fact, simplylacking context

Not quite, there is a wide distinction between common across the web, and lacking context. We are identifying less than 100 terms that are common/conventional, so “mode”is hardly common, especially in the domain of heating.

The use cases might blur the lines between “fixed vocabularie” and common names, but we cannot because the solutions and testing cannot.

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

I agree, but we need to separate general understanding from a fixed vocabulary. The Plain English concept can help in a more general (but harder to test) sense, but the conventional controls requires a fixed vocabulary. These two things need different solutions.

> (because the "intent" as outlined for Plain Language, references navigational elements, user interfaces, and instructions)

Then we need to clarify/ prioritise the use-cases, because the solutions are very different. Plain language means changing the visible content, programmatically available does not.


> 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”>

Sticking a title on common controls would be actively harmful for some people, such as low vision users for whom it can interfere, with little benefit. Extra help is most useful for the unconventional controls.


> I mentioned Plain Language in the subject line, as it WASa 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

Again, we need to separate ‘fixed taxonomy’ from extra explanation AND from ‘public word lists’, which are not ‘fixed’ in the sense of programmatically available.

A public word list is not ‘fixed’, you are having to declare which one you are using in order to test it. You cannot use such a list for associating icons. You can use it for settling arguments about how common a term is, which makes some sense for plain language.


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

I see these as separate, the need for extra explanation of ‘mode’ is valid, but different from saying that you should use a different term than mode.

Plain english would require you to look up the term in the list and say “use a different term”.

In this case, I don’t think you would find a consistent term for that concept in a word-list, so the ‘extra explanation’ aspect is more important.


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

Yep, I also see issues with testability/usefulness for word lists, but that is separate from a “fixed vocabulary” which has to be agreed in advance, speced, rather than open.


> So... while I agree that there is likely some space between the 2 emergent requirements,

There are 3 solutions though, as I listed above.

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

Yes, but that swapping for icons has to be pre-defined and consistent across sites, whereas ‘extra info’ that is custom to the site can be more open.

Cheers,

-Alastair