Plain Language / Support Personalization

Hi All,

Thinking through these two (related) proposed SC, I personally keep
struggling with how they are evolving.

Stepping back a bit, and re-reading the Description and Intent of these 2
Proposed SC, I tried taking a stab at expressing the requirements using a
user-story. I'd like to test out that user-story on-list, to see if *I* am
understanding what is being sought in these two draft SC. (I've also taken
a go on where I believe the requirements might fall within our A/AA/AAA
structure).
Here is where I arrived:

*As a User with comprehension issues associated to language (terms and
usage), I require the ability to:*


   - *easily determine or access the definition or explanation of terms and
   words used on 'critical' (conventional?) controls and input labels (AA)*




*(where those conventional controls and inputs are enumerated in the SC -
   such as this working draft:
   https://rawgit.com/w3c/wcag21/support-personalization_ISSUE-6/guidelines/sc/21/support-personalization-minimum.html
   <https://rawgit.com/w3c/wcag21/support-personalization_ISSUE-6/guidelines/sc/21/support-personalization-minimum.html>)
   *
   - *easily find or access extended help explanations or support for
   inputs, controls, and error messages (AA or AAA - I'm not sure)*

   *(I recognize that this is not the same as using simpler terms, however
   the use-case provided in *Plain language (Minimum)
   <https://github.com/w3c/wcag21/issues/30>*, which references the
   instance when a button labelled "Mode" was incomprehensible to a user,
   would not be addressed by a "word-frequency" list, as I would argue that
   the term "Mode" is in fact fairly common. In the example provided, it
   wasn't so much that the term "Mode" was inappropriate or "complex", but
   that there was no additional contextual information about what "Mode" meant
   on the UI of the thermostat.)*

   - *convert common (conventional?) terms and instructions to other modes
   of expression (eg. convert form control labels to symbols) (AAA)*

Techniques:

*All techniques required to meet these needs will require a programmatic
association of the supplemental/augmented information to the impact content
(controls, inputs, help-messages, etc.). *


Personally, I believe that for all of the above requirements, the use of
the emergent Coga Semantics will be the most robust solution going forward.

However in the here-and-now, to publish a AA SC I believe that we must
require that at least one solution (Technique) can be brought forward today
that uses *existing technologies*, even if *those* solutions only get us to
the minimal functional requirement.

So, for example, in the "Mode" button scenario provided above, a minimum
solution would be to use the @title attribute to provide a prose
'explanation' around that 'control':


<button title="Switch between Cooling and Heating">Mode</button>

This may not solve all issues for all users, but I believe that it does get
us closer to addressing one of the functional problems
​ articulated in the user-story​
: providing more contextual help on a specific control. (Additionally,
because Coga Semantics could be the best solution to this problem, we can
take this scenario and leverage it into a teachable moment to drive home
that fact
​.)​


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? (If
the first answer is yes, then I will suggest the second answer today is no.)

*My* ultimate desire is to establish requirements where it becomes obvious
that using Coga Semantics is the most robust solution to the content
creator, but that at AA today they can use other techniques to be in
compliance.

This mirrors (I will argue) the same way we advanced ARIA into/through WCAG
2.0: there is no explicit requirement to use ARIA to meet any of the 2.0
SC, but gosh-darn-it there are a lot of those SC that can be addressed
robustly (and often easily) *if* you used ARIA, and so... (This is an
attempt to address the chicken and egg problem with Coga Semantics today).

I recognize that we are also working towards a fast-approaching deadline,
and I truly want to see these SC (or variants of them) make the cut. To
help meet that goal, I want to ensure I fully understand what our end-game
is, which is why I am writing this today.

Am I correctly understanding the problem space?

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

Advancing the mission of digital accessibility and inclusion