Re: Rolling the personalization SC into 4.1.2

Hi John,

I think we agree the SC should refer to a pre-determined taxonomy, and it should be possible to fulfil with metadata attributes and/or HTML tags.

The latest SC (and my recent suggestions) specifically apply to navigation elements, form controls and interactive controls which are each a fixed list of items. They map to parts of the coga-personalisation spec (coga-action/destination/field) that also use a fixed list of terms.

Therefore the SC does use a fixed taxonomy, we just need to pin down the definitions and how to reference it… Which I think will be continued in the other thread.

Cheers,

-Alastair


From: John Foliot <john.foliot@deque.com>
Date: Tuesday, 18 July 2017 at 14:36
To: Alastair Campbell <acampbell@nomensa.com>
Cc: WCAG <w3c-wai-gl@w3.org>
Subject: Re: Rolling the personalization SC into 4.1.2

Hi Alastair,

> I’m wondering if this is a change without a difference, because technically tags are metadata as well, but I assume you mean that it must use particular attributes?

Actually, not really, but rather it's the values of any given "attribute" that is important here (@attribute="[value string]").

The intent of this success cryteria [SC manager, please note this spelling issue - thanks] is to support user preferences or needs of the user. For example, having familiar terms and symbols is key to being able to use the web. However what is familiar for one user may be new for another requiring them to learn new symbols. Personalization could include loading a set of symbols that is appropriate for the specific user, ensuring that all users find the icons simple and familiar.

To be able to perform the "transformation" that this SC is seeking for "personalization" we need to be working with a fixed value list (taxonomy). Yes, the native semantics of HTML represents a fixed taxonomy as well (I don't think I said it didn't), but what is important is that both author and software are working from the same fixed list - that's the key to getting the bulk of what I believe COGA is seeking with this 'Personalization' SC accomplished. The fixed list needs to be predictable going in.

In other words, if a plugin or other software helper tool  is to replace "common navigational elements" with icons/images, we need to know when to use "home.png" (home.ico?) - unless you are suggesting that a random string of text can then be processed using AI to determine that not only will coga-destination="home" take the user to the home-page, but so would coga-destination="自宅" or coga-destination="entrée" (and not to beat a dead horse, but please tell me how <a href="/" title="自宅"> would not pass the current SC language as currently written?). And since at this time the coga semantics spec is still in draft, and a reading of that draft today shows significant gaps still to be filled, I am unclear how else we could achieve the goal today (outside of using other predetermined 'lookup lists' - perhaps something from schema.org<http://schema.org>, or Dublin Core?).

(I note as well that this was one of the drivers for native landmark roles in HTML5; after Hixie did his famous Google crawl and he noticed how many times he saw the non-semantic <div="nav"> that he created the now semantic <nav> element {etc., etc.}. I will argue it's essentially the same problem space - turning something from 'randomly labelled' into 'predictably tagged', which is how I've distilled this SC down.)

JF

On Mon, Jul 17, 2017 at 4:33 PM, Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>> wrote:
John wrote:
> I believe what is *truly* required is "contextual information SUPPLIED as metadata", so that machines can parse and adapt to that data (ergo - personalize).
…
> which is why I would favor a direct, not-beating-around-the-bushes SC that explicitly calls for the provision of metadata (while leaving open the possibility that multiple sets of metadata could emerge, from existing semantics in HTML5

I’m wondering if this is a change without a difference, because technically tags are metadata as well, but I assume you mean that it must use particular attributes?

If so, explicitly calling it metadata then precludes you from using built-in semantics from HTML(5) to fulfil the criteria. (And I’m still not clear why this has to be explicit when 4.1.2 only needs “programmatically determined”.)

For example, coga-field (for form elements) has a value of ‘phone’, which could be fulfilled by the HTML input type of tel. Another examples would be if we later to include regions/sections (under the personalisation spec’s “3.4 Potential parts of a page”), HTML elements that mean the same thing should be available as sufficient techniques.


> As the current wording for the draft SC is presented:
> “contextual information is available for common form elements, common navigation elements and common interactive controls is programmatically available.”

I had suggested a version closer to 4.1.2:
“For common navigation elements, common form elements and common interactive controls contextual information can be programmatically determined.”

I wouldn’t object to adding this to the end: “can be programmatically determined from the metadata”, but I think it is unnecessary, and prevents us simplifying later if HTML adds something that can be used for the same scenario.

Cheers,

-Alastair

PS. Where you said “*All* metadata requires a taxonomy - that is what makes the metadata useful, as it can be machine-interpreted”, that implies it has to be pre-agreed terms.
Taxonomies can be pre-determined, or they can be open. In this context I agree a pre-determined taxonomy is most suitable, but in the context of Search or Administrative metadata, they are quite often open. I.e. an author could add a new term to the object their working on.
I’ve done a lot of Information Architecture work, including specifying taxonomies for content management systems, (not to mention folksonomies, fuzzy matching of terms etc), so I’m pretty familiar with the various uses of metadata. Open taxonomies have their uses to.



--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com<mailto:john.foliot@deque.com>

Advancing the mission of digital accessibility and inclusion