Re: Rolling the personalization SC into 4.1.2

Hi Alastair,

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

For WCAG 2.1, I'd be very careful to not specify a specific taxonomy or
taxonomies too tightly. For example, yes, *when* coga-semantics is
complete, it could/would be one such taxonomy, but in the interest of
technology agnosticism, I'd want to avoid making that the only taxonomy
that authors could use, via obtuse SC language.

So, for example, I'd only want to reference a "publicly available taxonomy"
suitable for use, of which coga-semantics appears will be the best fit, but
that leaves open the door that another taxonomy could also be used
(especially in early days).

JF

On Tue, Jul 18, 2017 at 8:50 AM, Alastair Campbell <acampbell@nomensa.com>
wrote:

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



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

Advancing the mission of digital accessibility and inclusion