RE: Proposal for support personlization AA from John, Chris, Jan and myself

Picking up a thread of this discussion, which remains relevant following today’s meeting – see comments below.

From: Alastair Campbell [mailto:acampbell@nomensa.com]
Sent: Thursday, July 20, 2017 4:45 AM

> The fact that the AA requirement does so without requiring a "taxonomy" is important, because there is no taxonomy.

That isn’t really true, there is one now. There is a list of items (75 in three categories), so what is needed is refinement of that to a point that we’re happy to create sufficient techniques.

The list of “terms” is already there, it was in Lisa’s email. What I was suggesting was that a version of those terms & descriptions is created by either:

  *   Including it directly in WCAG 2.1 as part of that SC’s material, or
  *   Modularising coga-personalisation, and the first module is just the destination/action/field part. (Perhaps rename to “Accessibility Personalisation”, or something more general.)
[Jason] I think the first option is what Lisa had proposed as a definition of “common controls”. If we were to proceed with this option, we would need more descriptive and explanatory text characterizing each of the types of UI component covered by the definition. The short names are suggestive, but not good for inclusion in a definition; and they raise internationalization concerns regarding whether they would remain meaningful when WCAG is translated into other languages.
A list of “conventional UI components” should really be backed up by a survey of what controls are used across a variety of Web applications (i.e., it should have an empirical basis in research).
Your second approach is possible, but then mandating the use of a W3C personalization specification would violate the technology-independent nature of WCAG 2. Nowhere do we prescribe the use of any specific technology. This, for instance, is why 4.1.2 is written as it is, instead of referring to ARIA.
Thus I think a version of option 1 (or a tight definition of what kinds of UI components the proposal applies to) is the best path to take.
In general, there are two sources of substantial ambiguity in the proposal currently under discussion:

  1.  Lack of clarity regarding what information is required to be provided by the content author, and which aspects of this information need to be given in a formal language such as the terms of a taxonomy, rather than in a natural (human) language. What ought to be provided has been described in broad terms such as what a control does, how to interact with it, or what its effect is.
  2.  Lack of clarity regarding the definition of “conventional controls” (the issue that I treated above).
I think the second problem can be solved by careful work on definitions. The first issue can be addressed too, but it isn’t easy. As I suggested during the meeting, modifying 3.3.2 would seem to solve part of the problem. There was also mention of modifying 3.3.5, but I didn’t catch what the proposed change would be. This would take care of the “natural language” component. Then we could try to define what ought to be “programmatically determined” (i.e., the formal taxonomy component).


________________________________

This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.


Thank you for your compliance.

________________________________