Re: Rolling the personalization SC into 4.1.2

Sorry for the long email, the summary is:

The current personalisation SC is actually quite narrow in scope, and appears to be fairly easy to implement and test (please see the details below).
I think it would be better to focus on the meta-data aspect (following a 4.1.2 approach), but the main hole is whether there is any technology to use the meta-data in the next couple of years.


David wrote:
> I thought pertinent to that conversation is the early COGA proposal to modify 4.1.2, which was done in conjunction with Rich Schwerdtfeger. https://github.com/w3c/wcag21/issues/22


I also made the argument to put under/with 4.1.2, Lisa pointed out it would need to be re-written to work for the COGA use-case. I think it got pushed aside due to the “no editing current SCs” in this part of the 2.1 process.

Personally I would prefer to take a 4.1.2 style approach, such as:
“Contextual information: Where a defined vocabulary is available, contextual information can be programmatically determined for sections and controls.” [1]

(NB: I think this could also be used to say that ARIA landmarks are required without re-scoping current SCs.)

However, if we take the current route of having a mechanism OR meta-data, the current proposal is quite constrained and testable. From the call yesterday I think there are some mis-understandings about the current proposal.

I would suggest a re-wording to simplify it, such as:
“Common navigation elements, common form elements and common interactive controls can be personalised by:
- a mechanism that enables the user to add symbols OR
- contextual information that can be programmatically determined.”

There are three lists of things (included in the definitions) which map to the pre-defined (testable, ARIA style) coga-personalisation spec:

Form elements: name (corresponds to both first and family), first name, family name, initial, phone (corresponds to a user phone number), cell phone, address 1, city, state… [2]
Interactive controls: compose, delete, next, previous, submit, undo, cancel, buy, add label, move, view, save, send… [3]
Navigation elements: home, contact us, our phone, our email, site map, help, about us… [4]

This is basically ARIA landmarks ++.

There is some argument discussion to be had on the details of those, but it is clear to me how to implement. I would not want to add the work of creating a personalisation mechanism so I would add meta-data like so:

<a href=”/” coga-destination=”home”>Home</a>

(Or “pref-destination” was acceptable to Rich Schwerdtfeger as something not limited to one user group.)

Then the user could have a browser/extension that shows icons on mouseover like this demo:
https://www.widgit.com/support/insite/index.htm (which works on all text, but I’m assuming it would be only items with personalisation meta-data in this context.)

I don’t see the argument that the title attribute is a loophole, as the same argument applies to 4.1.2. That uses “programmatically determined”, and does NOT specify a vocabulary. It relies on the definitions of ‘name’ and ‘role’, but it is the bazillion sufficient techniques that enforce ARIA as the spec to use.

This proposal defines ‘contextual’, and we can discuss the details of that, but it is the same principle as 4.1.2.

This SC has been refined and refined, and I think is quite reasonable from a testability and website implementation point of view now.

The one remaining objection (for me anyway) is whether there is user-side technology to do something with the meta-data.
I appreciate the chicken & egg situation we’re in, on the low vision side we have a similar problem but there are at least two projects working on browser extensions that do what we need, plus scripts we can use for testing.

Lisa: Are there any projects underway to make use of this? Otherwise we’re in a situation of saying to people: implement this, but no one can use it yet.

I also agree with Chris’ point that if we specify that creating a mechanism is a good way to pass this, then all manner of terrible implementations will be created and it will probably do more harm than good.

Lisa, I think the motivation for the first bullet was so that things like PDFs could have alternative content versions, but given the narrower scope of the current SC, is that still a concern? (PDFs with navigation & forms are generally a disaster anyway?!)

I suggest (again focusing on the meta-data aspect, either with the one I proposed above, or something like:
“For common navigation elements, common form elements and common interactive controls contextual information can be programmatically determined.”

Cheers,

-Alastair

1] https://lists.w3.org/Archives/Public/w3c-wai-gl/2017JulSep/0005.html

2] https://rawgit.com/w3c/wcag21/support-personalization_ISSUE-6/guidelines/terms/21/common-form-elements.html

3] https://rawgit.com/w3c/wcag21/support-personalization_ISSUE-6/guidelines/terms/21/common-interactive-controls.html

4] https://rawgit.com/w3c/wcag21/support-personalization_ISSUE-6/guidelines/terms/21/common-navigation-elements.html