Re: Rolling the personalization SC into 4.1.2

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

​>​


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

Hi Alastair,


​*All* metadata requires a taxonomy - that is what makes the metadata
useful, as it can be machine-interpreted.

Three distinct types of metadata exist: *descriptive metadata*, *structural
metadata*, and *administrative metadata*.

   - Descriptive metadata describes a resource for purposes such as
   discovery and identification. It can include elements such as title,
   abstract, author, and keywords.
   - Structural metadata is metadata about containers of data and indicates
   how compound objects are put together, for example, how pages are ordered
   to form chapters. It describes the types, versions, relationships and other
   characteristics of digital materials.
   - Administrative metadata provides information to help manage a
   resource, such as when and how it was created, file type and other
   technical information, and who can access it.
   (source: https://en.wikipedia.org/wiki/Metadata)


In your example​:


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

​...the value of the text-string "home" is determined / understood because
"coga-destination" has already been predefined as a form of *structural
metadata*. The programmatic linkage is because "coga-destination" is an
attribute of that specific <a> (anchor) element.

However, when I write:

<a href=”/”
​
​title=”home”>Home</a>

​... I have also "linked" that text string ("home") to the anchor element,
as @title is also an attribute of that <a> element as well​. It does not
provide the same "value" however, because while the 'string text' is
identical, one of the attributes is more tightly scoped (thus fulfilling
the "need") whereas the other is not.

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


...it is asking for "programmatically available" (linked) "contextual
information" (text-string) and *not* metadata, and as such I will argue
that using @title (as it is defined in HTML5) is indeed a valid example of
a Success Technique based upon the SC when written that way.

*I believe what is *truly* required is "contextual information SUPPLIED as
metadata", so that machines can parse and adapt to that data (ergo -
personalize).*


> It relies on the definitions of ‘name’ and ‘role’, but it is the
bazillion sufficient techniques that enforce ARIA as the spec to use.

Err... yes, but it also can be satisfied *without* the use of ARIA.

For example, using native form controls in an HTML form (<input
type="checkbox">, <input type="submit">, <button>) relies on the native
semantics of HTML (a
​fixed ​
semantic taxonomy
​ - more *structural metadata*​
), and the native landmark elements of HTML5 do so as well (<nav>,<footer>,
<aside>, etc.) *BECAUSE*
​all of ​
those values have
​also ​
all been mapped to yet another taxonomy: the AAM
<https://www.w3.org/TR/html-aam-1.0/>
​, which is based upon a fixed list of roles, states and properties (again,
more *structural metadata*) that current Assistive Technology (primarily
screen readers) require when interacting with an operating system.​

​

​It seems pretty clear to me that for real personalization to work, it
requires a fixed taxonomy​ (a point reinforced when you study the
draft coga-semantics
specification <https://www.w3.org/TR/personalization-semantics-1.0/>),
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 - as Mike Gower has pointed out - to schema.org's
taxonomy, or in fact any other organization's use-specific taxonomy), as
long as it meets the need of providing a form of personalization - the real
goal here.

JF



On Mon, Jul 17, 2017 at 10:43 AM, lisa.seeman <lisa.seeman@zoho.com> wrote:

> Hi david
>
> I did the reqrite with Rich, but it has nothing to do with coga.
> Are you suggesting adding the word context to it to include it?
>
> All the best
>
> Lisa Seeman
>
> LinkedIn <http://il.linkedin.com/in/lisaseeman/>, Twitter
> <https://twitter.com/SeemanLisa>
>
>
>
>
> ---- On Thu, 13 Jul 2017 20:11:37 +0300 *David
> MacDonald<david@can-adapt.com <david@can-adapt.com>>* wrote ----
>
> At the end of the meeting Michael G. suggested moving the personalization
> SC proposal into 4.1.2. Mike and Andrew, and perhaps Chris are going to go
> off and present some alternative language to the current SC.
>
> I thought pertinent to that conversation is the early COGA proposal to
> modify 4.1.2, which was done in conjunction with Rich Schwerdtfeger.
>
> It is here:
> https://github.com/w3c/wcag21/issues/22
>
> It might be useful.
>
> Cheers,
> David MacDonald
>
>
>
> *Can**Adapt* *Solutions Inc.*
> Mobile:  613.806.9005 <(613)%20806-9005>
>
> LinkedIn
> <http://www.linkedin.com/in/davidmacdonald100>
>
> twitter.com/davidmacd
>
> GitHub <https://github.com/DavidMacDonald>
>
> http://www.can-adapt.com/
>
>
>
> *  Adapting the web to all users*
> *            Including those with disabilities*
>
> If you are not the intended recipient, please review our privacy policy
> <http://www.davidmacd.com/disclaimer.html>
>
>
>
>


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

Advancing the mission of digital accessibility and inclusion