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

Advancing the mission of digital accessibility and inclusion