Success Criterion 1.3.4 Identify Common Purpose [Trace]

[GreggVan]

Success Criterion 1.3.4 Identify Common Purpose§
(Level AA) [New]
In content implemented using markup languages, for each user interface component that serves a purpose identified in the Common Purposes for User Interface Components section, that purpose can be programmatically determined.

I thought you had this one solved — until I heard that you now don’t mean that the terms in the list are the terms that need to be used — but rather that any set of terms can be used for those functions as long as they are documented somewhere.

There is no way for this to meet “accessibility supported” if AT have no idea in advance what words to look for. If I create AT this year — and each month after release — for all years going forward
— a new site can use a new set of words — there is no way I can design my AT now, to work with sites that use different sets of words that I don’t know what they will be.

In order for this to work — you must tell me the functions AND the terms that will be used (or tell me that each technology will use a standard set of terms for that technology. (e.g. HTML will define the terms for HTML, PDF will define them for PDF, etc.) Unless someone can tell me another way an AT vendor can know what the terms for those functions are in a programmatically determinable way..., I don't see how this can be met.

[johnfoliot]

Hi Gregg, There seems to be a fair bit of confusion about this, and yet it should be quite simple. The key to this SC, and the bigger 'ask' is to apply *metadata directly to those elements* that serve the "common purposes" articulated in the list. But given internationalization concerns (etc.), the list is malleable to the extent that it defines concepts, rather than specific terms (but, it needs terms to start the definition process). The "simplest" explanation can also be articulated in code - a link to the *Contact Us Page*. But to fully illustrate, I'll actually use the Japanese equivelant of お問い合わせ. Additionally, I will illustrate this using Microdata annotation, and the Schema.org taxonomy (ontology): <a href="http://example.com/contactus.html" itemscope itemtype="http://schema.org/ContactPage">お問い合わせ</a> So, the terms themselves are mostly "placeholders" for the more important definitions of concepts - the metadata *values*. With a publicly available Metadata schema, Assistive Technology *CAN* do the look-up, either via the "old-school" name-spacing (in the mode of Dublin Core), or, with Microdata, following the URL to the explicitly defined concept. At the end of the day, the disambiguation happens at the defined (external) vocabulary, and as long as it is publicly available, AT has the hooks it needs - the disambiguated definitions. "But what AT today?" you ask. Welcome to the chicken and egg problem (which I'm sure you are all too familiar with). As a proof-of-concept tool moving forward (and needed for the exit criteria), I hope (plan) on seeing a browser extension that will do a little bit of user style sheet injection when the Microdata annotation is used (not a complete solution, but illustrative) that will, in essence take advantage of the fact that each term definition is specifically referenced at the element level, using a very specific block (or string) of text. In my example above, that string is "...itemtype="http://schema.org/ContactPage"..." ​...​ and so I can use that string as a CSS selector, and then do stuff like adding a button with icon and text overlay anytime there is a link or button (trigger) to the Contact Us Page ​.​ N ​ow, if a large organization wants​ to publish its own taxonomy list, they will need to ensure that the *concepts defined by this SC* will be mapped to their choice of term and that lookup list is public, but it is the definitions that are effectively normative, not the terms: *​Non-normative Term: * *Normative definition* (taken from Merriam-Webster <https://www.merriam-webster.com/dictionary/dog> for illustration purposes only): dog canid: wolves, foxes, and other dogs; especially : a highly variable domestic mammal (Canis familiaris) closely related to the gray wolf chien​ canid: wolves, foxes, and other dogs; especially : a highly variable domestic mammal (Canis familiaris) closely related to the gray wolf ​ puppy canid: wolves, foxes, and other dogs; especially : a highly variable domestic mammal (Canis familiaris) closely related to the gray wolf ​ fur-baby canid: wolves, foxes, and other dogs; especially : a highly variable domestic mammal (Canis familiaris) closely related to the gray wolf Make sense? JF

…

On Sat, Dec 16, 2017 at 10:51 AM, GreggVan ***@***.***> wrote: Success Criterion 1.3.4 Identify Common Purpose§ (Level AA) [New] In content implemented using markup languages, for each user interface component that serves a purpose identified in the Common Purposes for User Interface Components section, that purpose can be programmatically determined. I thought you had this one solved — until I heard that you now don’t mean that they terms in the list are the terms that need to be used — but rather that any set of terms can be used for those functions as long as they are documented somewhere. This is no way for this to meet “accessibility supported” if AT have no idea in advance what words to look for. If I create AT this year — and each month after release — for all years - a new site can use a new set of words — there is no way I can design my AT now to work with sites that use different sets of words that I don’t know what they will be. In order for this to work — you must tell me the functions AND the terms that will be used (or tell me that each technology will use a standard set of terms for that technology. (e.g. HTML will define the terms for HTML, PDF for PDF, etc.) Unless someone can tell me another way an AT vendor can know what the terms for those functions are in a programmatically determinable way. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#635>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABK-czKwicKADnieNtV9NMU1ScNXkjl9ks5tA_UjgaJpZM4REY2y> .

-- John Foliot Principal Accessibility Strategist Deque Systems Inc. [email protected] Advancing the mission of digital accessibility and inclusion

[jake-abma]

relates to: #402

[GreggVan]

I do not see how it is simple. Simple to explain the problems or what needs to be done — but a LOT more work than if you just define the token/term to start with. If you want to be international - make it a number. but you need one I think your explanation of metadata is fine — but you gloss over the fact that there needs to be the base term that you associate all the other terms to. And that one needs to be normative. you need it to decode the term. You also need authors to list how they are going to tell you how to find the decoding sheet etc. Here is my thinking. Let me now where you see me going wrong. if you don’t - then I have a suggested cure at the end G In order for metadata to work you need both the definition of the term and the term. This SC only provides the definition and then allows of any term to be used as long as it is written down somewhere. But that is of no use to the machine. For example here are my terms for the definitions - in alphabetical order. I publish them with definitions on my website under “example.com/data/decoding/wcag21/metadata.db then I use them on my page. Here are 4 words I use on my page - in alphabetical order. ‘ anccoy Jmeoaz ljerras slijnjope How does a piece of AT know what they mean? If you number the definitions - then I could say “anccoy” is number 14 and you would know which one it means. I could also say anccoy is reset - but that makes it normative that I tie my word to reset (which you don’t want to do) I can’t say it it the 14th word. So you need to EITHER make the order normative (and therefore the number ) or number them and make the number normative or you have to make the english term (or any term) normative or the actual words (including punctuation) of the definition - in english - needs to be normative (worse than having the english term) otherwise you have a bunch of definitions that someone else can make up words for that you do not know how to decode. That is problem 1 problem 2 is that you need to a) have a normative way of finding this list of new terms — b) define normatively the data format for this decoding database. and c) require that the reference to the list be on every page - since we evaluate by page - or it has to be in a normative place on every website (not practical) Otherwise — when I create my AT today I will not know how to associate whatever a person uses next year to create their page - with the definitions. and it will not be programmatically determinable. See the problem? SUGGESTION: If you want a international term instead of an english one — then normatively number them and suggest that the number be accompanied by whatever term in whatever language they like to make it easier for coders (and AT in at least that language). The AT can then keep a list of the terms in the different languages that is supports in a database in the AT. Best gregg

…

On Dec 16, 2017, at 1:30 PM, John Foliot ***@***.***> wrote: Hi Gregg, There seems to be a fair bit of confusion about this, and yet it should be quite simple. The key to this SC, and the bigger 'ask' is to apply *metadata directly to those elements* that serve the "common purposes" articulated in the list. But given internationalization concerns (etc.), the list is malleable to the extent that it defines concepts, rather than specific terms (but, it needs terms to start the definition process). The "simplest" explanation can also be articulated in code - a link to the *Contact Us Page*. But to fully illustrate, I'll actually use the Japanese equivelant of お問い合わせ. Additionally, I will illustrate this using Microdata annotation, and the Schema.org taxonomy (ontology): <a href="http://example.com/contactus.html" itemscope itemtype="http://schema.org/ContactPage">お問い合わせ</a> So, the terms themselves are mostly "placeholders" for the more important definitions of concepts - the metadata *values*. With a publicly available Metadata schema, Assistive Technology *CAN* do the look-up, either via the "old-school" name-spacing (in the mode of Dublin Core), or, with Microdata, following the URL to the explicitly defined concept. At the end of the day, the disambiguation happens at the defined (external) vocabulary, and as long as it is publicly available, AT has the hooks it needs - the disambiguated definitions. "But what AT today?" you ask. Welcome to the chicken and egg problem (which I'm sure you are all too familiar with). As a proof-of-concept tool moving forward (and needed for the exit criteria), I hope (plan) on seeing a browser extension that will do a little bit of user style sheet injection when the Microdata annotation is used (not a complete solution, but illustrative) that will, in essence take advantage of the fact that each term definition is specifically referenced at the element level, using a very specific block (or string) of text. In my example above, that string is "...itemtype="http://schema.org/ContactPage"..." ​...​ and so I can use that string as a CSS selector, and then do stuff like adding a button with icon and text overlay anytime there is a link or button (trigger) to the Contact Us Page ​.​ Now, if a large organization wants​ to publish its own taxonomy list, they will need to ensure that the *concepts defined by this SC* will be mapped to their choice of term and that lookup list is public, but it is the definitions that are effectively normative, not the terms: *​Non-normative Term: * *Normative definition* (taken from Merriam-Webster <https://www.merriam-webster.com/dictionary/dog> for illustration purposes only): dog canid: wolves, foxes, and other dogs; especially : a highly variable domestic mammal (Canis familiaris) closely related to the gray wolf chien​ canid: wolves, foxes, and other dogs; especially : a highly variable domestic mammal (Canis familiaris) closely related to the gray wolf ​ puppy canid: wolves, foxes, and other dogs; especially : a highly variable domestic mammal (Canis familiaris) closely related to the gray wolf ​ fur-baby canid: wolves, foxes, and other dogs; especially : a highly variable domestic mammal (Canis familiaris) closely related to the gray wolf Make sense? JF On Sat, Dec 16, 2017 at 10:51 AM, GreggVan ***@***.***> wrote: > Success Criterion 1.3.4 Identify Common Purpose§ > (Level AA) [New] > In content implemented using markup languages, for each user interface > component that serves a purpose identified in the Common Purposes for User > Interface Components section, that purpose can be programmatically > determined. > > I thought you had this one solved — until I heard that you now don’t mean > that they terms in the list are the terms that need to be used — but rather > that any set of terms can be used for those functions as long as they are > documented somewhere. This is no way for this to meet “accessibility > supported” if AT have no idea in advance what words to look for. If I > create AT this year — and each month after release — for all years - a new > site can use a new set of words — there is no way I can design my AT now to > work with sites that use different sets of words that I don’t know what > they will be. In order for this to work — you must tell me the functions > AND the terms that will be used (or tell me that each technology will use a > standard set of terms for that technology. (e.g. HTML will define the terms > for HTML, PDF for PDF, etc.) Unless someone can tell me another way an AT > vendor can know what the terms for those functions are in a > programmatically determinable way. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#635>, or mute the thread > <https://github.com/notifications/unsubscribe-auth/ABK-czKwicKADnieNtV9NMU1ScNXkjl9ks5tA_UjgaJpZM4REY2y> > . > -- John Foliot Principal Accessibility Strategist Deque Systems Inc. ***@***.*** Advancing the mission of digital accessibility and inclusion — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#635 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJph3j7urR46441VX4MHx9BdT9cVaUP1ks5tBAxMgaJpZM4REY2y>.

[GreggVan]

On Dec 16, 2017, at 1:30 PM, John Foliot ***@***.***> wrote: Hi Gregg, There seems to be a fair bit of confusion about this, and yet it should be quite simple. The key to this SC, and the bigger 'ask' is to apply *metadata directly to those elements* that serve the "common purposes" articulated in the list.

Yep

But given internationalization concerns (etc.), the list is malleable to the extent that it defines concepts, rather than specific terms (but, it needs terms to start the definition process).

All metadata has the same internationalization concern. None of them say — "so you can use any terms you want as long as you document it” you need to list the referent name or label or handle as well as the definition.

The "simplest" explanation can also be articulated in code - a link to the *Contact Us Page*. But to fully illustrate, I'll actually use the Japanese equivelant of お問い合わせ. Additionally, I will illustrate this using Microdata annotation, and the Schema.org taxonomy (ontology): <a href="http://example.com/contactus.html" itemscope itemtype="http://schema.org/ContactPage">お問い合わせ</a>

AH but Contact Page is the term. you can’t use schema.org without using the name of the entity first — and then attaching any other label that you want.

So, the terms themselves are mostly "placeholders" for the more important definitions of concepts - the metadata *values*. With a publicly available Metadata schema, Assistive Technology *CAN* do the look-up, either via the "old-school" name-spacing (in the mode of Dublin Core), or, with Microdata, following the URL to the explicitly defined concept. At the end of the day, the disambiguation happens at the defined (external) vocabulary, and as long as it is publicly available, AT has the hooks it needs - the disambiguated definitions.

yes but you MUST USE THE TERM. you can’t say "http://schema.org/お問い合わせ you must first use the defined name.

"But what AT today?" you ask. Welcome to the chicken and egg problem (which I'm sure you are all too familiar with). As a proof-of-concept tool moving forward (and needed for the exit criteria), I hope (plan) on seeing a browser extension that will do a little bit of user style sheet injection when the Microdata annotation is used (not a complete solution, but illustrative) that will, in essence take advantage of the fact that each term definition is specifically referenced at the element level, using a very specific block (or string) of text. In my example above, that string is "...itemtype="http://schema.org/ContactPage"..." ​...​ and so I can use that string as a CSS selector, and then do stuff like adding a button with icon and text overlay anytime there is a link or button (trigger) to the Contact Us Page ​.​

if you want to say they must use Schema.org then that is fine. but I can’t make AT today that will work next year if you use http://FoliotScheme.org/お問い合わせ how will I know what that means? I can haul down your definition in (japanese but it won’t help my AT programmatically determine the function.

Now, if a large organization wants​ to publish its own taxonomy list, they will need to ensure that the *concepts defined by this SC* will be mapped to their choice of term and that lookup list is public, but it is the definitions that are effectively normative, not the terms:

Great — but how do I map them back to the terms if there are no known stable handles for each term in the SC?

*​Non-normative Term: * *Normative definition* (taken from Merriam-Webster <https://www.merriam-webster.com/dictionary/dog> for illustration purposes only): dog canid: wolves, foxes, and other dogs; especially : a highly variable domestic mammal (Canis familiaris) closely related to the gray wolf chien​ canid: wolves, foxes, and other dogs; especially : a highly variable domestic mammal (Canis familiaris) closely related to the gray wolf ​ puppy canid: wolves, foxes, and other dogs; especially : a highly variable domestic mammal (Canis familiaris) closely related to the gray wolf ​ fur-baby canid: wolves, foxes, and other dogs; especially : a highly variable domestic mammal (Canis familiaris) closely related to the gray wolf Make sense?

Not unless you assume that everyone knows english. if you used english terms for the 20 or so items — I could know what the translation to my country’s language was’’’ or even if you numbered them. But you need some stable referent

…

JF On Sat, Dec 16, 2017 at 10:51 AM, GreggVan ***@***.***> wrote: > Success Criterion 1.3.4 Identify Common Purpose§ > (Level AA) [New] > In content implemented using markup languages, for each user interface > component that serves a purpose identified in the Common Purposes for User > Interface Components section, that purpose can be programmatically > determined. > > I thought you had this one solved — until I heard that you now don’t mean > that they terms in the list are the terms that need to be used — but rather > that any set of terms can be used for those functions as long as they are > documented somewhere. This is no way for this to meet “accessibility > supported” if AT have no idea in advance what words to look for. If I > create AT this year — and each month after release — for all years - a new > site can use a new set of words — there is no way I can design my AT now to > work with sites that use different sets of words that I don’t know what > they will be. In order for this to work — you must tell me the functions > AND the terms that will be used (or tell me that each technology will use a > standard set of terms for that technology. (e.g. HTML will define the terms > for HTML, PDF for PDF, etc.) Unless someone can tell me another way an AT > vendor can know what the terms for those functions are in a > programmatically determinable way. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#635>, or mute the thread > <https://github.com/notifications/unsubscribe-auth/ABK-czKwicKADnieNtV9NMU1ScNXkjl9ks5tA_UjgaJpZM4REY2y> > . > -- John Foliot Principal Accessibility Strategist Deque Systems Inc. ***@***.*** Advancing the mission of digital accessibility and inclusion — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#635 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJph3j7urR46441VX4MHx9BdT9cVaUP1ks5tBAxMgaJpZM4REY2y>.

[johnfoliot]

Hi Gregg, You wrote:

*In order for metadata to work you need both the definition of the term

and the term. For example here are my terms for the definitions - in alphabetical order. I publish them with definitions on my website under “example.com/data/decoding/wcag21/metadata.db <http://example.com/data/decoding/wcag21/metadata.db>* *then I use them on my page. Here are 4 words I use on my page - in alphabetical order. ‘* *anccoy* *Jmeoaz* *ljerras* *slijnjope * *How does a piece of AT know what they mean? * Namespacing <https://msdn.microsoft.com/en-us/library/ms754619(v=vs.85).aspx>. Different schemas may have different terms for the same (or equivalent) concepts, and we do not want to restrict this SC to a single metadata schema or annotation format. However, using Microdata annotation, the namespacing happens when you supply the value (which is a URL string to the definition). But that is but one method of doing the "lookup" or the linking of controls to definitions.

*otherwise you have a bunch of definitions that someone else can make up

words for that you do not know how to decode. * Partially correct: you can make up your own terms, however 2 points to remember: #1, for the metadata to be useful, there needs to be the namespacing/lookup mechanism. In Microdata annotation, the url that *is* the definitionis the value string. Other metadata schemas use global namespacing and declarations in the document <head>, such as Dublin Core (not recommended, as that is document level metadata, and not element level microdata) or TEI (which also allows for customization <http://www.tei-c.org/Guidelines/Customization/index.xml> through classes and attributes). The emergent Personalization Semantics <https://www.w3.org/TR/personalization-semantics-1.0/> uses inline attributes (without "namespacing", but via reserved attribute strings and values just like ARIA)... so the method is less important than the result. #2, you would have to warrant and prove that your definitions at example.com/data/decoding/wcag21/metadata.db could in fact be accessibility supported: that web-browsers and an AT tool can do the appropriate namespace lookup required to close this loop.

*problem 2 is that you need to* *a) have a normative way of finding this list of new terms —* ​This depends on the metadata schema and usage rules. However, whether inline or as part of a global header declaration, metadata schemas all provide normative terms and definitions, and a mechanism for "looking up" the definition. This SC essentially states that for whatever metadata schema you choose, it must have a ​schema-level ​ term *that matches our list of definitions*. Thus, when the AT does the namespaced lookup for the term declared ​ (your "Jmeoaz")​ , it arrives at the "common definition" we require ​ ​ (Contact us - View the contact information for content owner or producer <http://rawgit.com/w3c/wcag21/master/guidelines/index.html#commonpurposes>)​ . ​ ​ *b) define normatively the data format for this decoding database.* ​I disagree. The data format is not critical here (important, yes, critical, no), rather it's the middleware that will be doing something useful with the metadata values - *and that middleware will need to be accessibly supported​* to be able to successfully meet this SC. That said, perhaps we *should* further state that custom metadata schemas must be declared using RDF or RDFa (???) - but that too feels like a bit of an over-reach. * and* * c) require that the reference to the list be on every page - since we evaluate by page - or it has to be in a normative place on every website (not practical)* ​...and again, I disagree. It depends on the (accessibility supported) metadata schema the author chooses. Some schemas have a global namespace declaration in the document <head> (and so, via HTML page templating, this could indeed may be VERY easy & practical to accomplish): <head> <link rel="schema.VANDERHEIDEN" href="http://example.com/data/decoding/wcag21/metadata/" /> </head> + <body> <a href="contactpage.html" class="Jmeoaz"> ​ お問い合わせ</a> <!-- presumes your metadata schema uses class values to apply inline term definitions, and is accessibility supported --> </body> Others can use Microdata annotation (where again the definition *IS* the URL string to the normative text(s)): <element itemscope itemtype="http://example.com/data/decoding/ wcag21/metadata/%Value">*Non-normative term*</element> Or, as in Personalization Semantics (or TEI), it can be dependant on a reserved list of attributes or class values: <button coga-action="undo"> ​ *Non-normative term*</button> ​> *See the problem?* ​ ​Actually, no, I don't​. (If anything, with respect Gregg, ​ the problem ​ as I see it​ is that you aren't understanding ​how to apply element level metadata fully, which, if nothing else, underscores a bigger concern - will others understand the ask here ​ as well?​ Or will they be confused ?)

​ *All metadata has the same internationalization concern. None of them say — "so you can use any terms you want as long as you document it” * ​Respectfully, I must disagree. ​Most (many) metadata schemes appear to allow for further extension or customization: Schema.org <http://schema.org/docs/extension.html>: "*There are two kinds of extensions: reviewed/hosted extensions and external extensions. Both kinds of extensions typically add subclasses and properties to the core. Properties may be added to existing and/or new classes.*" TEI <http://www.tei-c.org/Guidelines/Customization/odds.xml#body.1_div.2_div.3>: "*A schema can include declarations for new elements,* *..."* Microformats <http://microformats.org/wiki/process>: "*So you wanna develop a new microformat? Or just a new vocabulary? Or create a new standard based on empirical research and scientific methods? This document will help guide you through the steps to take towards achieving these goals.*" (again, I would not recommend Microformats, as it appears *too* malleable, given that the definition list(s) is a publicly editable wiki)

*AH but Contact Page is the term. you can’t use schema.org

<http://schema.org/> without using the name of the entity first — and then attaching any other label that you want. *

*yes but you MUST USE THE TERM. you can’t say "**http://schema.org/*お問い合わせ

<http://schema.org/%E3%81%8A%E5%95%8F%E3%81%84%E5%90%88%E3%82%8F%E3%81%9B> you must first use the defined name. ​Again, respectfully, this is incorrect. The term we are applying metadata to itself is abstract, it is the *definition* that is normative. In my example using Microdata, the term that is being defined is *the value between the element's opening and closing tag*​: <a href="http://example.com/contactus.html" ​ ​ itemscope ​ ​ <!-- required to scope the definition to just this element ​ ​ ​& element value -->​ ​ itemtype="http://schema.org/ContactPage"> <!-- URL to normative definition --> お問い合わせ <!-- Term that is being defined in this instance, *scoped as such* with the *itemscope* attribute --> </a> ​The fact that ​ ​​ お問い合わせ ​ is the Japanese translation of "Contact Page" doesn't really matter, because both terms will point to (reference) the normative definition at ​ http://schema.org/ContactPage ​ when encoded using Microdata annotation (as above). As long as http://schema.org/ContactPage ​ resolves to a definition that is equal (or equated) to "View the contact information for content owner or producer"​, you will have succeeded. Ditto for your custom schema: if (using Microdata annotation) itemtype="http://example.com/data/decoding/wcag21/metadata/ ​VanderheidenContactDetails.xml​ [sic] also maps back to "View the contact information for content owner or producer" ​ you're good-to-go.​ So, to wrap up, yes, we will need a ​"lookup list" that declares the normative definitions we require, and with those definitions a list of "common" terms that serve as a handle for each definition. That current list is found as "chapter" 7 in the draft WCAG 2.1 spec: http://rawgit.com/w3c/wcag21/master/guidelines/index.html#commonpurposes But critically, the author does not need to use the specific terms/handles used in that list, what they need to reference is the actual normative definition. *How they apply that definition* to any given element will depend on which schema the author uses, and how the schema they have chosen at the document level mandates applying definitions to conceptual elements: - some may use reserved handles/short-terms (referenced as attributes or class values + page-level namespacing), - others may simply point to the URL that constitutes the normative definition (Microdata format) with no actual (reserved) "term" being used, - while others may use reserved inline attributes ​ & values​ (Personalization Semantics). 3 different techniques, but all will (MUST!) ultimately reference the same normative definition. JF

…

On Wed, Dec 20, 2017 at 10:08 PM, GreggVan ***@***.***> wrote: > On Dec 16, 2017, at 1:30 PM, John Foliot ***@***.***> wrote: > > Hi Gregg, > > There seems to be a fair bit of confusion about this, and yet it should be > quite simple. > > The key to this SC, and the bigger 'ask' is to apply *metadata directly to > those elements* that serve the "common purposes" articulated in the list. Yep > But given internationalization concerns (etc.), the list is malleable to > the extent that it defines concepts, rather than specific terms (but, it > needs terms to start the definition process). All metadata has the same internationalization concern. None of them say — "so you can use any terms you want as long as you document it” you need to list the referent name or label or handle as well as the definition. > > The "simplest" explanation can also be articulated in code - a link to > the *Contact > Us Page*. But to fully illustrate, I'll actually use the Japanese > equivelant of お問い合わせ. Additionally, I will illustrate this using Microdata > annotation, and the Schema.org taxonomy (ontology): > > <a href="http://example.com/contactus.html" > itemscope > itemtype="http://schema.org/ContactPage">お問い合わせ</a> > AH but Contact Page is the term. you can’t use schema.org without using the name of the entity first — and then attaching any other label that you want. > > So, the terms themselves are mostly "placeholders" for the more important > definitions of concepts - the metadata *values*. With a publicly available > Metadata schema, Assistive Technology *CAN* do the look-up, either via the > "old-school" name-spacing (in the mode of Dublin Core), or, with Microdata, > following the URL to the explicitly defined concept. At the end of the day, > the disambiguation happens at the defined (external) vocabulary, and as > long as it is publicly available, AT has the hooks it needs - the > disambiguated definitions. yes but you MUST USE THE TERM. you can’t say "http://schema.org/お問い合わせ you must first use the defined name. > > "But what AT today?" you ask. > > Welcome to the chicken and egg problem (which I'm sure you are all too > familiar with). As a proof-of-concept tool moving forward (and needed for > the exit criteria), I hope (plan) on seeing a browser extension that will > do a little bit of user style sheet injection when the Microdata annotation > is used (not a complete solution, but illustrative) that will, in essence > take advantage of the fact that each term definition is specifically > referenced at the element level, using a very specific block (or string) of > text. In my example above, that string is > > "...itemtype="http://schema.org/ContactPage"..." > > ​...​ > and so I can use that string as a CSS selector, and then do stuff like > adding a button with icon and text overlay anytime there is a link or > button (trigger) to the Contact Us Page > ​.​ if you want to say they must use Schema.org then that is fine. but I can’t make AT today that will work next year if you use http://FoliotScheme.org/お問い合わせ <http://foliotscheme.org/%E3%81%8A%E5%95%8F%E3%81%84%E5%90%88%E3%82%8F%E3%81%9B> how will I know what that means? I can haul down your definition in (japanese but it won’t help my AT programmatically determine the function. > > Now, if a large organization wants​ to publish its own taxonomy list, they > will need to ensure that the *concepts defined by this SC* will be mapped > to their choice of term and that lookup list is public, but it is the > definitions that are effectively normative, not the terms: Great — but how do I map them back to the terms if there are no known stable handles for each term in the SC? > > *​Non-normative Term: * *Normative definition* (taken > from Merriam-Webster <https://www.merriam-webster.com/dictionary/dog> for > illustration purposes only): > dog canid: wolves, > foxes, and other dogs; especially : a highly variable domestic mammal > (Canis > familiaris) closely related to the gray wolf > > chien​ canid: wolves, > foxes, and other dogs; especially : a highly variable domestic mammal > (Canis > familiaris) closely related to the gray wolf > > ​ puppy canid: wolves, > foxes, and other dogs; especially : a highly variable domestic mammal > (Canis > familiaris) closely related to the gray wolf > > ​ fur-baby canid: wolves, > foxes, and other dogs; especially : a highly variable domestic mammal > (Canis > familiaris) closely related to the gray wolf > > Make sense? Not unless you assume that everyone knows english. if you used english terms for the 20 or so items — I could know what the translation to my country’s language was’’’ or even if you numbered them. But you need some stable referent > > JF > > On Sat, Dec 16, 2017 at 10:51 AM, GreggVan ***@***.***> wrote: > > > Success Criterion 1.3.4 Identify Common Purpose§ > > (Level AA) [New] > > In content implemented using markup languages, for each user interface > > component that serves a purpose identified in the Common Purposes for User > > Interface Components section, that purpose can be programmatically > > determined. > > > > I thought you had this one solved — until I heard that you now don’t mean > > that they terms in the list are the terms that need to be used — but rather > > that any set of terms can be used for those functions as long as they are > > documented somewhere. This is no way for this to meet “accessibility > > supported” if AT have no idea in advance what words to look for. If I > > create AT this year — and each month after release — for all years - a new > > site can use a new set of words — there is no way I can design my AT now to > > work with sites that use different sets of words that I don’t know what > > they will be. In order for this to work — you must tell me the functions > > AND the terms that will be used (or tell me that each technology will use a > > standard set of terms for that technology. (e.g. HTML will define the terms > > for HTML, PDF for PDF, etc.) Unless someone can tell me another way an AT > > vendor can know what the terms for those functions are in a > > programmatically determinable way. > > > > — > > You are receiving this because you are subscribed to this thread. > > Reply to this email directly, view it on GitHub > > <#635>, or mute the thread > > <https://github.com/notifications/unsubscribe-auth/ABK- czKwicKADnieNtV9NMU1ScNXkjl9ks5tA_UjgaJpZM4REY2y> > > . > > > > > > -- > John Foliot > Principal Accessibility Strategist > Deque Systems Inc. > ***@***.*** > > Advancing the mission of digital accessibility and inclusion > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub <https://github.com/w3c/ wcag21/issues/635#issuecomment-352201706>, or mute the thread < https://github.com/notifications/unsubscribe-auth/ AJph3j7urR46441VX4MHx9BdT9cVaUP1ks5tBAxMgaJpZM4REY2y>. > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#635 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABK-c0vcBdxkZWCxutxfFkp3dmuYo02gks5tCdnTgaJpZM4REY2y> .

-- John Foliot Principal Accessibility Strategist Deque Systems Inc. [email protected] Advancing the mission of digital accessibility and inclusion

[GreggVan]

to make a long posting short What I had said was the referent — you are saying would be the URL. that is fine. But you have not defined the URL for each of the concepts in the SC. When you do — you will have satisfied what I have been asking for. It can be a name a number a URL but it needs to be determinant and there is nothing determinant — there is no stable handle — for each of the terms in the list. Does that help? Gregg

…

On Dec 21, 2017, at 12:46 PM, John Foliot ***@***.***> wrote: Hi Gregg, You wrote: > *In order for metadata to work you need both the definition of the term and the term. For example here are my terms for the definitions - in alphabetical order. I publish them with definitions on my website under “example.com/data/decoding/wcag21/metadata.db <http://example.com/data/decoding/wcag21/metadata.db>* *then I use them on my page. Here are 4 words I use on my page - in alphabetical order. ‘* *anccoy* *Jmeoaz* *ljerras* *slijnjope * *How does a piece of AT know what they mean? * Namespacing <https://msdn.microsoft.com/en-us/library/ms754619(v=vs.85).aspx>. Different schemas may have different terms for the same (or equivalent) concepts, and we do not want to restrict this SC to a single metadata schema or annotation format. However, using Microdata annotation, the namespacing happens when you supply the value (which is a URL string to the definition). But that is but one method of doing the "lookup" or the linking of controls to definitions. > *otherwise you have a bunch of definitions that someone else can make up words for that you do not know how to decode. * Partially correct: you can make up your own terms, however 2 points to remember: #1, for the metadata to be useful, there needs to be the namespacing/lookup mechanism. In Microdata annotation, the url that *is* the definitionis the value string. Other metadata schemas use global namespacing and declarations in the document <head>, such as Dublin Core (not recommended, as that is document level metadata, and not element level microdata) or TEI (which also allows for customization <http://www.tei-c.org/Guidelines/Customization/index.xml> through classes and attributes). The emergent Personalization Semantics <https://www.w3.org/TR/personalization-semantics-1.0/> uses inline attributes (without "namespacing", but via reserved attribute strings and values just like ARIA)... so the method is less important than the result. #2, you would have to warrant and prove that your definitions at example.com/data/decoding/wcag21/metadata.db could in fact be accessibility supported: that web-browsers and an AT tool can do the appropriate namespace lookup required to close this loop. > *problem 2 is that you need to* *a) have a normative way of finding this list of new terms —* ​This depends on the metadata schema and usage rules. However, whether inline or as part of a global header declaration, metadata schemas all provide normative terms and definitions, and a mechanism for "looking up" the definition. This SC essentially states that for whatever metadata schema you choose, it must have a ​schema-level ​ term *that matches our list of definitions*. Thus, when the AT does the namespaced lookup for the term declared ​ (your "Jmeoaz")​ , it arrives at the "common definition" we require ​ ​ (Contact us - View the contact information for content owner or producer <http://rawgit.com/w3c/wcag21/master/guidelines/index.html#commonpurposes>)​ . ​ ​ *b) define normatively the data format for this decoding database.* ​I disagree. The data format is not critical here (important, yes, critical, no), rather it's the middleware that will be doing something useful with the metadata values - *and that middleware will need to be accessibly supported​* to be able to successfully meet this SC. That said, perhaps we *should* further state that custom metadata schemas must be declared using RDF or RDFa (???) - but that too feels like a bit of an over-reach. * and* * c) require that the reference to the list be on every page - since we evaluate by page - or it has to be in a normative place on every website (not practical)* ​...and again, I disagree. It depends on the (accessibility supported) metadata schema the author chooses. Some schemas have a global namespace declaration in the document <head> (and so, via HTML page templating, this could indeed may be VERY easy & practical to accomplish): <head> <link rel="schema.VANDERHEIDEN" href="http://example.com/data/decoding/wcag21/metadata/" /> </head> + <body> <a href="contactpage.html" class="Jmeoaz"> ​ お問い合わせ</a> <!-- presumes your metadata schema uses class values to apply inline term definitions, and is accessibility supported --> </body> Others can use Microdata annotation (where again the definition *IS* the URL string to the normative text(s)): <element itemscope itemtype="http://example.com/data/decoding/ wcag21/metadata/%Value">*Non-normative term*</element> Or, as in Personalization Semantics (or TEI), it can be dependant on a reserved list of attributes or class values: <button coga-action="undo"> ​ *Non-normative term*</button> ​> *See the problem?* ​ ​Actually, no, I don't​. (If anything, with respect Gregg, ​ the problem ​ as I see it​ is that you aren't understanding ​how to apply element level metadata fully, which, if nothing else, underscores a bigger concern - will others understand the ask here ​ as well?​ Or will they be confused ?) > ​ *All metadata has the same internationalization concern. None of them say — "so you can use any terms you want as long as you document it” * ​Respectfully, I must disagree. ​Most (many) metadata schemes appear to allow for further extension or customization: Schema.org <http://schema.org/docs/extension.html>: "*There are two kinds of extensions: reviewed/hosted extensions and external extensions. Both kinds of extensions typically add subclasses and properties to the core. Properties may be added to existing and/or new classes.*" TEI <http://www.tei-c.org/Guidelines/Customization/odds.xml#body.1_div.2_div.3>: "*A schema can include declarations for new elements,* *..."* Microformats <http://microformats.org/wiki/process>: "*So you wanna develop a new microformat? Or just a new vocabulary? Or create a new standard based on empirical research and scientific methods? This document will help guide you through the steps to take towards achieving these goals.*" (again, I would not recommend Microformats, as it appears *too* malleable, given that the definition list(s) is a publicly editable wiki) > *AH but Contact Page is the term. you can’t use schema.org <http://schema.org/> without using the name of the entity first — and then attaching any other label that you want. * > *yes but you MUST USE THE TERM. you can’t say "**http://schema.org/*お問い合わせ <http://schema.org/%E3%81%8A%E5%95%8F%E3%81%84%E5%90%88%E3%82%8F%E3%81%9B> you must first use the defined name. ​Again, respectfully, this is incorrect. The term we are applying metadata to itself is abstract, it is the *definition* that is normative. In my example using Microdata, the term that is being defined is *the value between the element's opening and closing tag*​: <a href="http://example.com/contactus.html" ​ ​ itemscope ​ ​ <!-- required to scope the definition to just this element ​ ​ ​& element value -->​ ​ itemtype="http://schema.org/ContactPage"> <!-- URL to normative definition --> お問い合わせ <!-- Term that is being defined in this instance, *scoped as such* with the *itemscope* attribute --> </a> ​The fact that ​ ​​ お問い合わせ ​ is the Japanese translation of "Contact Page" doesn't really matter, because both terms will point to (reference) the normative definition at ​ http://schema.org/ContactPage ​ when encoded using Microdata annotation (as above). As long as http://schema.org/ContactPage ​ resolves to a definition that is equal (or equated) to "View the contact information for content owner or producer"​, you will have succeeded. Ditto for your custom schema: if (using Microdata annotation) itemtype="http://example.com/data/decoding/wcag21/metadata/ ​VanderheidenContactDetails.xml​ [sic] also maps back to "View the contact information for content owner or producer" ​ you're good-to-go.​ So, to wrap up, yes, we will need a ​"lookup list" that declares the normative definitions we require, and with those definitions a list of "common" terms that serve as a handle for each definition. That current list is found as "chapter" 7 in the draft WCAG 2.1 spec: http://rawgit.com/w3c/wcag21/master/guidelines/index.html#commonpurposes But critically, the author does not need to use the specific terms/handles used in that list, what they need to reference is the actual normative definition. *How they apply that definition* to any given element will depend on which schema the author uses, and how the schema they have chosen at the document level mandates applying definitions to conceptual elements: - some may use reserved handles/short-terms (referenced as attributes or class values + page-level namespacing), - others may simply point to the URL that constitutes the normative definition (Microdata format) with no actual (reserved) "term" being used, - while others may use reserved inline attributes ​ & values​ (Personalization Semantics). 3 different techniques, but all will (MUST!) ultimately reference the same normative definition. JF On Wed, Dec 20, 2017 at 10:08 PM, GreggVan ***@***.***> wrote: > > > > On Dec 16, 2017, at 1:30 PM, John Foliot ***@***.***> > wrote: > > > > Hi Gregg, > > > > There seems to be a fair bit of confusion about this, and yet it should > be > > quite simple. > > > > The key to this SC, and the bigger 'ask' is to apply *metadata directly > to > > those elements* that serve the "common purposes" articulated in the list. > > Yep > > > But given internationalization concerns (etc.), the list is malleable to > > the extent that it defines concepts, rather than specific terms (but, it > > needs terms to start the definition process). > > All metadata has the same internationalization concern. None of them say — > "so you can use any terms you want as long as you document it” > > you need to list the referent name or label or handle as well as the > definition. > > > > > The "simplest" explanation can also be articulated in code - a link to > > the *Contact > > Us Page*. But to fully illustrate, I'll actually use the Japanese > > equivelant of お問い合わせ. Additionally, I will illustrate this using > Microdata > > annotation, and the Schema.org taxonomy (ontology): > > > > <a href="http://example.com/contactus.html" > > itemscope > > itemtype="http://schema.org/ContactPage">お問い合わせ</a> > > > AH but Contact Page is the term. you can’t use schema.org without using > the name of the entity first — and then attaching any other label that you > want. > > > > > So, the terms themselves are mostly "placeholders" for the more important > > definitions of concepts - the metadata *values*. With a publicly > available > > Metadata schema, Assistive Technology *CAN* do the look-up, either via > the > > "old-school" name-spacing (in the mode of Dublin Core), or, with > Microdata, > > following the URL to the explicitly defined concept. At the end of the > day, > > the disambiguation happens at the defined (external) vocabulary, and as > > long as it is publicly available, AT has the hooks it needs - the > > disambiguated definitions. > > yes but you MUST USE THE TERM. you can’t say "http://schema.org/お問い合わせ > > you must first use the defined name. > > > > > "But what AT today?" you ask. > > > > Welcome to the chicken and egg problem (which I'm sure you are all too > > familiar with). As a proof-of-concept tool moving forward (and needed for > > the exit criteria), I hope (plan) on seeing a browser extension that will > > do a little bit of user style sheet injection when the Microdata > annotation > > is used (not a complete solution, but illustrative) that will, in essence > > take advantage of the fact that each term definition is specifically > > referenced at the element level, using a very specific block (or string) > of > > text. In my example above, that string is > > > > "...itemtype="http://schema.org/ContactPage"..." > > > > ​...​ > > and so I can use that string as a CSS selector, and then do stuff like > > adding a button with icon and text overlay anytime there is a link or > > button (trigger) to the Contact Us Page > > ​.​ > > if you want to say they must use Schema.org then that is fine. > > but I can’t make AT today that will work next year if you use > http://FoliotScheme.org/お問い合わせ > <http://foliotscheme.org/%E3%81%8A%E5%95%8F%E3%81%84%E5%90%88%E3%82%8F%E3%81%9B> > > how will I know what that means? I can haul down your definition in > (japanese but it won’t help my AT programmatically determine the function. > > > > > > > > Now, if a large organization wants​ to publish its own taxonomy list, > they > > will need to ensure that the *concepts defined by this SC* will be mapped > > to their choice of term and that lookup list is public, but it is the > > definitions that are effectively normative, not the terms: > > Great — but how do I map them back to the terms if there are no known > stable handles for each term in the SC? > > > > > > *​Non-normative Term: * *Normative definition* (taken > > from Merriam-Webster <https://www.merriam-webster.com/dictionary/dog> > for > > illustration purposes only): > > dog canid: wolves, > > foxes, and other dogs; especially : a highly variable domestic mammal > > (Canis > > familiaris) closely related to the gray wolf > > > > chien​ canid: wolves, > > foxes, and other dogs; especially : a highly variable domestic mammal > > (Canis > > familiaris) closely related to the gray wolf > > > > ​ puppy canid: wolves, > > foxes, and other dogs; especially : a highly variable domestic mammal > > (Canis > > familiaris) closely related to the gray wolf > > > > ​ fur-baby canid: wolves, > > foxes, and other dogs; especially : a highly variable domestic mammal > > (Canis > > familiaris) closely related to the gray wolf > > > > Make sense? > > Not unless you assume that everyone knows english. > > if you used english terms for the 20 or so items — I could know what the > translation to my country’s language was’’’ > > or even if you numbered them. > > But you need some stable referent > > > > > > > JF > > > > On Sat, Dec 16, 2017 at 10:51 AM, GreggVan ***@***.***> > wrote: > > > > > Success Criterion 1.3.4 Identify Common Purpose§ > > > (Level AA) [New] > > > In content implemented using markup languages, for each user interface > > > component that serves a purpose identified in the Common Purposes for > User > > > Interface Components section, that purpose can be programmatically > > > determined. > > > > > > I thought you had this one solved — until I heard that you now don’t > mean > > > that they terms in the list are the terms that need to be used — but > rather > > > that any set of terms can be used for those functions as long as they > are > > > documented somewhere. This is no way for this to meet “accessibility > > > supported” if AT have no idea in advance what words to look for. If I > > > create AT this year — and each month after release — for all years - a > new > > > site can use a new set of words — there is no way I can design my AT > now to > > > work with sites that use different sets of words that I don’t know what > > > they will be. In order for this to work — you must tell me the > functions > > > AND the terms that will be used (or tell me that each technology will > use a > > > standard set of terms for that technology. (e.g. HTML will define the > terms > > > for HTML, PDF for PDF, etc.) Unless someone can tell me another way an > AT > > > vendor can know what the terms for those functions are in a > > > programmatically determinable way. > > > > > > — > > > You are receiving this because you are subscribed to this thread. > > > Reply to this email directly, view it on GitHub > > > <#635>, or mute the thread > > > <https://github.com/notifications/unsubscribe-auth/ABK- > czKwicKADnieNtV9NMU1ScNXkjl9ks5tA_UjgaJpZM4REY2y> > > > . > > > > > > > > > > > -- > > John Foliot > > Principal Accessibility Strategist > > Deque Systems Inc. > > ***@***.*** > > > > Advancing the mission of digital accessibility and inclusion > > — > > You are receiving this because you authored the thread. > > Reply to this email directly, view it on GitHub <https://github.com/w3c/ > wcag21/issues/635#issuecomment-352201706>, or mute the thread < > https://github.com/notifications/unsubscribe-auth/ > AJph3j7urR46441VX4MHx9BdT9cVaUP1ks5tBAxMgaJpZM4REY2y>. > > > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <#635 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/ABK-c0vcBdxkZWCxutxfFkp3dmuYo02gks5tCdnTgaJpZM4REY2y> > . > -- John Foliot Principal Accessibility Strategist Deque Systems Inc. ***@***.*** Advancing the mission of digital accessibility and inclusion — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#635 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJph3uqy6SpnoqrRXK6rK8TS7rp6qU-pks5tCplhgaJpZM4REY2y>.

[johnfoliot]

Gregg, Let me back this up a bit: would you prefer we *mandate the use of a single normative metadata schema here*, or is it preferable to say "Use a schema that is publicly available and accessibility supported" and leave it to the author to choose which schema best suits their needs?

What I had said was the referent — you are saying would be the URL.

​> ​ that is fine. But you have not defined the URL for each of the concepts in the SC. ​Once again, this depends on what metadata schema you use​. Yes, I can map all of the current 'handles' to a Schema.org definition (I've done so already), *but not all metadata schemas have unique URLs for each definition*. We have a normative list of common "handles" and clear definitions, and how any schema references those definitions will be dependant on the schemas vocabulary structure and the inline annotation method used to apply the definition to the control. ​>​ When you do — you will have satisfied what I have been asking for. It can be ​> ​ a name ​​ For ​metadata vocabularies that use namespacing and ​inline values (​ terms ​)​ , the "name" will be the related term specific to that ​ specific​ vocabulary ​. As AWK previously pointed out, one vocabulary may use the term "toc", while another vocabulary may use "TableOfContents"​, and the Gregg-Vanderheiden vocabulary uses " anccoy ​". That really shouldn't matter (and in practice, doesn't). As long as all three vocabularies bind their terms (names) to a common definition "View or go to a table of contents" [link type] ​, which term you use will then be dependant on the namespace lookup declaration (or method that you use to link the public vocabulary to the page/element)​. ​ ​> a number ​??? This feels over-engineered. That said, we could provide, as part of the Understanding documentation, a "mapping table" that uses numbers as KeyID values, and then list our "common term/handle", the normative definition, and then pointers to one or more metadata schemas that shows how the annotation would work, and the value to point to​ - but that would all be non-normative and illustrative, as we do not want to mandate the use of a specific metadata vocabulary: [image: Inline image 2] ​ ​​ ​> ​ a URL ​ ​ For ​metadata vocabularies that use direct URLs to definitions (such as, but not limited to, Schema.org), the "name" will be the related term specified at the URL . ​Not all metadata schemas however are constructed in this fashion - many do not resolve to unique URLS per definition.

but it needs to be determinant and there is nothing determinant — there

is no stable handle — for each of the terms in the list. ​That's a feature Gregg, not a bug. We want to leave *which* metadata vocabulary the author uses open to the author to choose, and/but different vocabularies may have different 'terms' for the same conceptual idea. We need to recognize that fact. So, as long as the vocabulary has public definitions, and those definitions map to the *normatively defined​ "Common Purposes"* definitions we've articulated <http://rawgit.com/w3c/wcag21/master/guidelines/index.html#commonpurposes>, then the method by which the schema supplies the metadata is dependant on the annotation method used by that particular vocabulary - and not all annotation methods use "terms" (and even when they do, how the"term" is applied also varies - it could be an attribute, a class value string, or an attribute value string). One overarching goal was to avoid being *too* prescriptive with regards to Techniques ("Thou MUST use the Vanderheiden metadata values on the following controls:...") - yet the only way to ensure *normative terms* is to specify a unique metadata vocabulary (and thus that vocabulary's terms), and specifying or defining a metadata schema is outside the scope of this Working Group (i.e. we SHOULD reuse what is already out there). JF

…

On Thu, Dec 21, 2017 at 11:50 AM, GreggVan ***@***.***> wrote: to make a long posting short What I had said was the referent — you are saying would be the URL. that is fine. But you have not defined the URL for each of the concepts in the SC. When you do — you will have satisfied what I have been asking for. It can be a name a number a URL but it needs to be determinant and there is nothing determinant — there is no stable handle — for each of the terms in the list. Does that help? Gregg > On Dec 21, 2017, at 12:46 PM, John Foliot ***@***.***> wrote: > > Hi Gregg, > > You wrote: > > > *In order for metadata to work you need both the definition of the term > and the term. For example here are my terms for the definitions - in > alphabetical order. I publish them with definitions on my website under > “example.com/data/decoding/wcag21/metadata.db > <http://example.com/data/decoding/wcag21/metadata.db>* > > *then I use them on my page. Here are 4 words I use on my page - in > alphabetical order. ‘* > > *anccoy* > *Jmeoaz* > *ljerras* > *slijnjope * > > *How does a piece of AT know what they mean? * > > Namespacing > <https://msdn.microsoft.com/en-us/library/ms754619(v=vs.85).aspx>. > Different schemas may have different terms for the same (or equivalent) > concepts, and we do not want to restrict this SC to a single metadata > schema or annotation format. However, using Microdata annotation, the > namespacing happens when you supply the value (which is a URL string to the > definition). But that is but one method of doing the "lookup" or the > linking of controls to definitions. > > > > *otherwise you have a bunch of definitions that someone else can make up > words for that you do not know how to decode. * > > > Partially correct: you can make up your own terms, however 2 points to > remember: > > #1, for the metadata to be useful, there needs to be the > namespacing/lookup mechanism. In Microdata annotation, the url that *is* > the definitionis the value string. Other metadata schemas use global > namespacing and declarations in the document <head>, such as Dublin Core > (not recommended, as that is document level metadata, and not element level > microdata) or TEI (which also allows for customization > <http://www.tei-c.org/Guidelines/Customization/index.xml> through classes > and attributes). The emergent Personalization Semantics > <https://www.w3.org/TR/personalization-semantics-1.0/> uses inline > attributes (without "namespacing", but via reserved attribute strings and > values just like ARIA)... so the method is less important than the result. > > #2, you would have to warrant and prove that your definitions at > example.com/data/decoding/wcag21/metadata.db could in fact be accessibility > supported: that web-browsers and an AT tool can do the appropriate > namespace lookup required to close this loop. > > > > > *problem 2 is that you need to* > > *a) have a normative way of finding this list of new terms —* > > ​This depends on the metadata schema and usage rules. However, whether > inline or as part of a global header declaration, metadata schemas all > provide normative terms and definitions, and a mechanism for "looking up" > the definition. > This SC essentially states that for whatever metadata schema you choose, it > must have a > ​schema-level ​ > term *that matches our list of definitions*. Thus, when the AT does the > namespaced lookup for the term declared > ​ (your "Jmeoaz")​ > , it arrives at the "common definition" we require > ​ ​ > (Contact us - View the contact information for content owner or producer > <http://rawgit.com/w3c/wcag21/master/guidelines/index.html# commonpurposes>)​ > . > ​ ​ > > > *b) define normatively the data format for this decoding database.* > > ​I disagree. The data format is not critical here (important, yes, > critical, no), rather it's the middleware that will be doing something > useful with the metadata values - *and that middleware will need to be > accessibly supported​* to be able to successfully meet this SC. > That said, perhaps we *should* further state that custom metadata schemas > must be declared using RDF or RDFa (???) - but that too feels like a bit of > an over-reach. > > > * and* > > * c) require that the reference to the list be on every page - since we > evaluate by page - or it has to be in a normative place on every website > (not practical)* > > ​...and again, I disagree. It depends on the (accessibility supported) > metadata schema the author chooses. Some schemas have a global namespace > declaration in the document <head> (and so, via HTML page templating, this > could indeed may be VERY easy & practical to accomplish): > > <head> > <link rel="schema.VANDERHEIDEN" > href="http://example.com/data/decoding/wcag21/metadata/" > /> > </head> > + > <body> > <a href="contactpage.html" class="Jmeoaz"> > ​ > お問い合わせ</a> > <!-- presumes your metadata schema uses class values to apply inline > term definitions, and is accessibility supported --> > > </body> > > > > Others can use Microdata annotation (where again the definition *IS* the > URL string to the normative text(s)): > > <element itemscope itemtype="http://example.com/data/decoding/ > wcag21/metadata/%Value">*Non-normative term*</element> > > > > Or, as in Personalization Semantics (or TEI), it can be dependant on a > reserved list of attributes or class values: > > <button coga-action="undo"> > ​ > *Non-normative term*</button> > > > > ​> > *See the problem?* > > > ​ > ​Actually, no, I don't​. > (If anything, with respect Gregg, > ​ > the problem > ​ as I see it​ > is that you aren't understanding > ​how to apply element level metadata > fully, which, if nothing else, underscores a bigger concern - will others > understand the ask here > ​ as well?​ Or will they be confused > ?) > > > > > ​ > *All metadata has the same internationalization concern. None of them say > — "so you can use any terms you want as long as you document it” * > > ​Respectfully, I must disagree. ​Most (many) metadata schemes appear to > allow for further extension or customization: > > Schema.org <http://schema.org/docs/extension.html>: "*There are two kinds > of extensions: reviewed/hosted extensions and external extensions. Both > kinds of extensions typically add subclasses and properties to the core. > Properties may be added to existing and/or new classes.*" > > TEI > <http://www.tei-c.org/Guidelines/Customization/odds. xml#body.1_div.2_div.3>: > "*A schema can include declarations for new elements,* *..."* > > Microformats <http://microformats.org/wiki/process>: "*So you wanna develop > a new microformat? Or just a new vocabulary? Or create a new standard based > on empirical research and scientific methods? This document will help guide > you through the steps to take towards achieving these goals.*" > (again, I would not recommend Microformats, as it appears *too* malleable, > given that the definition list(s) is a publicly editable wiki) > > > > > *AH but Contact Page is the term. you can’t use schema.org > <http://schema.org/> without using the name of the entity first — and then > attaching any other label that you want. * > > *yes but you MUST USE THE TERM. you can’t say "**http://schema.org/* お問い合わせ > <http://schema.org/%E3%81%8A%E5%95%8F%E3%81%84%E5%90%88%E3% 82%8F%E3%81%9B> you > must first use the defined name. > > ​Again, respectfully, this is incorrect. The term we are applying metadata > to itself is abstract, it is the *definition* that is normative. In my > example using Microdata, the term that is being defined is *the value > between the element's opening and closing tag*​: > > > <a href="http://example.com/contactus.html" > ​ > ​ > itemscope > ​ > ​ <!-- required to scope the definition to just this element > ​ ​ > ​& element value -->​ > > ​ itemtype="http://schema.org/ContactPage"> <!-- URL to normative > definition --> > お問い合わせ <!-- Term that is being defined in this instance, *scoped > as such* with the *itemscope* attribute --> > </a> > > ​The fact that ​ > ​​ > お問い合わせ > ​ is the Japanese translation of "Contact Page" doesn't really matter, > because both terms will point to (reference) the normative definition at ​ > http://schema.org/ContactPage > ​ when encoded using Microdata annotation (as above). > > As long as > http://schema.org/ContactPage > ​ resolves to a definition that is equal (or equated) to "View the contact > information for content owner or producer"​, you will have succeeded. > > Ditto for your custom schema: if (using Microdata annotation) > itemtype="http://example.com/data/decoding/wcag21/metadata/ > ​VanderheidenContactDetails.xml​ [sic] > also maps back to "View the contact information for content owner or > producer" > ​ you're good-to-go.​ > > > So, to wrap up, yes, we will need a ​"lookup list" that declares the > normative definitions we require, and with those definitions a list of > "common" terms that serve as a handle for each definition. That current > list is found as "chapter" 7 in the draft WCAG 2.1 spec: > http://rawgit.com/w3c/wcag21/master/guidelines/index.html#commonpurposes > > But critically, the author does not need to use the specific terms/handles > used in that list, what they need to reference is the actual normative > definition. *How they apply that definition* to any given element will > depend on which schema the author uses, and how the schema they have chosen > at the document level mandates applying definitions to conceptual elements: > > - some may use reserved handles/short-terms (referenced as attributes or > class values + page-level namespacing), > - others may simply point to the URL that constitutes the normative > definition (Microdata format) with no actual (reserved) "term" being used, > - while others may use reserved inline attributes > ​ & values​ > (Personalization Semantics). > > > 3 different techniques, but all will (MUST!) ultimately reference the same > normative definition. > > > JF > > On Wed, Dec 20, 2017 at 10:08 PM, GreggVan ***@***.***> wrote: > > > > > > > > On Dec 16, 2017, at 1:30 PM, John Foliot ***@***.***> > > wrote: > > > > > > Hi Gregg, > > > > > > There seems to be a fair bit of confusion about this, and yet it should > > be > > > quite simple. > > > > > > The key to this SC, and the bigger 'ask' is to apply *metadata directly > > to > > > those elements* that serve the "common purposes" articulated in the list. > > > > Yep > > > > > But given internationalization concerns (etc.), the list is malleable to > > > the extent that it defines concepts, rather than specific terms (but, it > > > needs terms to start the definition process). > > > > All metadata has the same internationalization concern. None of them say — > > "so you can use any terms you want as long as you document it” > > > > you need to list the referent name or label or handle as well as the > > definition. > > > > > > > > The "simplest" explanation can also be articulated in code - a link to > > > the *Contact > > > Us Page*. But to fully illustrate, I'll actually use the Japanese > > > equivelant of お問い合わせ. Additionally, I will illustrate this using > > Microdata > > > annotation, and the Schema.org taxonomy (ontology): > > > > > > <a href="http://example.com/contactus.html" > > > itemscope > > > itemtype="http://schema.org/ContactPage">お問い合わせ</a> > > > > > AH but Contact Page is the term. you can’t use schema.org without using > > the name of the entity first — and then attaching any other label that you > > want. > > > > > > > > So, the terms themselves are mostly "placeholders" for the more important > > > definitions of concepts - the metadata *values*. With a publicly > > available > > > Metadata schema, Assistive Technology *CAN* do the look-up, either via > > the > > > "old-school" name-spacing (in the mode of Dublin Core), or, with > > Microdata, > > > following the URL to the explicitly defined concept. At the end of the > > day, > > > the disambiguation happens at the defined (external) vocabulary, and as > > > long as it is publicly available, AT has the hooks it needs - the > > > disambiguated definitions. > > > > yes but you MUST USE THE TERM. you can’t say "http://schema.org/お問い合わせ > > > > you must first use the defined name. > > > > > > > > "But what AT today?" you ask. > > > > > > Welcome to the chicken and egg problem (which I'm sure you are all too > > > familiar with). As a proof-of-concept tool moving forward (and needed for > > > the exit criteria), I hope (plan) on seeing a browser extension that will > > > do a little bit of user style sheet injection when the Microdata > > annotation > > > is used (not a complete solution, but illustrative) that will, in essence > > > take advantage of the fact that each term definition is specifically > > > referenced at the element level, using a very specific block (or string) > > of > > > text. In my example above, that string is > > > > > > "...itemtype="http://schema.org/ContactPage"..." > > > > > > ​...​ > > > and so I can use that string as a CSS selector, and then do stuff like > > > adding a button with icon and text overlay anytime there is a link or > > > button (trigger) to the Contact Us Page > > > ​.​ > > > > if you want to say they must use Schema.org then that is fine. > > > > but I can’t make AT today that will work next year if you use > > http://FoliotScheme.org/お問い合わせ <http://foliotscheme.org/%E3%81%8A%E5%95%8F%E3%81%84%E5%90%88%E3%82%8F%E3%81%9B> > > <http://foliotscheme.org/%E3%81%8A%E5%95%8F%E3%81%84%E5%90% 88%E3%82%8F%E3%81%9B> > > > > how will I know what that means? I can haul down your definition in > > (japanese but it won’t help my AT programmatically determine the function. > > > > > > > > > > > > > > Now, if a large organization wants​ to publish its own taxonomy list, > > they > > > will need to ensure that the *concepts defined by this SC* will be mapped > > > to their choice of term and that lookup list is public, but it is the > > > definitions that are effectively normative, not the terms: > > > > Great — but how do I map them back to the terms if there are no known > > stable handles for each term in the SC? > > > > > > > > > > *​Non-normative Term: * *Normative definition* (taken > > > from Merriam-Webster <https://www.merriam-webster.com/dictionary/dog > > > for > > > illustration purposes only): > > > dog canid: wolves, > > > foxes, and other dogs; especially : a highly variable domestic mammal > > > (Canis > > > familiaris) closely related to the gray wolf > > > > > > chien​ canid: wolves, > > > foxes, and other dogs; especially : a highly variable domestic mammal > > > (Canis > > > familiaris) closely related to the gray wolf > > > > > > ​ puppy canid: wolves, > > > foxes, and other dogs; especially : a highly variable domestic mammal > > > (Canis > > > familiaris) closely related to the gray wolf > > > > > > ​ fur-baby canid: wolves, > > > foxes, and other dogs; especially : a highly variable domestic mammal > > > (Canis > > > familiaris) closely related to the gray wolf > > > > > > Make sense? > > > > Not unless you assume that everyone knows english. > > > > if you used english terms for the 20 or so items — I could know what the > > translation to my country’s language was’’’ > > > > or even if you numbered them. > > > > But you need some stable referent > > > > > > > > > > > > JF > > > > > > On Sat, Dec 16, 2017 at 10:51 AM, GreggVan ***@***.*** > > > wrote: > > > > > > > Success Criterion 1.3.4 Identify Common Purpose§ > > > > (Level AA) [New] > > > > In content implemented using markup languages, for each user interface > > > > component that serves a purpose identified in the Common Purposes for > > User > > > > Interface Components section, that purpose can be programmatically > > > > determined. > > > > > > > > I thought you had this one solved — until I heard that you now don’t > > mean > > > > that they terms in the list are the terms that need to be used — but > > rather > > > > that any set of terms can be used for those functions as long as they > > are > > > > documented somewhere. This is no way for this to meet “accessibility > > > > supported” if AT have no idea in advance what words to look for. If I > > > > create AT this year — and each month after release — for all years - a > > new > > > > site can use a new set of words — there is no way I can design my AT > > now to > > > > work with sites that use different sets of words that I don’t know what > > > > they will be. In order for this to work — you must tell me the > > functions > > > > AND the terms that will be used (or tell me that each technology will > > use a > > > > standard set of terms for that technology. (e.g. HTML will define the > > terms > > > > for HTML, PDF for PDF, etc.) Unless someone can tell me another way an > > AT > > > > vendor can know what the terms for those functions are in a > > > > programmatically determinable way. > > > > > > > > — > > > > You are receiving this because you are subscribed to this thread. > > > > Reply to this email directly, view it on GitHub > > > > <#635>, or mute the thread > > > > <https://github.com/notifications/unsubscribe-auth/ABK- > > czKwicKADnieNtV9NMU1ScNXkjl9ks5tA_UjgaJpZM4REY2y> > > > > . > > > > > > > > > > > > > > > > -- > > > John Foliot > > > Principal Accessibility Strategist > > > Deque Systems Inc. > > > ***@***.*** > > > > > > Advancing the mission of digital accessibility and inclusion > > > — > > > You are receiving this because you authored the thread. > > > Reply to this email directly, view it on GitHub < https://github.com/w3c/ > > wcag21/issues/635#issuecomment-352201706>, or mute the thread < > > https://github.com/notifications/unsubscribe-auth/ > > AJph3j7urR46441VX4MHx9BdT9cVaUP1ks5tBAxMgaJpZM4REY2y>. > > > > > > > — > > You are receiving this because you commented. > > Reply to this email directly, view it on GitHub > > <#635 (comment)>, or mute > > the thread > > <https://github.com/notifications/unsubscribe-auth/ABK- c0vcBdxkZWCxutxfFkp3dmuYo02gks5tCdnTgaJpZM4REY2y> > > . > > > > > > -- > John Foliot > Principal Accessibility Strategist > Deque Systems Inc. > ***@***.*** > > Advancing the mission of digital accessibility and inclusion > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub <https://github.com/w3c/ wcag21/issues/635#issuecomment-353413400>, or mute the thread < https://github.com/notifications/unsubscribe-auth/ AJph3uqy6SpnoqrRXK6rK8TS7rp6qU-pks5tCplhgaJpZM4REY2y>. > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#635 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABK-c2wGj7jzYy_cgVYc-AigHpPcMS_0ks5tCppKgaJpZM4REY2y> .

-- John Foliot Principal Accessibility Strategist Deque Systems Inc. [email protected] Advancing the mission of digital accessibility and inclusion

[GreggVan]

On Dec 21, 2017, at 2:41 PM, John Foliot ***@***.***> wrote: Gregg, Let me back this up a bit: would you prefer we *mandate the use of a single normative metadata schema here*, or is it preferable to say "Use a schema that is publicly available and accessibility supported" and leave it to the author to choose which schema best suits their needs?

People can use whatever schema they want — AS LONG AS there is a way to tie that schema back to the items in your list in WCAG 2.1 right now you do not have a way — since you do not specify anything that can be used as and ID as normative. IF - you use the term you have here OR - if you give each one a number OR - you give each one ANY Normative handle it works. easiest - is to make the term normative and in techniques describe how to use any other schema to link back to it. OR - number each one and make the number fixed and normative (also works but a bit of a pain to use and more prone to error)

> What I had said was the referent — you are saying would be the URL. ​> ​ that is fine. But you have not defined the URL for each of the concepts in the SC. ​Once again, this depends on what metadata schema you use​. Yes, I can map all of the current 'handles' to a Schema.org definition (I've done so already), *but not all metadata schemas have unique URLs for each definition*. We have a normative list of common "handles" and clear definitions, and how any schema references those definitions will be dependant on the schemas vocabulary structure and the inline annotation method used to apply the definition to the control.

You can’t map anything back to the SC list if they list has no handles.

…

​>​ When you do — you will have satisfied what I have been asking for. It can be ​> ​ a name ​​ For ​metadata vocabularies that use namespacing and ​inline values (​ terms ​)​ , the "name" will be the related term specific to that ​ specific​ vocabulary ​. As AWK previously pointed out, one vocabulary may use the term "toc", while another vocabulary may use "TableOfContents"​, and the Gregg-Vanderheiden vocabulary uses " anccoy ​". That really shouldn't matter (and in practice, doesn't). As long as all three vocabularies bind their terms (names) to a common definition "View or go to a table of contents" [link type] ​, which term you use will then be dependant on the namespace lookup declaration (or method that you use to link the public vocabulary to the page/element)​. ​ ​> a number ​??? This feels over-engineered. That said, we could provide, as part of the Understanding documentation, a "mapping table" that uses numbers as KeyID values, and then list our "common term/handle", the normative definition, and then pointers to one or more metadata schemas that shows how the annotation would work, and the value to point to​ - but that would all be non-normative and illustrative, as we do not want to mandate the use of a specific metadata vocabulary: [image: Inline image 2] ​ ​​ ​> ​ a URL ​ ​ For ​metadata vocabularies that use direct URLs to definitions (such as, but not limited to, Schema.org), the "name" will be the related term specified at the URL . ​Not all metadata schemas however are constructed in this fashion - many do not resolve to unique URLS per definition. > but it needs to be determinant and there is nothing determinant — there is no stable handle — for each of the terms in the list. ​That's a feature Gregg, not a bug. We want to leave *which* metadata vocabulary the author uses open to the author to choose, and/but different vocabularies may have different 'terms' for the same conceptual idea. We need to recognize that fact. So, as long as the vocabulary has public definitions, and those definitions map to the *normatively defined​ "Common Purposes"* definitions we've articulated <http://rawgit.com/w3c/wcag21/master/guidelines/index.html#commonpurposes>, then the method by which the schema supplies the metadata is dependant on the annotation method used by that particular vocabulary - and not all annotation methods use "terms" (and even when they do, how the"term" is applied also varies - it could be an attribute, a class value string, or an attribute value string). One overarching goal was to avoid being *too* prescriptive with regards to Techniques ("Thou MUST use the Vanderheiden metadata values on the following controls:...") - yet the only way to ensure *normative terms* is to specify a unique metadata vocabulary (and thus that vocabulary's terms), and specifying or defining a metadata schema is outside the scope of this Working Group (i.e. we SHOULD reuse what is already out there). JF On Thu, Dec 21, 2017 at 11:50 AM, GreggVan ***@***.***> wrote: > to make a long posting short > > What I had said was the referent — you are saying would be the URL. > that is fine. But you have not defined the URL for each of the concepts in > the SC. > > When you do — you will have satisfied what I have been asking for. It can > be > a name > a number > a URL > > but it needs to be determinant and there is nothing determinant — there is > no stable handle — for each of the terms in the list. > > Does that help? > > Gregg > > > > On Dec 21, 2017, at 12:46 PM, John Foliot ***@***.***> > wrote: > > > > Hi Gregg, > > > > You wrote: > > > > > *In order for metadata to work you need both the definition of the term > > and the term. For example here are my terms for the definitions - in > > alphabetical order. I publish them with definitions on my website under > > “example.com/data/decoding/wcag21/metadata.db > > <http://example.com/data/decoding/wcag21/metadata.db>* > > > > *then I use them on my page. Here are 4 words I use on my page - in > > alphabetical order. ‘* > > > > *anccoy* > > *Jmeoaz* > > *ljerras* > > *slijnjope * > > > > *How does a piece of AT know what they mean? * > > > > Namespacing > > <https://msdn.microsoft.com/en-us/library/ms754619(v=vs.85).aspx>. > > Different schemas may have different terms for the same (or equivalent) > > concepts, and we do not want to restrict this SC to a single metadata > > schema or annotation format. However, using Microdata annotation, the > > namespacing happens when you supply the value (which is a URL string to > the > > definition). But that is but one method of doing the "lookup" or the > > linking of controls to definitions. > > > > > > > *otherwise you have a bunch of definitions that someone else can make > up > > words for that you do not know how to decode. * > > > > > > Partially correct: you can make up your own terms, however 2 points to > > remember: > > > > #1, for the metadata to be useful, there needs to be the > > namespacing/lookup mechanism. In Microdata annotation, the url that *is* > > the definitionis the value string. Other metadata schemas use global > > namespacing and declarations in the document <head>, such as Dublin Core > > (not recommended, as that is document level metadata, and not element > level > > microdata) or TEI (which also allows for customization > > <http://www.tei-c.org/Guidelines/Customization/index.xml> through > classes > > and attributes). The emergent Personalization Semantics > > <https://www.w3.org/TR/personalization-semantics-1.0/> uses inline > > attributes (without "namespacing", but via reserved attribute strings and > > values just like ARIA)... so the method is less important than the > result. > > > > #2, you would have to warrant and prove that your definitions at > > example.com/data/decoding/wcag21/metadata.db could in fact be > accessibility > > supported: that web-browsers and an AT tool can do the appropriate > > namespace lookup required to close this loop. > > > > > > > > > *problem 2 is that you need to* > > > > *a) have a normative way of finding this list of new terms —* > > > > ​This depends on the metadata schema and usage rules. However, whether > > inline or as part of a global header declaration, metadata schemas all > > provide normative terms and definitions, and a mechanism for "looking up" > > the definition. > > This SC essentially states that for whatever metadata schema you choose, > it > > must have a > > ​schema-level ​ > > term *that matches our list of definitions*. Thus, when the AT does the > > namespaced lookup for the term declared > > ​ (your "Jmeoaz")​ > > , it arrives at the "common definition" we require > > ​ ​ > > (Contact us - View the contact information for content owner or producer > > <http://rawgit.com/w3c/wcag21/master/guidelines/index.html# > commonpurposes>)​ > > . > > ​ ​ > > > > > > *b) define normatively the data format for this decoding database.* > > > > ​I disagree. The data format is not critical here (important, yes, > > critical, no), rather it's the middleware that will be doing something > > useful with the metadata values - *and that middleware will need to be > > accessibly supported​* to be able to successfully meet this SC. > > That said, perhaps we *should* further state that custom metadata schemas > > must be declared using RDF or RDFa (???) - but that too feels like a bit > of > > an over-reach. > > > > > > * and* > > > > * c) require that the reference to the list be on every page - since we > > evaluate by page - or it has to be in a normative place on every website > > (not practical)* > > > > ​...and again, I disagree. It depends on the (accessibility supported) > > metadata schema the author chooses. Some schemas have a global namespace > > declaration in the document <head> (and so, via HTML page templating, > this > > could indeed may be VERY easy & practical to accomplish): > > > > <head> > > <link rel="schema.VANDERHEIDEN" > > href="http://example.com/data/decoding/wcag21/metadata/" > > /> > > </head> > > + > > <body> > > <a href="contactpage.html" class="Jmeoaz"> > > ​ > > お問い合わせ</a> > > <!-- presumes your metadata schema uses class values to apply inline > > term definitions, and is accessibility supported --> > > > > </body> > > > > > > > > Others can use Microdata annotation (where again the definition *IS* the > > URL string to the normative text(s)): > > > > <element itemscope itemtype="http://example.com/data/decoding/ > > wcag21/metadata/%Value">*Non-normative term*</element> > > > > > > > > Or, as in Personalization Semantics (or TEI), it can be dependant on a > > reserved list of attributes or class values: > > > > <button coga-action="undo"> > > ​ > > *Non-normative term*</button> > > > > > > > > ​> > > *See the problem?* > > > > > > ​ > > ​Actually, no, I don't​. > > (If anything, with respect Gregg, > > ​ > > the problem > > ​ as I see it​ > > is that you aren't understanding > > ​how to apply element level metadata > > fully, which, if nothing else, underscores a bigger concern - will others > > understand the ask here > > ​ as well?​ Or will they be confused > > ?) > > > > > > > > > ​ > > *All metadata has the same internationalization concern. None of them say > > — "so you can use any terms you want as long as you document it” * > > > > ​Respectfully, I must disagree. ​Most (many) metadata schemes appear to > > allow for further extension or customization: > > > > Schema.org <http://schema.org/docs/extension.html>: "*There are two > kinds > > of extensions: reviewed/hosted extensions and external extensions. Both > > kinds of extensions typically add subclasses and properties to the core. > > Properties may be added to existing and/or new classes.*" > > > > TEI > > <http://www.tei-c.org/Guidelines/Customization/odds. > xml#body.1_div.2_div.3>: > > "*A schema can include declarations for new elements,* *..."* > > > > Microformats <http://microformats.org/wiki/process>: "*So you wanna > develop > > a new microformat? Or just a new vocabulary? Or create a new standard > based > > on empirical research and scientific methods? This document will help > guide > > you through the steps to take towards achieving these goals.*" > > (again, I would not recommend Microformats, as it appears *too* > malleable, > > given that the definition list(s) is a publicly editable wiki) > > > > > > > > > *AH but Contact Page is the term. you can’t use schema.org > > <http://schema.org/> without using the name of the entity first — and > then > > attaching any other label that you want. * > > > *yes but you MUST USE THE TERM. you can’t say "**http://schema.org/* > お問い合わせ > > <http://schema.org/%E3%81%8A%E5%95%8F%E3%81%84%E5%90%88%E3% > 82%8F%E3%81%9B> you > > must first use the defined name. > > > > ​Again, respectfully, this is incorrect. The term we are applying > metadata > > to itself is abstract, it is the *definition* that is normative. In my > > example using Microdata, the term that is being defined is *the value > > between the element's opening and closing tag*​: > > > > > > <a href="http://example.com/contactus.html" > > ​ > > ​ > > itemscope > > ​ > > ​ <!-- required to scope the definition to just this element > > ​ ​ > > ​& element value -->​ > > > > ​ itemtype="http://schema.org/ContactPage"> <!-- URL to normative > > definition --> > > お問い合わせ <!-- Term that is being defined in this instance, *scoped > > as such* with the *itemscope* attribute --> > > </a> > > > > ​The fact that ​ > > ​​ > > お問い合わせ > > ​ is the Japanese translation of "Contact Page" doesn't really matter, > > because both terms will point to (reference) the normative definition at > ​ > > http://schema.org/ContactPage > > ​ when encoded using Microdata annotation (as above). > > > > As long as > > http://schema.org/ContactPage > > ​ resolves to a definition that is equal (or equated) to "View the > contact > > information for content owner or producer"​, you will have succeeded. > > > > Ditto for your custom schema: if (using Microdata annotation) > > itemtype="http://example.com/data/decoding/wcag21/metadata/ > > ​VanderheidenContactDetails.xml​ [sic] > > also maps back to "View the contact information for content owner or > > producer" > > ​ you're good-to-go.​ > > > > > > So, to wrap up, yes, we will need a ​"lookup list" that declares the > > normative definitions we require, and with those definitions a list of > > "common" terms that serve as a handle for each definition. That current > > list is found as "chapter" 7 in the draft WCAG 2.1 spec: > > http://rawgit.com/w3c/wcag21/master/guidelines/index.html#commonpurposes > > > > But critically, the author does not need to use the specific > terms/handles > > used in that list, what they need to reference is the actual normative > > definition. *How they apply that definition* to any given element will > > depend on which schema the author uses, and how the schema they have > chosen > > at the document level mandates applying definitions to conceptual > elements: > > > > - some may use reserved handles/short-terms (referenced as attributes or > > class values + page-level namespacing), > > - others may simply point to the URL that constitutes the normative > > definition (Microdata format) with no actual (reserved) "term" being > used, > > - while others may use reserved inline attributes > > > ​ & values​ > > (Personalization Semantics). > > > > > > 3 different techniques, but all will (MUST!) ultimately reference the > same > > normative definition. > > > > > > JF > > > > On Wed, Dec 20, 2017 at 10:08 PM, GreggVan ***@***.***> > wrote: > > > > > > > > > > > > On Dec 16, 2017, at 1:30 PM, John Foliot ***@***.***> > > > wrote: > > > > > > > > Hi Gregg, > > > > > > > > There seems to be a fair bit of confusion about this, and yet it > should > > > be > > > > quite simple. > > > > > > > > The key to this SC, and the bigger 'ask' is to apply *metadata > directly > > > to > > > > those elements* that serve the "common purposes" articulated in the > list. > > > > > > Yep > > > > > > > But given internationalization concerns (etc.), the list is > malleable to > > > > the extent that it defines concepts, rather than specific terms > (but, it > > > > needs terms to start the definition process). > > > > > > All metadata has the same internationalization concern. None of them > say — > > > "so you can use any terms you want as long as you document it” > > > > > > you need to list the referent name or label or handle as well as the > > > definition. > > > > > > > > > > > The "simplest" explanation can also be articulated in code - a link > to > > > > the *Contact > > > > Us Page*. But to fully illustrate, I'll actually use the Japanese > > > > equivelant of お問い合わせ. Additionally, I will illustrate this using > > > Microdata > > > > annotation, and the Schema.org taxonomy (ontology): > > > > > > > > <a href="http://example.com/contactus.html" > > > > itemscope > > > > itemtype="http://schema.org/ContactPage">お問い合わせ</a> > > > > > > > AH but Contact Page is the term. you can’t use schema.org without > using > > > the name of the entity first — and then attaching any other label that > you > > > want. > > > > > > > > > > > So, the terms themselves are mostly "placeholders" for the more > important > > > > definitions of concepts - the metadata *values*. With a publicly > > > available > > > > Metadata schema, Assistive Technology *CAN* do the look-up, either > via > > > the > > > > "old-school" name-spacing (in the mode of Dublin Core), or, with > > > Microdata, > > > > following the URL to the explicitly defined concept. At the end of > the > > > day, > > > > the disambiguation happens at the defined (external) vocabulary, and > as > > > > long as it is publicly available, AT has the hooks it needs - the > > > > disambiguated definitions. > > > > > > yes but you MUST USE THE TERM. you can’t say "http://schema.org/お問い合わせ > > > > > > you must first use the defined name. > > > > > > > > > > > "But what AT today?" you ask. > > > > > > > > Welcome to the chicken and egg problem (which I'm sure you are all > too > > > > familiar with). As a proof-of-concept tool moving forward (and > needed for > > > > the exit criteria), I hope (plan) on seeing a browser extension that > will > > > > do a little bit of user style sheet injection when the Microdata > > > annotation > > > > is used (not a complete solution, but illustrative) that will, in > essence > > > > take advantage of the fact that each term definition is specifically > > > > referenced at the element level, using a very specific block (or > string) > > > of > > > > text. In my example above, that string is > > > > > > > > "...itemtype="http://schema.org/ContactPage"..." > > > > > > > > ​...​ > > > > and so I can use that string as a CSS selector, and then do stuff > like > > > > adding a button with icon and text overlay anytime there is a link or > > > > button (trigger) to the Contact Us Page > > > > ​.​ > > > > > > if you want to say they must use Schema.org then that is fine. > > > > > > but I can’t make AT today that will work next year if you use > > > http://FoliotScheme.org/お問い合わせ > <http://foliotscheme.org/%E3%81%8A%E5%95%8F%E3%81%84%E5%90%88%E3%82%8F%E3%81%9B> > > > <http://foliotscheme.org/%E3%81%8A%E5%95%8F%E3%81%84%E5%90% > 88%E3%82%8F%E3%81%9B> > > > > > > > how will I know what that means? I can haul down your definition in > > > (japanese but it won’t help my AT programmatically determine the > function. > > > > > > > > > > > > > > > > > > > > Now, if a large organization wants​ to publish its own taxonomy list, > > > they > > > > will need to ensure that the *concepts defined by this SC* will be > mapped > > > > to their choice of term and that lookup list is public, but it is the > > > > definitions that are effectively normative, not the terms: > > > > > > Great — but how do I map them back to the terms if there are no known > > > stable handles for each term in the SC? > > > > > > > > > > > > > > *​Non-normative Term: * *Normative definition* (taken > > > > from Merriam-Webster <https://www.merriam-webster.com/dictionary/dog > > > > > for > > > > illustration purposes only): > > > > dog canid: wolves, > > > > foxes, and other dogs; especially : a highly variable domestic mammal > > > > (Canis > > > > familiaris) closely related to the gray wolf > > > > > > > > chien​ canid: wolves, > > > > foxes, and other dogs; especially : a highly variable domestic mammal > > > > (Canis > > > > familiaris) closely related to the gray wolf > > > > > > > > ​ puppy canid: wolves, > > > > foxes, and other dogs; especially : a highly variable domestic mammal > > > > (Canis > > > > familiaris) closely related to the gray wolf > > > > > > > > ​ fur-baby canid: wolves, > > > > foxes, and other dogs; especially : a highly variable domestic mammal > > > > (Canis > > > > familiaris) closely related to the gray wolf > > > > > > > > Make sense? > > > > > > Not unless you assume that everyone knows english. > > > > > > if you used english terms for the 20 or so items — I could know what > the > > > translation to my country’s language was’’’ > > > > > > or even if you numbered them. > > > > > > But you need some stable referent > > > > > > > > > > > > > > > > > JF > > > > > > > > On Sat, Dec 16, 2017 at 10:51 AM, GreggVan ***@***.*** > > > > > wrote: > > > > > > > > > Success Criterion 1.3.4 Identify Common Purpose§ > > > > > (Level AA) [New] > > > > > In content implemented using markup languages, for each user > interface > > > > > component that serves a purpose identified in the Common Purposes > for > > > User > > > > > Interface Components section, that purpose can be programmatically > > > > > determined. > > > > > > > > > > I thought you had this one solved — until I heard that you now > don’t > > > mean > > > > > that they terms in the list are the terms that need to be used — > but > > > rather > > > > > that any set of terms can be used for those functions as long as > they > > > are > > > > > documented somewhere. This is no way for this to meet > “accessibility > > > > > supported” if AT have no idea in advance what words to look for. > If I > > > > > create AT this year — and each month after release — for all years > - a > > > new > > > > > site can use a new set of words — there is no way I can design my > AT > > > now to > > > > > work with sites that use different sets of words that I don’t know > what > > > > > they will be. In order for this to work — you must tell me the > > > functions > > > > > AND the terms that will be used (or tell me that each technology > will > > > use a > > > > > standard set of terms for that technology. (e.g. HTML will define > the > > > terms > > > > > for HTML, PDF for PDF, etc.) Unless someone can tell me another > way an > > > AT > > > > > vendor can know what the terms for those functions are in a > > > > > programmatically determinable way. > > > > > > > > > > — > > > > > You are receiving this because you are subscribed to this thread. > > > > > Reply to this email directly, view it on GitHub > > > > > <#635>, or mute the thread > > > > > <https://github.com/notifications/unsubscribe-auth/ABK- > > > czKwicKADnieNtV9NMU1ScNXkjl9ks5tA_UjgaJpZM4REY2y> > > > > > . > > > > > > > > > > > > > > > > > > > > > -- > > > > John Foliot > > > > Principal Accessibility Strategist > > > > Deque Systems Inc. > > > > ***@***.*** > > > > > > > > Advancing the mission of digital accessibility and inclusion > > > > — > > > > You are receiving this because you authored the thread. > > > > Reply to this email directly, view it on GitHub < > https://github.com/w3c/ > > > wcag21/issues/635#issuecomment-352201706>, or mute the thread < > > > https://github.com/notifications/unsubscribe-auth/ > > > AJph3j7urR46441VX4MHx9BdT9cVaUP1ks5tBAxMgaJpZM4REY2y>. > > > > > > > > > > — > > > You are receiving this because you commented. > > > Reply to this email directly, view it on GitHub > > > <#635 (comment)>, or > mute > > > the thread > > > <https://github.com/notifications/unsubscribe-auth/ABK- > c0vcBdxkZWCxutxfFkp3dmuYo02gks5tCdnTgaJpZM4REY2y> > > > . > > > > > > > > > > > -- > > John Foliot > > Principal Accessibility Strategist > > Deque Systems Inc. > > ***@***.*** > > > > Advancing the mission of digital accessibility and inclusion > > — > > You are receiving this because you authored the thread. > > Reply to this email directly, view it on GitHub <https://github.com/w3c/ > wcag21/issues/635#issuecomment-353413400>, or mute the thread < > https://github.com/notifications/unsubscribe-auth/ > AJph3uqy6SpnoqrRXK6rK8TS7rp6qU-pks5tCplhgaJpZM4REY2y>. > > > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <#635 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/ABK-c2wGj7jzYy_cgVYc-AigHpPcMS_0ks5tCppKgaJpZM4REY2y> > . > -- John Foliot Principal Accessibility Strategist Deque Systems Inc. ***@***.*** Advancing the mission of digital accessibility and inclusion — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#635 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJph3hjwcTA9A9S2O72se7g6lJzNTt3Jks5tCrROgaJpZM4REY2y>.

[johnfoliot]

Gregg, The *Definitions* listed at Chapter 7 <http://rawgit.com/w3c/wcag21/master/guidelines/index.html#commonpurposes> of the draft is what is normative (which is why that long list is not an external document, but tagged on to the bottom of the latest draft). The terms (handles? names?) related to the definitions are themselves not normative per-se, but very useful in allowing actual metadata vocabularies to have both a short handle and longer description of the concepts that we are mandating needing to be 'tagged' - and tagging concepts is the end-game here, not terms; it's the common understanding behind the term that is critical to this SC. From that list, *you can (if you so desire) map any term you want* to any of those normative definitions, and as long as you have done so (as the metadata vocabulary author) you are on the path to success. In other words, if it walks like a duck, and quacks like a duck, you can still tag it by the term "canard", as long as your public vocabulary states *"In the Vanderheiden vocabulary, Canard = [WCAG 2.1's normative definition for the handle known as Duck (+/- extremely minor editorial differences)]"* - it's the concept that counts, not the term, which can change by metadata vocabulary. Then, assuming your private metadata vocabulary has an accessibility supported lookup mechanism (namespaced? URI ref? other?), the machines will be able to go to your definition and determine that when Gregg uses the metadata term of "canard" he means WCAG 2.1's defined concept of "Duck". But using the term "canard" alone, <element itemscope itemtype="canard">Bird</element> <!-- Using Microdata annotation --> ...with no referenced metadata vocabulary does not achieve the goal, as nobody would know what you meant by canard (it could easily also mean "...*a false or baseless, usually derogatory story, report, or rumor.*" [source: http://www.dictionary.com/browse/canard].) *Thus the term isn't that important,* *the definition is.* And as previously noted, *defining a specific metadata vocabulary is out of scope for this WG* (which, as I re-read your notes, seems to be what you are looking for - terms AND definitions), which is how we got to where we are today: specifying concepts normatively that need to be mapped to terms (which, abstractly, any term will work if it maps to the correct concept, and linked via a public vocabulary that shows your proprietary term = WCAG 2.1's definition for any given concept). JF

…

On Thu, Dec 21, 2017 at 1:56 PM, GreggVan ***@***.***> wrote: > On Dec 21, 2017, at 2:41 PM, John Foliot ***@***.***> wrote: > > Gregg, > > Let me back this up a bit: would you prefer we *mandate the use of a single > normative metadata schema here*, or is it preferable to say "Use a schema > that is publicly available and accessibility supported" and leave it to the > author to choose which schema best suits their needs? People can use whatever schema they want — AS LONG AS there is a way to tie that schema back to the items in your list in WCAG 2.1 right now you do not have a way — since you do not specify anything that can be used as and ID as normative. IF - you use the term you have here OR - if you give each one a number OR - you give each one ANY Normative handle it works. easiest - is to make the term normative and in techniques describe how to use any other schema to link back to it. OR - number each one and make the number fixed and normative (also works but a bit of a pain to use and more prone to error) > > > > What I had said was the referent — you are saying would be the URL. > > ​> ​ > that is fine. But you have not defined the URL for each of the concepts in > the SC. > > > ​Once again, this depends on what metadata schema you use​. Yes, I can map > all of the current 'handles' to a Schema.org definition (I've done so > already), *but not all metadata schemas have unique URLs for each > definition*. We have a normative list of common "handles" and clear > definitions, and how any schema references those definitions will be > dependant on the schemas vocabulary structure and the inline annotation > method used to apply the definition to the control. You can’t map anything back to the SC list if they list has no handles. > > > ​>​ > When you do — you will have satisfied what I have been asking for. It can > be > > ​> ​ > a name > > > ​​ > For > ​metadata > vocabularies that use namespacing and > ​inline values (​ > terms > ​)​ > , the "name" will be the related term specific to that > ​ specific​ > vocabulary > ​. > As AWK previously pointed out, one vocabulary may use the term "toc", while > another vocabulary may use "TableOfContents"​, and the Gregg-Vanderheiden > vocabulary uses " > anccoy > ​". That really shouldn't matter (and in practice, doesn't). > > As long as all three vocabularies bind their terms (names) to a common > definition > "View or go to a table of contents" [link type] > ​, which term you use will then be dependant on the namespace lookup > declaration (or method that you use to link the public vocabulary to the > page/element)​. > > ​ > > ​> > a number > > > ​??? This feels over-engineered. That said, we could provide, as part of > the Understanding documentation, a "mapping table" that uses numbers as > KeyID values, and then list our "common term/handle", the normative > definition, and then pointers to one or more metadata schemas that shows > how the annotation would work, and the value to point to​ - but that would > all be non-normative and illustrative, as we do not want to mandate the use > of a specific metadata vocabulary: > > [image: Inline image 2] > ​ > ​​ > > ​> ​ > a URL > > ​ > ​ > For > ​metadata > vocabularies that use direct URLs to definitions (such as, but not limited > to, Schema.org), the "name" will be the related term specified at the URL > . > ​Not all metadata schemas however are constructed in this fashion - many > do not resolve to unique URLS per definition. > > > > but it needs to be determinant and there is nothing determinant — there > is no stable handle — for each of the terms in the list. > > ​That's a feature Gregg, not a bug. We want to leave *which* metadata > vocabulary the author uses open to the author to choose, and/but different > vocabularies may have different 'terms' for the same conceptual idea. We > need to recognize that fact. > > So, as long as the vocabulary has public definitions, and those definitions > map to the *normatively defined​ "Common Purposes"* definitions we've > articulated > <http://rawgit.com/w3c/wcag21/master/guidelines/index.html# commonpurposes>, > then the method by which the schema supplies the metadata is dependant on > the annotation method used by that particular vocabulary - and not all > annotation methods use "terms" (and even when they do, how the"term" is > applied also varies - it could be an attribute, a class value string, or an > attribute value string). > > One overarching goal was to avoid being *too* prescriptive with regards to > Techniques ("Thou MUST use the Vanderheiden metadata values on the > following controls:...") - yet the only way to ensure *normative terms* is > to specify a unique metadata vocabulary (and thus that vocabulary's terms), > and specifying or defining a metadata schema is outside the scope of this > Working Group (i.e. we SHOULD reuse what is already out there). > > JF > > > > On Thu, Dec 21, 2017 at 11:50 AM, GreggVan ***@***.***> wrote: > > > to make a long posting short > > > > What I had said was the referent — you are saying would be the URL. > > that is fine. But you have not defined the URL for each of the concepts in > > the SC. > > > > When you do — you will have satisfied what I have been asking for. It can > > be > > a name > > a number > > a URL > > > > but it needs to be determinant and there is nothing determinant — there is > > no stable handle — for each of the terms in the list. > > > > Does that help? > > > > Gregg > > > > > > > On Dec 21, 2017, at 12:46 PM, John Foliot ***@***.***> > > wrote: > > > > > > Hi Gregg, > > > > > > You wrote: > > > > > > > *In order for metadata to work you need both the definition of the term > > > and the term. For example here are my terms for the definitions - in > > > alphabetical order. I publish them with definitions on my website under > > > “example.com/data/decoding/wcag21/metadata.db > > > <http://example.com/data/decoding/wcag21/metadata.db>* > > > > > > *then I use them on my page. Here are 4 words I use on my page - in > > > alphabetical order. ‘* > > > > > > *anccoy* > > > *Jmeoaz* > > > *ljerras* > > > *slijnjope * > > > > > > *How does a piece of AT know what they mean? * > > > > > > Namespacing > > > <https://msdn.microsoft.com/en-us/library/ms754619(v=vs.85).aspx>. > > > Different schemas may have different terms for the same (or equivalent) > > > concepts, and we do not want to restrict this SC to a single metadata > > > schema or annotation format. However, using Microdata annotation, the > > > namespacing happens when you supply the value (which is a URL string to > > the > > > definition). But that is but one method of doing the "lookup" or the > > > linking of controls to definitions. > > > > > > > > > > *otherwise you have a bunch of definitions that someone else can make > > up > > > words for that you do not know how to decode. * > > > > > > > > > Partially correct: you can make up your own terms, however 2 points to > > > remember: > > > > > > #1, for the metadata to be useful, there needs to be the > > > namespacing/lookup mechanism. In Microdata annotation, the url that *is* > > > the definitionis the value string. Other metadata schemas use global > > > namespacing and declarations in the document <head>, such as Dublin Core > > > (not recommended, as that is document level metadata, and not element > > level > > > microdata) or TEI (which also allows for customization > > > <http://www.tei-c.org/Guidelines/Customization/index.xml> through > > classes > > > and attributes). The emergent Personalization Semantics > > > <https://www.w3.org/TR/personalization-semantics-1.0/> uses inline > > > attributes (without "namespacing", but via reserved attribute strings and > > > values just like ARIA)... so the method is less important than the > > result. > > > > > > #2, you would have to warrant and prove that your definitions at > > > example.com/data/decoding/wcag21/metadata.db could in fact be > > accessibility > > > supported: that web-browsers and an AT tool can do the appropriate > > > namespace lookup required to close this loop. > > > > > > > > > > > > > *problem 2 is that you need to* > > > > > > *a) have a normative way of finding this list of new terms —* > > > > > > ​This depends on the metadata schema and usage rules. However, whether > > > inline or as part of a global header declaration, metadata schemas all > > > provide normative terms and definitions, and a mechanism for "looking up" > > > the definition. > > > This SC essentially states that for whatever metadata schema you choose, > > it > > > must have a > > > ​schema-level ​ > > > term *that matches our list of definitions*. Thus, when the AT does the > > > namespaced lookup for the term declared > > > ​ (your "Jmeoaz")​ > > > , it arrives at the "common definition" we require > > > ​ ​ > > > (Contact us - View the contact information for content owner or producer > > > <http://rawgit.com/w3c/wcag21/master/guidelines/index.html# > > commonpurposes>)​ > > > . > > > ​ ​ > > > > > > > > > *b) define normatively the data format for this decoding database.* > > > > > > ​I disagree. The data format is not critical here (important, yes, > > > critical, no), rather it's the middleware that will be doing something > > > useful with the metadata values - *and that middleware will need to be > > > accessibly supported​* to be able to successfully meet this SC. > > > That said, perhaps we *should* further state that custom metadata schemas > > > must be declared using RDF or RDFa (???) - but that too feels like a bit > > of > > > an over-reach. > > > > > > > > > * and* > > > > > > * c) require that the reference to the list be on every page - since we > > > evaluate by page - or it has to be in a normative place on every website > > > (not practical)* > > > > > > ​...and again, I disagree. It depends on the (accessibility supported) > > > metadata schema the author chooses. Some schemas have a global namespace > > > declaration in the document <head> (and so, via HTML page templating, > > this > > > could indeed may be VERY easy & practical to accomplish): > > > > > > <head> > > > <link rel="schema.VANDERHEIDEN" > > > href="http://example.com/data/decoding/wcag21/metadata/" > > > /> > > > </head> > > > + > > > <body> > > > <a href="contactpage.html" class="Jmeoaz"> > > > ​ > > > お問い合わせ</a> > > > <!-- presumes your metadata schema uses class values to apply inline > > > term definitions, and is accessibility supported --> > > > > > > </body> > > > > > > > > > > > > Others can use Microdata annotation (where again the definition *IS* the > > > URL string to the normative text(s)): > > > > > > <element itemscope itemtype="http://example.com/data/decoding/ > > > wcag21/metadata/%Value">*Non-normative term*</element> > > > > > > > > > > > > Or, as in Personalization Semantics (or TEI), it can be dependant on a > > > reserved list of attributes or class values: > > > > > > <button coga-action="undo"> > > > ​ > > > *Non-normative term*</button> > > > > > > > > > > > > ​> > > > *See the problem?* > > > > > > > > > ​ > > > ​Actually, no, I don't​. > > > (If anything, with respect Gregg, > > > ​ > > > the problem > > > ​ as I see it​ > > > is that you aren't understanding > > > ​how to apply element level metadata > > > fully, which, if nothing else, underscores a bigger concern - will others > > > understand the ask here > > > ​ as well?​ Or will they be confused > > > ?) > > > > > > > > > > > > > ​ > > > *All metadata has the same internationalization concern. None of them say > > > — "so you can use any terms you want as long as you document it” * > > > > > > ​Respectfully, I must disagree. ​Most (many) metadata schemes appear to > > > allow for further extension or customization: > > > > > > Schema.org <http://schema.org/docs/extension.html>: "*There are two > > kinds > > > of extensions: reviewed/hosted extensions and external extensions. Both > > > kinds of extensions typically add subclasses and properties to the core. > > > Properties may be added to existing and/or new classes.*" > > > > > > TEI > > > <http://www.tei-c.org/Guidelines/Customization/odds. > > xml#body.1_div.2_div.3>: > > > "*A schema can include declarations for new elements,* *..."* > > > > > > Microformats <http://microformats.org/wiki/process>: "*So you wanna > > develop > > > a new microformat? Or just a new vocabulary? Or create a new standard > > based > > > on empirical research and scientific methods? This document will help > > guide > > > you through the steps to take towards achieving these goals.*" > > > (again, I would not recommend Microformats, as it appears *too* > > malleable, > > > given that the definition list(s) is a publicly editable wiki) > > > > > > > > > > > > > *AH but Contact Page is the term. you can’t use schema.org > > > <http://schema.org/> without using the name of the entity first — and > > then > > > attaching any other label that you want. * > > > > *yes but you MUST USE THE TERM. you can’t say "** http://schema.org/* > > お問い合わせ > > > <http://schema.org/%E3%81%8A%E5%95%8F%E3%81%84%E5%90%88%E3% > > 82%8F%E3%81%9B> you > > > must first use the defined name. > > > > > > ​Again, respectfully, this is incorrect. The term we are applying > > metadata > > > to itself is abstract, it is the *definition* that is normative. In my > > > example using Microdata, the term that is being defined is *the value > > > between the element's opening and closing tag*​: > > > > > > > > > <a href="http://example.com/contactus.html" > > > ​ > > > ​ > > > itemscope > > > ​ > > > ​ <!-- required to scope the definition to just this element > > > ​ ​ > > > ​& element value -->​ > > > > > > ​ itemtype="http://schema.org/ContactPage"> <!-- URL to normative > > > definition --> > > > お問い合わせ <!-- Term that is being defined in this instance, *scoped > > > as such* with the *itemscope* attribute --> > > > </a> > > > > > > ​The fact that ​ > > > ​​ > > > お問い合わせ > > > ​ is the Japanese translation of "Contact Page" doesn't really matter, > > > because both terms will point to (reference) the normative definition at > > ​ > > > http://schema.org/ContactPage > > > ​ when encoded using Microdata annotation (as above). > > > > > > As long as > > > http://schema.org/ContactPage > > > ​ resolves to a definition that is equal (or equated) to "View the > > contact > > > information for content owner or producer"​, you will have succeeded. > > > > > > Ditto for your custom schema: if (using Microdata annotation) > > > itemtype="http://example.com/data/decoding/wcag21/metadata/ > > > ​VanderheidenContactDetails.xml​ [sic] > > > also maps back to "View the contact information for content owner or > > > producer" > > > ​ you're good-to-go.​ > > > > > > > > > So, to wrap up, yes, we will need a ​"lookup list" that declares the > > > normative definitions we require, and with those definitions a list of > > > "common" terms that serve as a handle for each definition. That current > > > list is found as "chapter" 7 in the draft WCAG 2.1 spec: > > > http://rawgit.com/w3c/wcag21/master/guidelines/index.html# commonpurposes > > > > > > But critically, the author does not need to use the specific > > terms/handles > > > used in that list, what they need to reference is the actual normative > > > definition. *How they apply that definition* to any given element will > > > depend on which schema the author uses, and how the schema they have > > chosen > > > at the document level mandates applying definitions to conceptual > > elements: > > > > > > - some may use reserved handles/short-terms (referenced as attributes or > > > class values + page-level namespacing), > > > - others may simply point to the URL that constitutes the normative > > > definition (Microdata format) with no actual (reserved) "term" being > > used, > > > - while others may use reserved inline attributes > > > > > ​ & values​ > > > (Personalization Semantics). > > > > > > > > > 3 different techniques, but all will (MUST!) ultimately reference the > > same > > > normative definition. > > > > > > > > > JF > > > > > > On Wed, Dec 20, 2017 at 10:08 PM, GreggVan ***@***.*** > > > wrote: > > > > > > > > > > > > > > > > On Dec 16, 2017, at 1:30 PM, John Foliot < ***@***.***> > > > > wrote: > > > > > > > > > > Hi Gregg, > > > > > > > > > > There seems to be a fair bit of confusion about this, and yet it > > should > > > > be > > > > > quite simple. > > > > > > > > > > The key to this SC, and the bigger 'ask' is to apply *metadata > > directly > > > > to > > > > > those elements* that serve the "common purposes" articulated in the > > list. > > > > > > > > Yep > > > > > > > > > But given internationalization concerns (etc.), the list is > > malleable to > > > > > the extent that it defines concepts, rather than specific terms > > (but, it > > > > > needs terms to start the definition process). > > > > > > > > All metadata has the same internationalization concern. None of them > > say — > > > > "so you can use any terms you want as long as you document it” > > > > > > > > you need to list the referent name or label or handle as well as the > > > > definition. > > > > > > > > > > > > > > The "simplest" explanation can also be articulated in code - a link > > to > > > > > the *Contact > > > > > Us Page*. But to fully illustrate, I'll actually use the Japanese > > > > > equivelant of お問い合わせ. Additionally, I will illustrate this using > > > > Microdata > > > > > annotation, and the Schema.org taxonomy (ontology): > > > > > > > > > > <a href="http://example.com/contactus.html" > > > > > itemscope > > > > > itemtype="http://schema.org/ContactPage">お問い合わせ</a> > > > > > > > > > AH but Contact Page is the term. you can’t use schema.org without > > using > > > > the name of the entity first — and then attaching any other label that > > you > > > > want. > > > > > > > > > > > > > > So, the terms themselves are mostly "placeholders" for the more > > important > > > > > definitions of concepts - the metadata *values*. With a publicly > > > > available > > > > > Metadata schema, Assistive Technology *CAN* do the look-up, either > > via > > > > the > > > > > "old-school" name-spacing (in the mode of Dublin Core), or, with > > > > Microdata, > > > > > following the URL to the explicitly defined concept. At the end of > > the > > > > day, > > > > > the disambiguation happens at the defined (external) vocabulary, and > > as > > > > > long as it is publicly available, AT has the hooks it needs - the > > > > > disambiguated definitions. > > > > > > > > yes but you MUST USE THE TERM. you can’t say " http://schema.org/お問い合わせ > > > > > > > > you must first use the defined name. > > > > > > > > > > > > > > "But what AT today?" you ask. > > > > > > > > > > Welcome to the chicken and egg problem (which I'm sure you are all > > too > > > > > familiar with). As a proof-of-concept tool moving forward (and > > needed for > > > > > the exit criteria), I hope (plan) on seeing a browser extension that > > will > > > > > do a little bit of user style sheet injection when the Microdata > > > > annotation > > > > > is used (not a complete solution, but illustrative) that will, in > > essence > > > > > take advantage of the fact that each term definition is specifically > > > > > referenced at the element level, using a very specific block (or > > string) > > > > of > > > > > text. In my example above, that string is > > > > > > > > > > "...itemtype="http://schema.org/ContactPage"..." > > > > > > > > > > ​...​ > > > > > and so I can use that string as a CSS selector, and then do stuff > > like > > > > > adding a button with icon and text overlay anytime there is a link or > > > > > button (trigger) to the Contact Us Page > > > > > ​.​ > > > > > > > > if you want to say they must use Schema.org then that is fine. > > > > > > > > but I can’t make AT today that will work next year if you use > > > > http://FoliotScheme.org/お問い合わせ <http://foliotscheme.org/%E3%81%8A%E5%95%8F%E3%81%84%E5%90%88%E3%82%8F%E3%81%9B> > > <http://foliotscheme.org/%E3%81%8A%E5%95%8F%E3%81%84%E5%90% 88%E3%82%8F%E3%81%9B> > > > > <http://foliotscheme.org/%E3%81%8A%E5%95%8F%E3%81%84%E5%90% > > 88%E3%82%8F%E3%81%9B> > > > > > > > > > > how will I know what that means? I can haul down your definition in > > > > (japanese but it won’t help my AT programmatically determine the > > function. > > > > > > > > > > > > > > > > > > > > > > > > > > Now, if a large organization wants​ to publish its own taxonomy list, > > > > they > > > > > will need to ensure that the *concepts defined by this SC* will be > > mapped > > > > > to their choice of term and that lookup list is public, but it is the > > > > > definitions that are effectively normative, not the terms: > > > > > > > > Great — but how do I map them back to the terms if there are no known > > > > stable handles for each term in the SC? > > > > > > > > > > > > > > > > > > *​Non-normative Term: * *Normative definition* (taken > > > > > from Merriam-Webster <https://www.merriam-webster. com/dictionary/dog > > > > > > > for > > > > > illustration purposes only): > > > > > dog canid: wolves, > > > > > foxes, and other dogs; especially : a highly variable domestic mammal > > > > > (Canis > > > > > familiaris) closely related to the gray wolf > > > > > > > > > > chien​ canid: wolves, > > > > > foxes, and other dogs; especially : a highly variable domestic mammal > > > > > (Canis > > > > > familiaris) closely related to the gray wolf > > > > > > > > > > ​ puppy canid: wolves, > > > > > foxes, and other dogs; especially : a highly variable domestic mammal > > > > > (Canis > > > > > familiaris) closely related to the gray wolf > > > > > > > > > > ​ fur-baby canid: wolves, > > > > > foxes, and other dogs; especially : a highly variable domestic mammal > > > > > (Canis > > > > > familiaris) closely related to the gray wolf > > > > > > > > > > Make sense? > > > > > > > > Not unless you assume that everyone knows english. > > > > > > > > if you used english terms for the 20 or so items — I could know what > > the > > > > translation to my country’s language was’’’ > > > > > > > > or even if you numbered them. > > > > > > > > But you need some stable referent > > > > > > > > > > > > > > > > > > > > > > JF > > > > > > > > > > On Sat, Dec 16, 2017 at 10:51 AM, GreggVan < ***@***.*** > > > > > > > wrote: > > > > > > > > > > > Success Criterion 1.3.4 Identify Common Purpose§ > > > > > > (Level AA) [New] > > > > > > In content implemented using markup languages, for each user > > interface > > > > > > component that serves a purpose identified in the Common Purposes > > for > > > > User > > > > > > Interface Components section, that purpose can be programmatically > > > > > > determined. > > > > > > > > > > > > I thought you had this one solved — until I heard that you now > > don’t > > > > mean > > > > > > that they terms in the list are the terms that need to be used — > > but > > > > rather > > > > > > that any set of terms can be used for those functions as long as > > they > > > > are > > > > > > documented somewhere. This is no way for this to meet > > “accessibility > > > > > > supported” if AT have no idea in advance what words to look for. > > If I > > > > > > create AT this year — and each month after release — for all years > > - a > > > > new > > > > > > site can use a new set of words — there is no way I can design my > > AT > > > > now to > > > > > > work with sites that use different sets of words that I don’t know > > what > > > > > > they will be. In order for this to work — you must tell me the > > > > functions > > > > > > AND the terms that will be used (or tell me that each technology > > will > > > > use a > > > > > > standard set of terms for that technology. (e.g. HTML will define > > the > > > > terms > > > > > > for HTML, PDF for PDF, etc.) Unless someone can tell me another > > way an > > > > AT > > > > > > vendor can know what the terms for those functions are in a > > > > > > programmatically determinable way. > > > > > > > > > > > > — > > > > > > You are receiving this because you are subscribed to this thread. > > > > > > Reply to this email directly, view it on GitHub > > > > > > <#635>, or mute the thread > > > > > > <https://github.com/notifications/unsubscribe-auth/ABK- > > > > czKwicKADnieNtV9NMU1ScNXkjl9ks5tA_UjgaJpZM4REY2y> > > > > > > . > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > John Foliot > > > > > Principal Accessibility Strategist > > > > > Deque Systems Inc. > > > > > ***@***.*** > > > > > > > > > > Advancing the mission of digital accessibility and inclusion > > > > > — > > > > > You are receiving this because you authored the thread. > > > > > Reply to this email directly, view it on GitHub < > > https://github.com/w3c/ > > > > wcag21/issues/635#issuecomment-352201706>, or mute the thread < > > > > https://github.com/notifications/unsubscribe-auth/ > > > > AJph3j7urR46441VX4MHx9BdT9cVaUP1ks5tBAxMgaJpZM4REY2y>. > > > > > > > > > > > > > — > > > > You are receiving this because you commented. > > > > Reply to this email directly, view it on GitHub > > > > <#635 (comment)>, or > > mute > > > > the thread > > > > <https://github.com/notifications/unsubscribe-auth/ABK- > > c0vcBdxkZWCxutxfFkp3dmuYo02gks5tCdnTgaJpZM4REY2y> > > > > . > > > > > > > > > > > > > > > > -- > > > John Foliot > > > Principal Accessibility Strategist > > > Deque Systems Inc. > > > ***@***.*** > > > > > > Advancing the mission of digital accessibility and inclusion > > > — > > > You are receiving this because you authored the thread. > > > Reply to this email directly, view it on GitHub < https://github.com/w3c/ > > wcag21/issues/635#issuecomment-353413400>, or mute the thread < > > https://github.com/notifications/unsubscribe-auth/ > > AJph3uqy6SpnoqrRXK6rK8TS7rp6qU-pks5tCplhgaJpZM4REY2y>. > > > > > > > — > > You are receiving this because you commented. > > Reply to this email directly, view it on GitHub > > <#635 (comment)>, or mute > > the thread > > <https://github.com/notifications/unsubscribe- auth/ABK-c2wGj7jzYy_cgVYc-AigHpPcMS_0ks5tCppKgaJpZM4REY2y> > > . > > > > > > -- > John Foliot > Principal Accessibility Strategist > Deque Systems Inc. > ***@***.*** > > Advancing the mission of digital accessibility and inclusion > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub <https://github.com/w3c/ wcag21/issues/635#issuecomment-353439809>, or mute the thread < https://github.com/notifications/unsubscribe-auth/ AJph3hjwcTA9A9S2O72se7g6lJzNTt3Jks5tCrROgaJpZM4REY2y>. > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#635 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABK-c1fwwWTFBGVehTZaZmuG6MOX2Ajnks5tCrfngaJpZM4REY2y> .

-- John Foliot Principal Accessibility Strategist Deque Systems Inc. [email protected] Advancing the mission of digital accessibility and inclusion

[DavidMacDonald]

Could we solve this issue by simply numbering each of the items in our list? It's not a new schema... it's a list of items for WCAG in our conformance which can now be referred to numerically.

1. Table of Contents - View or go to a table of contents
2. Next - View or go to the next item in a series (e.g. a page in a book or next article)
3. Previous - View or go to the previous item in a series
4. Reply - Reply to current item (e.g. an email)
5. Forward - Forward the current item (e.g. an email)
6. Inbox - View the inbox (e.g. an email application inbox)

[GreggVan]

yes — that is what I thought was the case. Until I was told that the names in the list were NOT normative (please see my original comment). So that left nothing in the list that you could refer to.

*”In the Vanderheiden vocabulary, Canard = [WCAG 2.1's normative definition for the handle known as Duck (+/- extremely minor editorial differences)]"* -

The problem. I was told that Duck was not normative and should not be used to identify the concept. I don’t see the logic in that — but was told that. So my comment (that started this ) was … This looked good until I was told that the term in the list was not to be used to identify the concept. If that is wrong — then we go back to status-quo-ante and we are all set. If not — then all your discussions below don’t work because the require mapping and you can’t map if there is no stable referent. Gregg

…

On Dec 21, 2017, at 4:00 PM, John Foliot ***@***.***> wrote: Gregg, The *Definitions* listed at Chapter 7 <http://rawgit.com/w3c/wcag21/master/guidelines/index.html#commonpurposes> of the draft is what is normative (which is why that long list is not an external document, but tagged on to the bottom of the latest draft). The terms (handles? names?) related to the definitions are themselves not normative per-se, but very useful in allowing actual metadata vocabularies to have both a short handle and longer description of the concepts that we are mandating needing to be 'tagged' - and tagging concepts is the end-game here, not terms; it's the common understanding behind the term that is critical to this SC. From that list, *you can (if you so desire) map any term you want* to any of those normative definitions, and as long as you have done so (as the metadata vocabulary author) you are on the path to success. In other words, if it walks like a duck, and quacks like a duck, you can still tag it by the term "canard", as long as your public vocabulary states *"In the Vanderheiden vocabulary, Canard = [WCAG 2.1's normative definition for the handle known as Duck (+/- extremely minor editorial differences)]"* - it's the concept that counts, not the term, which can change by metadata vocabulary. Then, assuming your private metadata vocabulary has an accessibility supported lookup mechanism (namespaced? URI ref? other?), the machines will be able to go to your definition and determine that when Gregg uses the metadata term of "canard" he means WCAG 2.1's defined concept of "Duck". But using the term "canard" alone, <element itemscope itemtype="canard">Bird</element> <!-- Using Microdata annotation --> ...with no referenced metadata vocabulary does not achieve the goal, as nobody would know what you meant by canard (it could easily also mean "...*a false or baseless, usually derogatory story, report, or rumor.*" [source: http://www.dictionary.com/browse/canard].) *Thus the term isn't that important,* *the definition is.* And as previously noted, *defining a specific metadata vocabulary is out of scope for this WG* (which, as I re-read your notes, seems to be what you are looking for - terms AND definitions), which is how we got to where we are today: specifying concepts normatively that need to be mapped to terms (which, abstractly, any term will work if it maps to the correct concept, and linked via a public vocabulary that shows your proprietary term = WCAG 2.1's definition for any given concept). JF On Thu, Dec 21, 2017 at 1:56 PM, GreggVan ***@***.***> wrote: > > > > On Dec 21, 2017, at 2:41 PM, John Foliot ***@***.***> > wrote: > > > > Gregg, > > > > Let me back this up a bit: would you prefer we *mandate the use of a > single > > normative metadata schema here*, or is it preferable to say "Use a schema > > that is publicly available and accessibility supported" and leave it to > the > > author to choose which schema best suits their needs? > > People can use whatever schema they want — AS LONG AS there is a way to > tie that schema back to the items in your list in WCAG 2.1 > > right now you do not have a way — since you do not specify anything that > can be used as and ID as normative. > > IF - you use the term you have here > OR - if you give each one a number > OR - you give each one ANY Normative handle > > it works. > > easiest - is to make the term normative and in techniques describe how to > use any other schema to link back to it. > OR - number each one and make the number fixed and normative (also works > but a bit of a pain to use and more prone to error) > > > > > > > > > What I had said was the referent — you are saying would be the URL. > > > > ​> ​ > > that is fine. But you have not defined the URL for each of the concepts > in > > the SC. > > > > > > ​Once again, this depends on what metadata schema you use​. Yes, I can > map > > all of the current 'handles' to a Schema.org definition (I've done so > > already), *but not all metadata schemas have unique URLs for each > > definition*. We have a normative list of common "handles" and clear > > definitions, and how any schema references those definitions will be > > dependant on the schemas vocabulary structure and the inline annotation > > method used to apply the definition to the control. > > > You can’t map anything back to the SC list if they list has no handles. > > > > > > ​>​ > > When you do — you will have satisfied what I have been asking for. It can > > be > > > > ​> ​ > > a name > > > > > > ​​ > > For > > ​metadata > > vocabularies that use namespacing and > > ​inline values (​ > > terms > > ​)​ > > , the "name" will be the related term specific to that > > ​ specific​ > > vocabulary > > ​. > > As AWK previously pointed out, one vocabulary may use the term "toc", > while > > another vocabulary may use "TableOfContents"​, and the Gregg-Vanderheiden > > vocabulary uses " > > anccoy > > ​". That really shouldn't matter (and in practice, doesn't). > > > > As long as all three vocabularies bind their terms (names) to a common > > definition > > "View or go to a table of contents" [link type] > > ​, which term you use will then be dependant on the namespace lookup > > declaration (or method that you use to link the public vocabulary to the > > page/element)​. > > > > ​ > > > > ​> > > a number > > > > > > ​??? This feels over-engineered. That said, we could provide, as part of > > the Understanding documentation, a "mapping table" that uses numbers as > > KeyID values, and then list our "common term/handle", the normative > > definition, and then pointers to one or more metadata schemas that shows > > how the annotation would work, and the value to point to​ - but that > would > > all be non-normative and illustrative, as we do not want to mandate the > use > > of a specific metadata vocabulary: > > > > [image: Inline image 2] > > ​ > > ​​ > > > > ​> ​ > > a URL > > > > ​ > > ​ > > For > > ​metadata > > vocabularies that use direct URLs to definitions (such as, but not > limited > > to, Schema.org), the "name" will be the related term specified at the URL > > . > > ​Not all metadata schemas however are constructed in this fashion - many > > do not resolve to unique URLS per definition. > > > > > > > but it needs to be determinant and there is nothing determinant — there > > is no stable handle — for each of the terms in the list. > > > > ​That's a feature Gregg, not a bug. We want to leave *which* metadata > > vocabulary the author uses open to the author to choose, and/but > different > > vocabularies may have different 'terms' for the same conceptual idea. We > > need to recognize that fact. > > > > So, as long as the vocabulary has public definitions, and those > definitions > > map to the *normatively defined​ "Common Purposes"* definitions we've > > articulated > > <http://rawgit.com/w3c/wcag21/master/guidelines/index.html# > commonpurposes>, > > then the method by which the schema supplies the metadata is dependant on > > the annotation method used by that particular vocabulary - and not all > > annotation methods use "terms" (and even when they do, how the"term" is > > applied also varies - it could be an attribute, a class value string, or > an > > attribute value string). > > > > One overarching goal was to avoid being *too* prescriptive with regards > to > > Techniques ("Thou MUST use the Vanderheiden metadata values on the > > following controls:...") - yet the only way to ensure *normative terms* > is > > > to specify a unique metadata vocabulary (and thus that vocabulary's > terms), > > and specifying or defining a metadata schema is outside the scope of this > > Working Group (i.e. we SHOULD reuse what is already out there). > > > > JF > > > > > > > > On Thu, Dec 21, 2017 at 11:50 AM, GreggVan ***@***.***> > wrote: > > > > > to make a long posting short > > > > > > What I had said was the referent — you are saying would be the URL. > > > that is fine. But you have not defined the URL for each of the > concepts in > > > the SC. > > > > > > When you do — you will have satisfied what I have been asking for. It > can > > > be > > > a name > > > a number > > > a URL > > > > > > but it needs to be determinant and there is nothing determinant — > there is > > > no stable handle — for each of the terms in the list. > > > > > > Does that help? > > > > > > Gregg > > > > > > > > > > On Dec 21, 2017, at 12:46 PM, John Foliot ***@***.***> > > > wrote: > > > > > > > > Hi Gregg, > > > > > > > > You wrote: > > > > > > > > > *In order for metadata to work you need both the definition of the > term > > > > and the term. For example here are my terms for the definitions - in > > > > alphabetical order. I publish them with definitions on my website > under > > > > “example.com/data/decoding/wcag21/metadata.db > > > > <http://example.com/data/decoding/wcag21/metadata.db>* > > > > > > > > *then I use them on my page. Here are 4 words I use on my page - in > > > > alphabetical order. ‘* > > > > > > > > *anccoy* > > > > *Jmeoaz* > > > > *ljerras* > > > > *slijnjope * > > > > > > > > *How does a piece of AT know what they mean? * > > > > > > > > Namespacing > > > > <https://msdn.microsoft.com/en-us/library/ms754619(v=vs.85).aspx>. > > > > Different schemas may have different terms for the same (or > equivalent) > > > > concepts, and we do not want to restrict this SC to a single metadata > > > > schema or annotation format. However, using Microdata annotation, the > > > > namespacing happens when you supply the value (which is a URL string > to > > > the > > > > definition). But that is but one method of doing the "lookup" or the > > > > linking of controls to definitions. > > > > > > > > > > > > > *otherwise you have a bunch of definitions that someone else can > make > > > up > > > > words for that you do not know how to decode. * > > > > > > > > > > > > Partially correct: you can make up your own terms, however 2 points > to > > > > remember: > > > > > > > > #1, for the metadata to be useful, there needs to be the > > > > namespacing/lookup mechanism. In Microdata annotation, the url that > *is* > > > > the definitionis the value string. Other metadata schemas use global > > > > namespacing and declarations in the document <head>, such as Dublin > Core > > > > (not recommended, as that is document level metadata, and not element > > > level > > > > microdata) or TEI (which also allows for customization > > > > <http://www.tei-c.org/Guidelines/Customization/index.xml> through > > > classes > > > > and attributes). The emergent Personalization Semantics > > > > <https://www.w3.org/TR/personalization-semantics-1.0/> uses inline > > > > attributes (without "namespacing", but via reserved attribute > strings and > > > > values just like ARIA)... so the method is less important than the > > > result. > > > > > > > > #2, you would have to warrant and prove that your definitions at > > > > example.com/data/decoding/wcag21/metadata.db could in fact be > > > accessibility > > > > supported: that web-browsers and an AT tool can do the appropriate > > > > namespace lookup required to close this loop. > > > > > > > > > > > > > > > > > *problem 2 is that you need to* > > > > > > > > *a) have a normative way of finding this list of new terms —* > > > > > > > > ​This depends on the metadata schema and usage rules. However, > whether > > > > inline or as part of a global header declaration, metadata schemas > all > > > > provide normative terms and definitions, and a mechanism for > "looking up" > > > > the definition. > > > > This SC essentially states that for whatever metadata schema you > choose, > > > it > > > > must have a > > > > ​schema-level ​ > > > > term *that matches our list of definitions*. Thus, when the AT does > the > > > > namespaced lookup for the term declared > > > > ​ (your "Jmeoaz")​ > > > > , it arrives at the "common definition" we require > > > > ​ ​ > > > > (Contact us - View the contact information for content owner or > producer > > > > <http://rawgit.com/w3c/wcag21/master/guidelines/index.html# > > > commonpurposes>)​ > > > > . > > > > ​ ​ > > > > > > > > > > > > *b) define normatively the data format for this decoding database.* > > > > > > > > ​I disagree. The data format is not critical here (important, yes, > > > > critical, no), rather it's the middleware that will be doing > something > > > > useful with the metadata values - *and that middleware will need to > be > > > > accessibly supported​* to be able to successfully meet this SC. > > > > That said, perhaps we *should* further state that custom metadata > schemas > > > > must be declared using RDF or RDFa (???) - but that too feels like a > bit > > > of > > > > an over-reach. > > > > > > > > > > > > * and* > > > > > > > > * c) require that the reference to the list be on every page - since > we > > > > evaluate by page - or it has to be in a normative place on every > website > > > > (not practical)* > > > > > > > > ​...and again, I disagree. It depends on the (accessibility > supported) > > > > metadata schema the author chooses. Some schemas have a global > namespace > > > > declaration in the document <head> (and so, via HTML page templating, > > > this > > > > could indeed may be VERY easy & practical to accomplish): > > > > > > > > <head> > > > > <link rel="schema.VANDERHEIDEN" > > > > href="http://example.com/data/decoding/wcag21/metadata/" > > > > /> > > > > </head> > > > > + > > > > <body> > > > > <a href="contactpage.html" class="Jmeoaz"> > > > > ​ > > > > お問い合わせ</a> > > > > <!-- presumes your metadata schema uses class values to apply inline > > > > term definitions, and is accessibility supported --> > > > > > > > > </body> > > > > > > > > > > > > > > > > Others can use Microdata annotation (where again the definition *IS* > the > > > > URL string to the normative text(s)): > > > > > > > > <element itemscope itemtype="http://example.com/data/decoding/ > > > > wcag21/metadata/%Value">*Non-normative term*</element> > > > > > > > > > > > > > > > > Or, as in Personalization Semantics (or TEI), it can be dependant on > a > > > > reserved list of attributes or class values: > > > > > > > > <button coga-action="undo"> > > > > ​ > > > > *Non-normative term*</button> > > > > > > > > > > > > > > > > ​> > > > > *See the problem?* > > > > > > > > > > > > ​ > > > > ​Actually, no, I don't​. > > > > (If anything, with respect Gregg, > > > > ​ > > > > the problem > > > > ​ as I see it​ > > > > is that you aren't understanding > > > > ​how to apply element level metadata > > > > fully, which, if nothing else, underscores a bigger concern - will > others > > > > understand the ask here > > > > ​ as well?​ Or will they be confused > > > > ?) > > > > > > > > > > > > > > > > > ​ > > > > *All metadata has the same internationalization concern. None of > them say > > > > — "so you can use any terms you want as long as you document it” * > > > > > > > > ​Respectfully, I must disagree. ​Most (many) metadata schemes appear > to > > > > allow for further extension or customization: > > > > > > > > Schema.org <http://schema.org/docs/extension.html>: "*There are two > > > kinds > > > > of extensions: reviewed/hosted extensions and external extensions. > Both > > > > kinds of extensions typically add subclasses and properties to the > core. > > > > Properties may be added to existing and/or new classes.*" > > > > > > > > TEI > > > > <http://www.tei-c.org/Guidelines/Customization/odds. > > > xml#body.1_div.2_div.3>: > > > > "*A schema can include declarations for new elements,* *..."* > > > > > > > > Microformats <http://microformats.org/wiki/process>: "*So you wanna > > > develop > > > > a new microformat? Or just a new vocabulary? Or create a new standard > > > based > > > > on empirical research and scientific methods? This document will help > > > guide > > > > you through the steps to take towards achieving these goals.*" > > > > (again, I would not recommend Microformats, as it appears *too* > > > malleable, > > > > given that the definition list(s) is a publicly editable wiki) > > > > > > > > > > > > > > > > > *AH but Contact Page is the term. you can’t use schema.org > > > > <http://schema.org/> without using the name of the entity first — > and > > > then > > > > attaching any other label that you want. * > > > > > *yes but you MUST USE THE TERM. you can’t say "** > http://schema.org/* > > > お問い合わせ > > > > <http://schema.org/%E3%81%8A%E5%95%8F%E3%81%84%E5%90%88%E3% > > > 82%8F%E3%81%9B> you > > > > must first use the defined name. > > > > > > > > ​Again, respectfully, this is incorrect. The term we are applying > > > metadata > > > > to itself is abstract, it is the *definition* that is normative. In > my > > > > example using Microdata, the term that is being defined is *the value > > > > between the element's opening and closing tag*​: > > > > > > > > > > > > <a href="http://example.com/contactus.html" > > > > ​ > > > > ​ > > > > itemscope > > > > ​ > > > > ​ <!-- required to scope the definition to just this element > > > > ​ ​ > > > > ​& element value -->​ > > > > > > > > ​ itemtype="http://schema.org/ContactPage"> <!-- URL to normative > > > > definition --> > > > > お問い合わせ <!-- Term that is being defined in this instance, *scoped > > > > as such* with the *itemscope* attribute --> > > > > </a> > > > > > > > > ​The fact that ​ > > > > ​​ > > > > お問い合わせ > > > > ​ is the Japanese translation of "Contact Page" doesn't really > matter, > > > > because both terms will point to (reference) the normative > definition at > > > ​ > > > > http://schema.org/ContactPage > > > > ​ when encoded using Microdata annotation (as above). > > > > > > > > As long as > > > > http://schema.org/ContactPage > > > > ​ resolves to a definition that is equal (or equated) to "View the > > > contact > > > > information for content owner or producer"​, you will have succeeded. > > > > > > > > Ditto for your custom schema: if (using Microdata annotation) > > > > itemtype="http://example.com/data/decoding/wcag21/metadata/ > > > > ​VanderheidenContactDetails.xml​ [sic] > > > > also maps back to "View the contact information for content owner or > > > > producer" > > > > ​ you're good-to-go.​ > > > > > > > > > > > > So, to wrap up, yes, we will need a ​"lookup list" that declares the > > > > normative definitions we require, and with those definitions a list > of > > > > "common" terms that serve as a handle for each definition. That > current > > > > list is found as "chapter" 7 in the draft WCAG 2.1 spec: > > > > http://rawgit.com/w3c/wcag21/master/guidelines/index.html# > commonpurposes > > > > > > > > But critically, the author does not need to use the specific > > > terms/handles > > > > used in that list, what they need to reference is the actual > normative > > > > definition. *How they apply that definition* to any given element > will > > > > depend on which schema the author uses, and how the schema they have > > > chosen > > > > at the document level mandates applying definitions to conceptual > > > elements: > > > > > > > > - some may use reserved handles/short-terms (referenced as > attributes or > > > > class values + page-level namespacing), > > > > - others may simply point to the URL that constitutes the normative > > > > definition (Microdata format) with no actual (reserved) "term" being > > > used, > > > > - while others may use reserved inline attributes > > > > > > > ​ & values​ > > > > (Personalization Semantics). > > > > > > > > > > > > 3 different techniques, but all will (MUST!) ultimately reference the > > > same > > > > normative definition. > > > > > > > > > > > > JF > > > > > > > > On Wed, Dec 20, 2017 at 10:08 PM, GreggVan ***@***.*** > > > > > wrote: > > > > > > > > > > > > > > > > > > > > On Dec 16, 2017, at 1:30 PM, John Foliot < > ***@***.***> > > > > > wrote: > > > > > > > > > > > > Hi Gregg, > > > > > > > > > > > > There seems to be a fair bit of confusion about this, and yet it > > > should > > > > > be > > > > > > quite simple. > > > > > > > > > > > > The key to this SC, and the bigger 'ask' is to apply *metadata > > > directly > > > > > to > > > > > > those elements* that serve the "common purposes" articulated in > the > > > list. > > > > > > > > > > Yep > > > > > > > > > > > But given internationalization concerns (etc.), the list is > > > malleable to > > > > > > the extent that it defines concepts, rather than specific terms > > > (but, it > > > > > > needs terms to start the definition process). > > > > > > > > > > All metadata has the same internationalization concern. None of > them > > > say — > > > > > "so you can use any terms you want as long as you document it” > > > > > > > > > > you need to list the referent name or label or handle as well as > the > > > > > definition. > > > > > > > > > > > > > > > > > The "simplest" explanation can also be articulated in code - a > link > > > to > > > > > > the *Contact > > > > > > Us Page*. But to fully illustrate, I'll actually use the Japanese > > > > > > equivelant of お問い合わせ. Additionally, I will illustrate this using > > > > > Microdata > > > > > > annotation, and the Schema.org taxonomy (ontology): > > > > > > > > > > > > <a href="http://example.com/contactus.html" > > > > > > itemscope > > > > > > itemtype="http://schema.org/ContactPage">お問い合わせ</a> > > > > > > > > > > > AH but Contact Page is the term. you can’t use schema.org without > > > using > > > > > the name of the entity first — and then attaching any other label > that > > > you > > > > > want. > > > > > > > > > > > > > > > > > So, the terms themselves are mostly "placeholders" for the more > > > important > > > > > > definitions of concepts - the metadata *values*. With a publicly > > > > > available > > > > > > Metadata schema, Assistive Technology *CAN* do the look-up, > either > > > via > > > > > the > > > > > > "old-school" name-spacing (in the mode of Dublin Core), or, with > > > > > Microdata, > > > > > > following the URL to the explicitly defined concept. At the end > of > > > the > > > > > day, > > > > > > the disambiguation happens at the defined (external) vocabulary, > and > > > as > > > > > > long as it is publicly available, AT has the hooks it needs - the > > > > > > disambiguated definitions. > > > > > > > > > > yes but you MUST USE THE TERM. you can’t say " > http://schema.org/お問い合わせ > > > > > > > > > > you must first use the defined name. > > > > > > > > > > > > > > > > > "But what AT today?" you ask. > > > > > > > > > > > > Welcome to the chicken and egg problem (which I'm sure you are > all > > > too > > > > > > familiar with). As a proof-of-concept tool moving forward (and > > > needed for > > > > > > the exit criteria), I hope (plan) on seeing a browser extension > that > > > will > > > > > > do a little bit of user style sheet injection when the Microdata > > > > > annotation > > > > > > is used (not a complete solution, but illustrative) that will, in > > > essence > > > > > > take advantage of the fact that each term definition is > specifically > > > > > > referenced at the element level, using a very specific block (or > > > string) > > > > > of > > > > > > text. In my example above, that string is > > > > > > > > > > > > "...itemtype="http://schema.org/ContactPage"..." > > > > > > > > > > > > ​...​ > > > > > > and so I can use that string as a CSS selector, and then do stuff > > > like > > > > > > adding a button with icon and text overlay anytime there is a > link or > > > > > > button (trigger) to the Contact Us Page > > > > > > ​.​ > > > > > > > > > > if you want to say they must use Schema.org then that is fine. > > > > > > > > > > but I can’t make AT today that will work next year if you use > > > > > http://FoliotScheme.org/お問い合わせ > <http://foliotscheme.org/%E3%81%8A%E5%95%8F%E3%81%84%E5%90%88%E3%82%8F%E3%81%9B> > > > <http://foliotscheme.org/%E3%81%8A%E5%95%8F%E3%81%84%E5%90% > 88%E3%82%8F%E3%81%9B> > > > > > <http://foliotscheme.org/%E3%81%8A%E5%95%8F%E3%81%84%E5%90% > > > > 88%E3%82%8F%E3%81%9B> > > > > > > > > > > > > > how will I know what that means? I can haul down your definition in > > > > > (japanese but it won’t help my AT programmatically determine the > > > function. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Now, if a large organization wants​ to publish its own taxonomy > list, > > > > > they > > > > > > will need to ensure that the *concepts defined by this SC* will > be > > > mapped > > > > > > to their choice of term and that lookup list is public, but it > is the > > > > > > definitions that are effectively normative, not the terms: > > > > > > > > > > Great — but how do I map them back to the terms if there are no > known > > > > > stable handles for each term in the SC? > > > > > > > > > > > > > > > > > > > > > > *​Non-normative Term: * *Normative definition* (taken > > > > > > from Merriam-Webster <https://www.merriam-webster. > com/dictionary/dog > > > > > > > > > for > > > > > > illustration purposes only): > > > > > > dog canid: wolves, > > > > > > foxes, and other dogs; especially : a highly variable domestic > mammal > > > > > > (Canis > > > > > > familiaris) closely related to the gray wolf > > > > > > > > > > > > chien​ canid: wolves, > > > > > > foxes, and other dogs; especially : a highly variable domestic > mammal > > > > > > (Canis > > > > > > familiaris) closely related to the gray wolf > > > > > > > > > > > > ​ puppy canid: wolves, > > > > > > foxes, and other dogs; especially : a highly variable domestic > mammal > > > > > > (Canis > > > > > > familiaris) closely related to the gray wolf > > > > > > > > > > > > ​ fur-baby canid: wolves, > > > > > > foxes, and other dogs; especially : a highly variable domestic > mammal > > > > > > (Canis > > > > > > familiaris) closely related to the gray wolf > > > > > > > > > > > > Make sense? > > > > > > > > > > Not unless you assume that everyone knows english. > > > > > > > > > > if you used english terms for the 20 or so items — I could know > what > > > the > > > > > translation to my country’s language was’’’ > > > > > > > > > > or even if you numbered them. > > > > > > > > > > But you need some stable referent > > > > > > > > > > > > > > > > > > > > > > > > > > > JF > > > > > > > > > > > > On Sat, Dec 16, 2017 at 10:51 AM, GreggVan < > ***@***.*** > > > > > > > > > wrote: > > > > > > > > > > > > > Success Criterion 1.3.4 Identify Common Purpose§ > > > > > > > (Level AA) [New] > > > > > > > In content implemented using markup languages, for each user > > > interface > > > > > > > component that serves a purpose identified in the Common > Purposes > > > for > > > > > User > > > > > > > Interface Components section, that purpose can be > programmatically > > > > > > > determined. > > > > > > > > > > > > > > I thought you had this one solved — until I heard that you now > > > don’t > > > > > mean > > > > > > > that they terms in the list are the terms that need to be used > — > > > but > > > > > rather > > > > > > > that any set of terms can be used for those functions as long > as > > > they > > > > > are > > > > > > > documented somewhere. This is no way for this to meet > > > “accessibility > > > > > > > supported” if AT have no idea in advance what words to look > for. > > > If I > > > > > > > create AT this year — and each month after release — for all > years > > > - a > > > > > new > > > > > > > site can use a new set of words — there is no way I can design > my > > > AT > > > > > now to > > > > > > > work with sites that use different sets of words that I don’t > know > > > what > > > > > > > they will be. In order for this to work — you must tell me the > > > > > functions > > > > > > > AND the terms that will be used (or tell me that each > technology > > > will > > > > > use a > > > > > > > standard set of terms for that technology. (e.g. HTML will > define > > > the > > > > > terms > > > > > > > for HTML, PDF for PDF, etc.) Unless someone can tell me another > > > way an > > > > > AT > > > > > > > vendor can know what the terms for those functions are in a > > > > > > > programmatically determinable way. > > > > > > > > > > > > > > — > > > > > > > You are receiving this because you are subscribed to this > thread. > > > > > > > Reply to this email directly, view it on GitHub > > > > > > > <#635>, or mute the thread > > > > > > > <https://github.com/notifications/unsubscribe-auth/ABK- > > > > > czKwicKADnieNtV9NMU1ScNXkjl9ks5tA_UjgaJpZM4REY2y> > > > > > > > . > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > John Foliot > > > > > > Principal Accessibility Strategist > > > > > > Deque Systems Inc. > > > > > > ***@***.*** > > > > > > > > > > > > Advancing the mission of digital accessibility and inclusion > > > > > > — > > > > > > You are receiving this because you authored the thread. > > > > > > Reply to this email directly, view it on GitHub < > > > https://github.com/w3c/ > > > > > wcag21/issues/635#issuecomment-352201706>, or mute the thread < > > > > > https://github.com/notifications/unsubscribe-auth/ > > > > > AJph3j7urR46441VX4MHx9BdT9cVaUP1ks5tBAxMgaJpZM4REY2y>. > > > > > > > > > > > > > > > > — > > > > > You are receiving this because you commented. > > > > > Reply to this email directly, view it on GitHub > > > > > <#635 (comment)>, > or > > > mute > > > > > the thread > > > > > <https://github.com/notifications/unsubscribe-auth/ABK- > > > c0vcBdxkZWCxutxfFkp3dmuYo02gks5tCdnTgaJpZM4REY2y> > > > > > . > > > > > > > > > > > > > > > > > > > > > -- > > > > John Foliot > > > > Principal Accessibility Strategist > > > > Deque Systems Inc. > > > > ***@***.*** > > > > > > > > Advancing the mission of digital accessibility and inclusion > > > > — > > > > You are receiving this because you authored the thread. > > > > Reply to this email directly, view it on GitHub < > https://github.com/w3c/ > > > wcag21/issues/635#issuecomment-353413400>, or mute the thread < > > > https://github.com/notifications/unsubscribe-auth/ > > > AJph3uqy6SpnoqrRXK6rK8TS7rp6qU-pks5tCplhgaJpZM4REY2y>. > > > > > > > > > > — > > > You are receiving this because you commented. > > > Reply to this email directly, view it on GitHub > > > <#635 (comment)>, or > mute > > > the thread > > > <https://github.com/notifications/unsubscribe- > auth/ABK-c2wGj7jzYy_cgVYc-AigHpPcMS_0ks5tCppKgaJpZM4REY2y> > > > . > > > > > > > > > > > -- > > John Foliot > > Principal Accessibility Strategist > > Deque Systems Inc. > > ***@***.*** > > > > Advancing the mission of digital accessibility and inclusion > > — > > You are receiving this because you authored the thread. > > Reply to this email directly, view it on GitHub <https://github.com/w3c/ > wcag21/issues/635#issuecomment-353439809>, or mute the thread < > https://github.com/notifications/unsubscribe-auth/ > AJph3hjwcTA9A9S2O72se7g6lJzNTt3Jks5tCrROgaJpZM4REY2y>. > > > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <#635 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/ABK-c1fwwWTFBGVehTZaZmuG6MOX2Ajnks5tCrfngaJpZM4REY2y> > . > -- John Foliot Principal Accessibility Strategist Deque Systems Inc. ***@***.*** Advancing the mission of digital accessibility and inclusion — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#635 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJph3rblHsGBuigIWlLn5wBf3nKVp6Rqks5tCsbrgaJpZM4REY2y>.

[johnfoliot]

Hi Gregg,

Until I was told that the names in the list were NOT normative (please

see my original comment). ​Not sure who told you that, as it is not written in the SC or Draft WCAG 2.1 anywhere. Sorry if you were mislead. Those terms/handles are non-normative as far as metadata values are concerned, but normative as part of the two-part list of handles and concepts that need to be tagged (our term and *our* definition) ​> I was told that Duck was not normative and should not be used to identify the concept. I don’t see the logic in that — but was told that. So my comment (that started this ) was … This looked good until I was told that the term in the list was not to be used to identify the concept.​ Well,... the list of handles and definitions, by virtue of the fact of being included in the normative WCAG 2.1 Specification (as opposed to an external document), means that they are 'normative' with regard to a common handle. But that handle can (and will be) be 'normatively translated' to more than one language, and so the terms being used as handles themselves are not normative *for use as metadata values*: you need to use a publicly available metadata schema (and WCAG 2.1 is not that). So normative in terms of a reference value for metadata vocabularies (aids in cross-mapping), but not normative as value strings in any of the methods used to apply metadata at the element level. Example, we have (as David noted): Table of Contents - View or go to a table of contents ​...but an author cannot simply use the term​ "Table of Contents" in their markup (again, using Microdata annotation formatting): ​<a href="toc.html" itemscope itemtype="Table of Contents">Link text</a> [FAILS - no specific vocabulary defined] ​<a href="toc.html" itemscope itemtype=" https://www.w3.org/TR/WCAG21#commonpurposes?Table of Contents>Link text</a> [ALSO FAILS - because WCAG 2.1 is not a metadata vocabulary] <a href="toc.html" itemscope itemtype=" http://schema.org/MoveAction?ToLocation=TableOfContents">Link text</a> [PASSES - because it uses a public metadata schema] ​I personally don't see any additional value in also numbering the terms and definitions, but I would not oppose that going forward if there is consensus in doing so. Are we on the same page now? JF [Note to self: keep this email for Success & Failure Techniques down the road]

…

On Thu, Dec 21, 2017 at 3:30 PM, GreggVan ***@***.***> wrote: yes — that is what I thought was the case. Until I was told that the names in the list were NOT normative (please see my original comment). So that left nothing in the list that you could refer to. > *”In the Vanderheiden vocabulary, Canard = [WCAG 2.1's normative definition for > the handle known as Duck (+/- extremely minor editorial differences)]"* - The problem. I was told that Duck was not normative and should not be used to identify the concept. I don’t see the logic in that — but was told that. So my comment (that started this ) was … This looked good until I was told that the term in the list was not to be used to identify the concept. If that is wrong — then we go back to status-quo-ante and we are all set. If not — then all your discussions below don’t work because the require mapping and you can’t map if there is no stable referent. Gregg > On Dec 21, 2017, at 4:00 PM, John Foliot ***@***.***> wrote: > > Gregg, > > The *Definitions* listed at Chapter 7 > <http://rawgit.com/w3c/wcag21/master/guidelines/index.html# commonpurposes> > of the draft is what is normative (which is why that long list is not an > external document, but tagged on to the bottom of the latest draft). > > The terms (handles? names?) related to the definitions are themselves not > normative per-se, but very useful in allowing actual metadata vocabularies > to have both a short handle and longer description of the concepts that we > are mandating needing to be 'tagged' - and tagging concepts is the end-game > here, not terms; it's the common understanding behind the term that is > critical to this SC. From that list, *you can (if you so desire) map any > term you want* to any of those normative definitions, and as long as you > have done so (as the metadata vocabulary author) you are on the path to > success. > > In other words, if it walks like a duck, and quacks like a duck, you can > still tag it by the term "canard", as long as your public vocabulary > states *"In > the Vanderheiden vocabulary, Canard = [WCAG 2.1's normative definition for > the handle known as Duck (+/- extremely minor editorial differences)]"* - > it's the concept that counts, not the term, which can change by metadata > vocabulary. > > Then, assuming your private metadata vocabulary has an accessibility > supported lookup mechanism (namespaced? URI ref? other?), the machines will > be able to go to your definition and determine that when Gregg uses the > metadata term of "canard" he means WCAG 2.1's defined concept of "Duck". > > But using the term "canard" alone, > > <element itemscope itemtype="canard">Bird</element> <!-- Using Microdata > annotation --> > > > ...with no referenced metadata vocabulary does not achieve the goal, as > nobody would know what you meant by canard (it could easily also mean "...*a > false or baseless, usually derogatory story, report, or rumor.*" [source: > http://www.dictionary.com/browse/canard].) > > *Thus the term isn't that important,* *the definition is.* > > And as previously noted, *defining a specific metadata vocabulary is out of > scope for this WG* (which, as I re-read your notes, seems to be what you > are looking for - terms AND definitions), which is how we got to where we > are today: specifying concepts normatively that need to be mapped to terms > (which, abstractly, any term will work if it maps to the correct concept, > and linked via a public vocabulary that shows your proprietary term = WCAG > 2.1's definition for any given concept). > > JF > > On Thu, Dec 21, 2017 at 1:56 PM, GreggVan ***@***.***> wrote: > > > > > > > > On Dec 21, 2017, at 2:41 PM, John Foliot ***@***.***> > > wrote: > > > > > > Gregg, > > > > > > Let me back this up a bit: would you prefer we *mandate the use of a > > single > > > normative metadata schema here*, or is it preferable to say "Use a schema > > > that is publicly available and accessibility supported" and leave it to > > the > > > author to choose which schema best suits their needs? > > > > People can use whatever schema they want — AS LONG AS there is a way to > > tie that schema back to the items in your list in WCAG 2.1 > > > > right now you do not have a way — since you do not specify anything that > > can be used as and ID as normative. > > > > IF - you use the term you have here > > OR - if you give each one a number > > OR - you give each one ANY Normative handle > > > > it works. > > > > easiest - is to make the term normative and in techniques describe how to > > use any other schema to link back to it. > > OR - number each one and make the number fixed and normative (also works > > but a bit of a pain to use and more prone to error) > > > > > > > > > > > > > > What I had said was the referent — you are saying would be the URL. > > > > > > ​> ​ > > > that is fine. But you have not defined the URL for each of the concepts > > in > > > the SC. > > > > > > > > > ​Once again, this depends on what metadata schema you use​. Yes, I can > > map > > > all of the current 'handles' to a Schema.org definition (I've done so > > > already), *but not all metadata schemas have unique URLs for each > > > definition*. We have a normative list of common "handles" and clear > > > definitions, and how any schema references those definitions will be > > > dependant on the schemas vocabulary structure and the inline annotation > > > method used to apply the definition to the control. > > > > > > You can’t map anything back to the SC list if they list has no handles. > > > > > > > > > ​>​ > > > When you do — you will have satisfied what I have been asking for. It can > > > be > > > > > > ​> ​ > > > a name > > > > > > > > > ​​ > > > For > > > ​metadata > > > vocabularies that use namespacing and > > > ​inline values (​ > > > terms > > > ​)​ > > > , the "name" will be the related term specific to that > > > ​ specific​ > > > vocabulary > > > ​. > > > As AWK previously pointed out, one vocabulary may use the term "toc", > > while > > > another vocabulary may use "TableOfContents"​, and the Gregg-Vanderheiden > > > vocabulary uses " > > > anccoy > > > ​". That really shouldn't matter (and in practice, doesn't). > > > > > > As long as all three vocabularies bind their terms (names) to a common > > > definition > > > "View or go to a table of contents" [link type] > > > ​, which term you use will then be dependant on the namespace lookup > > > declaration (or method that you use to link the public vocabulary to the > > > page/element)​. > > > > > > ​ > > > > > > ​> > > > a number > > > > > > > > > ​??? This feels over-engineered. That said, we could provide, as part of > > > the Understanding documentation, a "mapping table" that uses numbers as > > > KeyID values, and then list our "common term/handle", the normative > > > definition, and then pointers to one or more metadata schemas that shows > > > how the annotation would work, and the value to point to​ - but that > > would > > > all be non-normative and illustrative, as we do not want to mandate the > > use > > > of a specific metadata vocabulary: > > > > > > [image: Inline image 2] > > > ​ > > > ​​ > > > > > > ​> ​ > > > a URL > > > > > > ​ > > > ​ > > > For > > > ​metadata > > > vocabularies that use direct URLs to definitions (such as, but not > > limited > > > to, Schema.org), the "name" will be the related term specified at the URL > > > . > > > ​Not all metadata schemas however are constructed in this fashion - many > > > do not resolve to unique URLS per definition. > > > > > > > > > > but it needs to be determinant and there is nothing determinant — there > > > is no stable handle — for each of the terms in the list. > > > > > > ​That's a feature Gregg, not a bug. We want to leave *which* metadata > > > vocabulary the author uses open to the author to choose, and/but > > different > > > vocabularies may have different 'terms' for the same conceptual idea. We > > > need to recognize that fact. > > > > > > So, as long as the vocabulary has public definitions, and those > > definitions > > > map to the *normatively defined​ "Common Purposes"* definitions we've > > > articulated > > > <http://rawgit.com/w3c/wcag21/master/guidelines/index.html# > > commonpurposes>, > > > then the method by which the schema supplies the metadata is dependant on > > > the annotation method used by that particular vocabulary - and not all > > > annotation methods use "terms" (and even when they do, how the"term" is > > > applied also varies - it could be an attribute, a class value string, or > > an > > > attribute value string). > > > > > > One overarching goal was to avoid being *too* prescriptive with regards > > to > > > Techniques ("Thou MUST use the Vanderheiden metadata values on the > > > following controls:...") - yet the only way to ensure *normative terms* > > is > > > > > to specify a unique metadata vocabulary (and thus that vocabulary's > > terms), > > > and specifying or defining a metadata schema is outside the scope of this > > > Working Group (i.e. we SHOULD reuse what is already out there). > > > > > > JF > > > > > > > > > > > > On Thu, Dec 21, 2017 at 11:50 AM, GreggVan ***@***.*** > > > wrote: > > > > > > > to make a long posting short > > > > > > > > What I had said was the referent — you are saying would be the URL. > > > > that is fine. But you have not defined the URL for each of the > > concepts in > > > > the SC. > > > > > > > > When you do — you will have satisfied what I have been asking for. It > > can > > > > be > > > > a name > > > > a number > > > > a URL > > > > > > > > but it needs to be determinant and there is nothing determinant — > > there is > > > > no stable handle — for each of the terms in the list. > > > > > > > > Does that help? > > > > > > > > Gregg > > > > > > > > > > > > > On Dec 21, 2017, at 12:46 PM, John Foliot < ***@***.***> > > > > wrote: > > > > > > > > > > Hi Gregg, > > > > > > > > > > You wrote: > > > > > > > > > > > *In order for metadata to work you need both the definition of the > > term > > > > > and the term. For example here are my terms for the definitions - in > > > > > alphabetical order. I publish them with definitions on my website > > under > > > > > “example.com/data/decoding/wcag21/metadata.db > > > > > <http://example.com/data/decoding/wcag21/metadata.db>* > > > > > > > > > > *then I use them on my page. Here are 4 words I use on my page - in > > > > > alphabetical order. ‘* > > > > > > > > > > *anccoy* > > > > > *Jmeoaz* > > > > > *ljerras* > > > > > *slijnjope * > > > > > > > > > > *How does a piece of AT know what they mean? * > > > > > > > > > > Namespacing > > > > > <https://msdn.microsoft.com/en-us/library/ms754619(v=vs.85).aspx >. > > > > > Different schemas may have different terms for the same (or > > equivalent) > > > > > concepts, and we do not want to restrict this SC to a single metadata > > > > > schema or annotation format. However, using Microdata annotation, the > > > > > namespacing happens when you supply the value (which is a URL string > > to > > > > the > > > > > definition). But that is but one method of doing the "lookup" or the > > > > > linking of controls to definitions. > > > > > > > > > > > > > > > > *otherwise you have a bunch of definitions that someone else can > > make > > > > up > > > > > words for that you do not know how to decode. * > > > > > > > > > > > > > > > Partially correct: you can make up your own terms, however 2 points > > to > > > > > remember: > > > > > > > > > > #1, for the metadata to be useful, there needs to be the > > > > > namespacing/lookup mechanism. In Microdata annotation, the url that > > *is* > > > > > the definitionis the value string. Other metadata schemas use global > > > > > namespacing and declarations in the document <head>, such as Dublin > > Core > > > > > (not recommended, as that is document level metadata, and not element > > > > level > > > > > microdata) or TEI (which also allows for customization > > > > > <http://www.tei-c.org/Guidelines/Customization/index.xml> through > > > > classes > > > > > and attributes). The emergent Personalization Semantics > > > > > <https://www.w3.org/TR/personalization-semantics-1.0/> uses inline > > > > > attributes (without "namespacing", but via reserved attribute > > strings and > > > > > values just like ARIA)... so the method is less important than the > > > > result. > > > > > > > > > > #2, you would have to warrant and prove that your definitions at > > > > > example.com/data/decoding/wcag21/metadata.db could in fact be > > > > accessibility > > > > > supported: that web-browsers and an AT tool can do the appropriate > > > > > namespace lookup required to close this loop. > > > > > > > > > > > > > > > > > > > > > *problem 2 is that you need to* > > > > > > > > > > *a) have a normative way of finding this list of new terms —* > > > > > > > > > > ​This depends on the metadata schema and usage rules. However, > > whether > > > > > inline or as part of a global header declaration, metadata schemas > > all > > > > > provide normative terms and definitions, and a mechanism for > > "looking up" > > > > > the definition. > > > > > This SC essentially states that for whatever metadata schema you > > choose, > > > > it > > > > > must have a > > > > > ​schema-level ​ > > > > > term *that matches our list of definitions*. Thus, when the AT does > > the > > > > > namespaced lookup for the term declared > > > > > ​ (your "Jmeoaz")​ > > > > > , it arrives at the "common definition" we require > > > > > ​ ​ > > > > > (Contact us - View the contact information for content owner or > > producer > > > > > <http://rawgit.com/w3c/wcag21/master/guidelines/index.html# > > > > commonpurposes>)​ > > > > > . > > > > > ​ ​ > > > > > > > > > > > > > > > *b) define normatively the data format for this decoding database.* > > > > > > > > > > ​I disagree. The data format is not critical here (important, yes, > > > > > critical, no), rather it's the middleware that will be doing > > something > > > > > useful with the metadata values - *and that middleware will need to > > be > > > > > accessibly supported​* to be able to successfully meet this SC. > > > > > That said, perhaps we *should* further state that custom metadata > > schemas > > > > > must be declared using RDF or RDFa (???) - but that too feels like a > > bit > > > > of > > > > > an over-reach. > > > > > > > > > > > > > > > * and* > > > > > > > > > > * c) require that the reference to the list be on every page - since > > we > > > > > evaluate by page - or it has to be in a normative place on every > > website > > > > > (not practical)* > > > > > > > > > > ​...and again, I disagree. It depends on the (accessibility > > supported) > > > > > metadata schema the author chooses. Some schemas have a global > > namespace > > > > > declaration in the document <head> (and so, via HTML page templating, > > > > this > > > > > could indeed may be VERY easy & practical to accomplish): > > > > > > > > > > <head> > > > > > <link rel="schema.VANDERHEIDEN" > > > > > href="http://example.com/data/decoding/wcag21/metadata/" > > > > > /> > > > > > </head> > > > > > + > > > > > <body> > > > > > <a href="contactpage.html" class="Jmeoaz"> > > > > > ​ > > > > > お問い合わせ</a> > > > > > <!-- presumes your metadata schema uses class values to apply inline > > > > > term definitions, and is accessibility supported --> > > > > > > > > > > </body> > > > > > > > > > > > > > > > > > > > > Others can use Microdata annotation (where again the definition *IS* > > the > > > > > URL string to the normative text(s)): > > > > > > > > > > <element itemscope itemtype="http://example.com/data/decoding/ > > > > > wcag21/metadata/%Value">*Non-normative term*</element> > > > > > > > > > > > > > > > > > > > > Or, as in Personalization Semantics (or TEI), it can be dependant on > > a > > > > > reserved list of attributes or class values: > > > > > > > > > > <button coga-action="undo"> > > > > > ​ > > > > > *Non-normative term*</button> > > > > > > > > > > > > > > > > > > > > ​> > > > > > *See the problem?* > > > > > > > > > > > > > > > ​ > > > > > ​Actually, no, I don't​. > > > > > (If anything, with respect Gregg, > > > > > ​ > > > > > the problem > > > > > ​ as I see it​ > > > > > is that you aren't understanding > > > > > ​how to apply element level metadata > > > > > fully, which, if nothing else, underscores a bigger concern - will > > others > > > > > understand the ask here > > > > > ​ as well?​ Or will they be confused > > > > > ?) > > > > > > > > > > > > > > > > > > > > > ​ > > > > > *All metadata has the same internationalization concern. None of > > them say > > > > > — "so you can use any terms you want as long as you document it” * > > > > > > > > > > ​Respectfully, I must disagree. ​Most (many) metadata schemes appear > > to > > > > > allow for further extension or customization: > > > > > > > > > > Schema.org <http://schema.org/docs/extension.html>: "*There are two > > > > kinds > > > > > of extensions: reviewed/hosted extensions and external extensions. > > Both > > > > > kinds of extensions typically add subclasses and properties to the > > core. > > > > > Properties may be added to existing and/or new classes.*" > > > > > > > > > > TEI > > > > > <http://www.tei-c.org/Guidelines/Customization/odds. > > > > xml#body.1_div.2_div.3>: > > > > > "*A schema can include declarations for new elements,* *..."* > > > > > > > > > > Microformats <http://microformats.org/wiki/process>: "*So you wanna > > > > develop > > > > > a new microformat? Or just a new vocabulary? Or create a new standard > > > > based > > > > > on empirical research and scientific methods? This document will help > > > > guide > > > > > you through the steps to take towards achieving these goals.*" > > > > > (again, I would not recommend Microformats, as it appears *too* > > > > malleable, > > > > > given that the definition list(s) is a publicly editable wiki) > > > > > > > > > > > > > > > > > > > > > *AH but Contact Page is the term. you can’t use schema.org > > > > > <http://schema.org/> without using the name of the entity first — > > and > > > > then > > > > > attaching any other label that you want. * > > > > > > *yes but you MUST USE THE TERM. you can’t say "** > > http://schema.org/* > > > > お問い合わせ > > > > > <http://schema.org/%E3%81%8A%E5%95%8F%E3%81%84%E5%90%88%E3% > > > > 82%8F%E3%81%9B> you > > > > > must first use the defined name. > > > > > > > > > > ​Again, respectfully, this is incorrect. The term we are applying > > > > metadata > > > > > to itself is abstract, it is the *definition* that is normative. In > > my > > > > > example using Microdata, the term that is being defined is *the value > > > > > between the element's opening and closing tag*​: > > > > > > > > > > > > > > > <a href="http://example.com/contactus.html" > > > > > ​ > > > > > ​ > > > > > itemscope > > > > > ​ > > > > > ​ <!-- required to scope the definition to just this element > > > > > ​ ​ > > > > > ​& element value -->​ > > > > > > > > > > ​ itemtype="http://schema.org/ContactPage"> <!-- URL to normative > > > > > definition --> > > > > > お問い合わせ <!-- Term that is being defined in this instance, *scoped > > > > > as such* with the *itemscope* attribute --> > > > > > </a> > > > > > > > > > > ​The fact that ​ > > > > > ​​ > > > > > お問い合わせ > > > > > ​ is the Japanese translation of "Contact Page" doesn't really > > matter, > > > > > because both terms will point to (reference) the normative > > definition at > > > > ​ > > > > > http://schema.org/ContactPage > > > > > ​ when encoded using Microdata annotation (as above). > > > > > > > > > > As long as > > > > > http://schema.org/ContactPage > > > > > ​ resolves to a definition that is equal (or equated) to "View the > > > > contact > > > > > information for content owner or producer"​, you will have succeeded. > > > > > > > > > > Ditto for your custom schema: if (using Microdata annotation) > > > > > itemtype="http://example.com/data/decoding/wcag21/metadata/ > > > > > ​VanderheidenContactDetails.xml​ [sic] > > > > > also maps back to "View the contact information for content owner or > > > > > producer" > > > > > ​ you're good-to-go.​ > > > > > > > > > > > > > > > So, to wrap up, yes, we will need a ​"lookup list" that declares the > > > > > normative definitions we require, and with those definitions a list > > of > > > > > "common" terms that serve as a handle for each definition. That > > current > > > > > list is found as "chapter" 7 in the draft WCAG 2.1 spec: > > > > > http://rawgit.com/w3c/wcag21/master/guidelines/index.html# > > commonpurposes > > > > > > > > > > But critically, the author does not need to use the specific > > > > terms/handles > > > > > used in that list, what they need to reference is the actual > > normative > > > > > definition. *How they apply that definition* to any given element > > will > > > > > depend on which schema the author uses, and how the schema they have > > > > chosen > > > > > at the document level mandates applying definitions to conceptual > > > > elements: > > > > > > > > > > - some may use reserved handles/short-terms (referenced as > > attributes or > > > > > class values + page-level namespacing), > > > > > - others may simply point to the URL that constitutes the normative > > > > > definition (Microdata format) with no actual (reserved) "term" being > > > > used, > > > > > - while others may use reserved inline attributes > > > > > > > > > ​ & values​ > > > > > (Personalization Semantics). > > > > > > > > > > > > > > > 3 different techniques, but all will (MUST!) ultimately reference the > > > > same > > > > > normative definition. > > > > > > > > > > > > > > > JF > > > > > > > > > > On Wed, Dec 20, 2017 at 10:08 PM, GreggVan < ***@***.*** > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Dec 16, 2017, at 1:30 PM, John Foliot < > > ***@***.***> > > > > > > wrote: > > > > > > > > > > > > > > Hi Gregg, > > > > > > > > > > > > > > There seems to be a fair bit of confusion about this, and yet it > > > > should > > > > > > be > > > > > > > quite simple. > > > > > > > > > > > > > > The key to this SC, and the bigger 'ask' is to apply *metadata > > > > directly > > > > > > to > > > > > > > those elements* that serve the "common purposes" articulated in > > the > > > > list. > > > > > > > > > > > > Yep > > > > > > > > > > > > > But given internationalization concerns (etc.), the list is > > > > malleable to > > > > > > > the extent that it defines concepts, rather than specific terms > > > > (but, it > > > > > > > needs terms to start the definition process). > > > > > > > > > > > > All metadata has the same internationalization concern. None of > > them > > > > say — > > > > > > "so you can use any terms you want as long as you document it” > > > > > > > > > > > > you need to list the referent name or label or handle as well as > > the > > > > > > definition. > > > > > > > > > > > > > > > > > > > > The "simplest" explanation can also be articulated in code - a > > link > > > > to > > > > > > > the *Contact > > > > > > > Us Page*. But to fully illustrate, I'll actually use the Japanese > > > > > > > equivelant of お問い合わせ. Additionally, I will illustrate this using > > > > > > Microdata > > > > > > > annotation, and the Schema.org taxonomy (ontology): > > > > > > > > > > > > > > <a href="http://example.com/contactus.html" > > > > > > > itemscope > > > > > > > itemtype="http://schema.org/ContactPage">お問い合わせ</a> > > > > > > > > > > > > > AH but Contact Page is the term. you can’t use schema.org without > > > > using > > > > > > the name of the entity first — and then attaching any other label > > that > > > > you > > > > > > want. > > > > > > > > > > > > > > > > > > > > So, the terms themselves are mostly "placeholders" for the more > > > > important > > > > > > > definitions of concepts - the metadata *values*. With a publicly > > > > > > available > > > > > > > Metadata schema, Assistive Technology *CAN* do the look-up, > > either > > > > via > > > > > > the > > > > > > > "old-school" name-spacing (in the mode of Dublin Core), or, with > > > > > > Microdata, > > > > > > > following the URL to the explicitly defined concept. At the end > > of > > > > the > > > > > > day, > > > > > > > the disambiguation happens at the defined (external) vocabulary, > > and > > > > as > > > > > > > long as it is publicly available, AT has the hooks it needs - the > > > > > > > disambiguated definitions. > > > > > > > > > > > > yes but you MUST USE THE TERM. you can’t say " > > http://schema.org/お問い合わせ > > > > > > > > > > > > you must first use the defined name. > > > > > > > > > > > > > > > > > > > > "But what AT today?" you ask. > > > > > > > > > > > > > > Welcome to the chicken and egg problem (which I'm sure you are > > all > > > > too > > > > > > > familiar with). As a proof-of-concept tool moving forward (and > > > > needed for > > > > > > > the exit criteria), I hope (plan) on seeing a browser extension > > that > > > > will > > > > > > > do a little bit of user style sheet injection when the Microdata > > > > > > annotation > > > > > > > is used (not a complete solution, but illustrative) that will, in > > > > essence > > > > > > > take advantage of the fact that each term definition is > > specifically > > > > > > > referenced at the element level, using a very specific block (or > > > > string) > > > > > > of > > > > > > > text. In my example above, that string is > > > > > > > > > > > > > > "...itemtype="http://schema.org/ContactPage"..." > > > > > > > > > > > > > > ​...​ > > > > > > > and so I can use that string as a CSS selector, and then do stuff > > > > like > > > > > > > adding a button with icon and text overlay anytime there is a > > link or > > > > > > > button (trigger) to the Contact Us Page > > > > > > > ​.​ > > > > > > > > > > > > if you want to say they must use Schema.org then that is fine. > > > > > > > > > > > > but I can’t make AT today that will work next year if you use > > > > > > http://FoliotScheme.org/お問い合わせ <http://foliotscheme.org/%E3%81%8A%E5%95%8F%E3%81%84%E5%90%88%E3%82%8F%E3%81%9B> > > <http://foliotscheme.org/%E3%81%8A%E5%95%8F%E3%81%84%E5%90% 88%E3%82%8F%E3%81%9B> > > > > <http://foliotscheme.org/%E3%81%8A%E5%95%8F%E3%81%84%E5%90% > > 88%E3%82%8F%E3%81%9B> > > > > > > <http://foliotscheme.org/%E3%81%8A%E5%95%8F%E3%81%84%E5%90% > > > > > > 88%E3%82%8F%E3%81%9B> > > > > > > > > > > > > > > > > how will I know what that means? I can haul down your definition in > > > > > > (japanese but it won’t help my AT programmatically determine the > > > > function. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Now, if a large organization wants​ to publish its own taxonomy > > list, > > > > > > they > > > > > > > will need to ensure that the *concepts defined by this SC* will > > be > > > > mapped > > > > > > > to their choice of term and that lookup list is public, but it > > is the > > > > > > > definitions that are effectively normative, not the terms: > > > > > > > > > > > > Great — but how do I map them back to the terms if there are no > > known > > > > > > stable handles for each term in the SC? > > > > > > > > > > > > > > > > > > > > > > > > > > *​Non-normative Term: * *Normative definition* (taken > > > > > > > from Merriam-Webster <https://www.merriam-webster. > > com/dictionary/dog > > > > > > > > > > > for > > > > > > > illustration purposes only): > > > > > > > dog canid: wolves, > > > > > > > foxes, and other dogs; especially : a highly variable domestic > > mammal > > > > > > > (Canis > > > > > > > familiaris) closely related to the gray wolf > > > > > > > > > > > > > > chien​ canid: wolves, > > > > > > > foxes, and other dogs; especially : a highly variable domestic > > mammal > > > > > > > (Canis > > > > > > > familiaris) closely related to the gray wolf > > > > > > > > > > > > > > ​ puppy canid: wolves, > > > > > > > foxes, and other dogs; especially : a highly variable domestic > > mammal > > > > > > > (Canis > > > > > > > familiaris) closely related to the gray wolf > > > > > > > > > > > > > > ​ fur-baby canid: wolves, > > > > > > > foxes, and other dogs; especially : a highly variable domestic > > mammal > > > > > > > (Canis > > > > > > > familiaris) closely related to the gray wolf > > > > > > > > > > > > > > Make sense? > > > > > > > > > > > > Not unless you assume that everyone knows english. > > > > > > > > > > > > if you used english terms for the 20 or so items — I could know > > what > > > > the > > > > > > translation to my country’s language was’’’ > > > > > > > > > > > > or even if you numbered them. > > > > > > > > > > > > But you need some stable referent > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > JF > > > > > > > > > > > > > > On Sat, Dec 16, 2017 at 10:51 AM, GreggVan < > > ***@***.*** > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > Success Criterion 1.3.4 Identify Common Purpose§ > > > > > > > > (Level AA) [New] > > > > > > > > In content implemented using markup languages, for each user > > > > interface > > > > > > > > component that serves a purpose identified in the Common > > Purposes > > > > for > > > > > > User > > > > > > > > Interface Components section, that purpose can be > > programmatically > > > > > > > > determined. > > > > > > > > > > > > > > > > I thought you had this one solved — until I heard that you now > > > > don’t > > > > > > mean > > > > > > > > that they terms in the list are the terms that need to be used > > — > > > > but > > > > > > rather > > > > > > > > that any set of terms can be used for those functions as long > > as > > > > they > > > > > > are > > > > > > > > documented somewhere. This is no way for this to meet > > > > “accessibility > > > > > > > > supported” if AT have no idea in advance what words to look > > for. > > > > If I > > > > > > > > create AT this year — and each month after release — for all > > years > > > > - a > > > > > > new > > > > > > > > site can use a new set of words — there is no way I can design > > my > > > > AT > > > > > > now to > > > > > > > > work with sites that use different sets of words that I don’t > > know > > > > what > > > > > > > > they will be. In order for this to work — you must tell me the > > > > > > functions > > > > > > > > AND the terms that will be used (or tell me that each > > technology > > > > will > > > > > > use a > > > > > > > > standard set of terms for that technology. (e.g. HTML will > > define > > > > the > > > > > > terms > > > > > > > > for HTML, PDF for PDF, etc.) Unless someone can tell me another > > > > way an > > > > > > AT > > > > > > > > vendor can know what the terms for those functions are in a > > > > > > > > programmatically determinable way. > > > > > > > > > > > > > > > > — > > > > > > > > You are receiving this because you are subscribed to this > > thread. > > > > > > > > Reply to this email directly, view it on GitHub > > > > > > > > <#635>, or mute the thread > > > > > > > > <https://github.com/notifications/unsubscribe-auth/ABK- > > > > > > czKwicKADnieNtV9NMU1ScNXkjl9ks5tA_UjgaJpZM4REY2y> > > > > > > > > . > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > John Foliot > > > > > > > Principal Accessibility Strategist > > > > > > > Deque Systems Inc. > > > > > > > ***@***.*** > > > > > > > > > > > > > > Advancing the mission of digital accessibility and inclusion > > > > > > > — > > > > > > > You are receiving this because you authored the thread. > > > > > > > Reply to this email directly, view it on GitHub < > > > > https://github.com/w3c/ > > > > > > wcag21/issues/635#issuecomment-352201706>, or mute the thread < > > > > > > https://github.com/notifications/unsubscribe-auth/ > > > > > > AJph3j7urR46441VX4MHx9BdT9cVaUP1ks5tBAxMgaJpZM4REY2y>. > > > > > > > > > > > > > > > > > > > — > > > > > > You are receiving this because you commented. > > > > > > Reply to this email directly, view it on GitHub > > > > > > <#635# issuecomment-353253435>, > > or > > > > mute > > > > > > the thread > > > > > > <https://github.com/notifications/unsubscribe-auth/ABK- > > > > c0vcBdxkZWCxutxfFkp3dmuYo02gks5tCdnTgaJpZM4REY2y> > > > > > > . > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > John Foliot > > > > > Principal Accessibility Strategist > > > > > Deque Systems Inc. > > > > > ***@***.*** > > > > > > > > > > Advancing the mission of digital accessibility and inclusion > > > > > — > > > > > You are receiving this because you authored the thread. > > > > > Reply to this email directly, view it on GitHub < > > https://github.com/w3c/ > > > > wcag21/issues/635#issuecomment-353413400>, or mute the thread < > > > > https://github.com/notifications/unsubscribe-auth/ > > > > AJph3uqy6SpnoqrRXK6rK8TS7rp6qU-pks5tCplhgaJpZM4REY2y>. > > > > > > > > > > > > > — > > > > You are receiving this because you commented. > > > > Reply to this email directly, view it on GitHub > > > > <#635 (comment)>, or > > mute > > > > the thread > > > > <https://github.com/notifications/unsubscribe- > > auth/ABK-c2wGj7jzYy_cgVYc-AigHpPcMS_0ks5tCppKgaJpZM4REY2y> > > > > . > > > > > > > > > > > > > > > > -- > > > John Foliot > > > Principal Accessibility Strategist > > > Deque Systems Inc. > > > ***@***.*** > > > > > > Advancing the mission of digital accessibility and inclusion > > > — > > > You are receiving this because you authored the thread. > > > Reply to this email directly, view it on GitHub < https://github.com/w3c/ > > wcag21/issues/635#issuecomment-353439809>, or mute the thread < > > https://github.com/notifications/unsubscribe-auth/ > > AJph3hjwcTA9A9S2O72se7g6lJzNTt3Jks5tCrROgaJpZM4REY2y>. > > > > > > > — > > You are receiving this because you commented. > > Reply to this email directly, view it on GitHub > > <#635 (comment)>, or mute > > the thread > > <https://github.com/notifications/unsubscribe-auth/ABK- c1fwwWTFBGVehTZaZmuG6MOX2Ajnks5tCrfngaJpZM4REY2y> > > . > > > > > > -- > John Foliot > Principal Accessibility Strategist > Deque Systems Inc. > ***@***.*** > > Advancing the mission of digital accessibility and inclusion > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub <https://github.com/w3c/ wcag21/issues/635#issuecomment-353456525>, or mute the thread < https://github.com/notifications/unsubscribe-auth/ AJph3rblHsGBuigIWlLn5wBf3nKVp6Rqks5tCsbrgaJpZM4REY2y>. > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#635 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABK-c7cI8S2MReGq1oL7Rdx5iqsCMoSqks5tCs4LgaJpZM4REY2y> .

-- John Foliot Principal Accessibility Strategist Deque Systems Inc. [email protected] Advancing the mission of digital accessibility and inclusion

[DavidMacDonald]

Developing the numbering idea a bit further:

Perhaps they can be a alphanumeric for the 2 lists:

A1. Table of Contents - View or go to a table of contents
A2. Next - View or go to the next item in a series (e.g. a page in a book or next article)
A3. Previous - View or go to the previous item in a series
...

B1. Name - Inputs used to handle information about a user’s name(s) (...
B2. Professional Title - Job title (e.g., "Software Engineer", ...
B3. Organization - Company name corresponding to the user

[GreggVan]

yes I think you can — and that would solve the problem. But the numbers would need to be normative and not change once the std is released I would suggest you add some characters to the front of the numbers so they know they are not just an ordered list. Perhaps CP CP01 CP02 CP03 etc gregg

…

On Dec 21, 2017, at 4:27 PM, David MacDonald ***@***.***> wrote: Could we solve this issue by simply numbering each of the items in our list? It's not a new schema... it's a list of items for WCAG in our conformance which can now be referred to numerically. Table of Contents - View or go to a table of contents Next - View or go to the next item in a series (e.g. a page in a book or next article) Previous - View or go to the previous item in a series Reply - Reply to current item (e.g. an email) 5 Forward - Forward the current item (e.g. an email) Inbox - View the inbox (e.g. an email application inbox) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#635 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJph3hFDCweL2rTLHfPq9F6mENB6-ZDEks5tCs0rgaJpZM4REY2y>.

[GreggVan]

easier though would be to just have the name in english be the anchor OR just say that the number should always be accompanied by the name in whatever language you like. That way it is determinant (the number) and human readable (the word) in the natural language of the page. like this CP05-TermName (in english on an english page) or CP05-Ονόματαόρων or CP05-مدت جو نالو Gregg

…

On Dec 21, 2017, at 6:10 PM, Gregg Vanderheiden GPII ***@***.***> wrote: yes I think you can — and that would solve the problem. But the numbers would need to be normative and not change once the std is released I would suggest you add some characters to the front of the numbers so they know they are not just an ordered list. Perhaps CP CP01 CP02 CP03 etc gregg > On Dec 21, 2017, at 4:27 PM, David MacDonald ***@***.*** ***@***.***>> wrote: > > Could we solve this issue by simply numbering each of the items in our list? It's not a new schema... it's a list of items for WCAG in our conformance which can now be referred to numerically. > > Table of Contents - View or go to a table of contents > Next - View or go to the next item in a series (e.g. a page in a book or next article) > Previous - View or go to the previous item in a series > Reply - Reply to current item (e.g. an email) > 5 Forward - Forward the current item (e.g. an email) > Inbox - View the inbox (e.g. an email application inbox) > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub <#635 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJph3hFDCweL2rTLHfPq9F6mENB6-ZDEks5tCs0rgaJpZM4REY2y>. >

[GreggVan]

ah looks a lot like your idea David g

…

On Dec 21, 2017, at 6:14 PM, Gregg Vanderheiden GPII ***@***.***> wrote: easier though would be to just have the name in english be the anchor OR just say that the number should always be accompanied by the name in whatever language you like. That way it is determinant (the number) and human readable (the word) in the natural language of the page. like this CP05-TermName (in english on an english page) or CP05-Ονόματαόρων or CP05-مدت جو نالو Gregg > On Dec 21, 2017, at 6:10 PM, Gregg Vanderheiden GPII ***@***.*** ***@***.***>> wrote: > > yes I think you can — and that would solve the problem. But the numbers would need to be normative and not change once the std is released > > I would suggest you add some characters to the front of the numbers so they know they are not just an ordered list. > > Perhaps CP > > CP01 > CP02 > CP03 > etc > > gregg > > > >> On Dec 21, 2017, at 4:27 PM, David MacDonald ***@***.*** ***@***.***>> wrote: >> >> Could we solve this issue by simply numbering each of the items in our list? It's not a new schema... it's a list of items for WCAG in our conformance which can now be referred to numerically. >> >> Table of Contents - View or go to a table of contents >> Next - View or go to the next item in a series (e.g. a page in a book or next article) >> Previous - View or go to the previous item in a series >> Reply - Reply to current item (e.g. an email) >> 5 Forward - Forward the current item (e.g. an email) >> Inbox - View the inbox (e.g. an email application inbox) >> — >> You are receiving this because you authored the thread. >> Reply to this email directly, view it on GitHub <#635 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJph3hFDCweL2rTLHfPq9F6mENB6-ZDEks5tCs0rgaJpZM4REY2y>. >> >

[Ryladog]

I like where this discussion is going….. From: GreggVan [mailto:[email protected]] Sent: Thursday, December 21, 2017 6:17 PM To: w3c/wcag21 <[email protected]> Cc: Subscribed <[email protected]> Subject: Re: [w3c/wcag21] Success Criterion 1.3.4 Identify Common Purpose [Trace] (#635) ah looks a lot like your idea David g

On Dec 21, 2017, at 6:14 PM, Gregg Vanderheiden GPII ***@***.*** ***@***.***> > wrote: easier though would be to just have the name in english be the anchor OR just say that the number should always be accompanied by the name in whatever language you like. That way it is determinant (the number) and human readable (the word) in the natural language of the page. like this CP05-TermName (in english on an english page) or CP05-Ονόματαόρων or CP05-مدت جو نالو Gregg > On Dec 21, 2017, at 6:10 PM, Gregg Vanderheiden GPII ***@***.*** ***@***.******@***.***> ***@***.***>> wrote: > > yes I think you can — and that would solve the problem. But the numbers would need to be normative and not change once the std is released > > I would suggest you add some characters to the front of the numbers so they know they are not just an ordered list. > > Perhaps CP > > CP01 > CP02 > CP03 > etc > > gregg > > > >> On Dec 21, 2017, at 4:27 PM, David MacDonald ***@***.*** ***@***.******@***.***> ***@***.***>> wrote: >> >> Could we solve this issue by simply numbering each of the items in our list? It's not a new schema... it's a list of items for WCAG in our conformance which can now be referred to numerically. >> >> Table of Contents - View or go to a table of contents >> Next - View or go to the next item in a series (e.g. a page in a book or next article) >> Previous - View or go to the previous item in a series >> Reply - Reply to current item (e.g. an email) >> 5 Forward - Forward the current item (e.g. an email) >> Inbox - View the inbox (e.g. an email application inbox) >> — >> You are receiving this because you authored the thread. >> Reply to this email directly, view it on GitHub <#635 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJph3hFDCweL2rTLHfPq9F6mENB6-ZDEks5tCs0rgaJpZM4REY2y>. >> >

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#635 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AFfqysiRGSCrFkBBQvMBYn4qNN-bzE6_ks5tCubrgaJpZM4REY2y> . <https://github.com/notifications/beacon/AFfqykathpMYZOMtCikgDg6MTv_T6CkLks5tCubrgaJpZM4REY2y.gif>

[awkawk]

Until I was told that the names in the list were NOT normative

There is some confusion here, probably caused by me.

The items on the list are normative as purposes, but not as metadata values. So we could have:

CP01. Table of Contents - View of go to a table of contents.

and an author would do something like:

<a href="http://example.com/toc.html" itemscope itemtype="http://schema.org/toc">Table of Contents</a>

Does that work, assuming that there are tools available that demonstrate accessibility support?

[johnfoliot]

If the WG supports prefixed numbers (CP 01) then I see no downside there, as it seems mostly editorial in nature (but I do see the disambiguation value). I'd be less enthusiastic of a prefix scheme in the format David proposed, as we'd also need to explain why we used A versus B versus C; it seems overly granular and I don't think it brings enough value to do that. JF

…

On Dec 21, 2017 5:23 PM, "Andrew Kirkpatrick" ***@***.***> wrote: Until I was told that the names in the list were NOT normative There is some confusion here, probably caused by me. The items on the list are normative as purposes, but not as metadata values. So we could have: CP01. Table of Contents - View of go to a table of contents. and an author would do something like: Table of Contents <http://example.com/toc.html> Does that work, assuming that there are tools available that demonstrate accessibility support? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#635 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABK-c1IgY7YW0CS5uua7Z6BEpiukgUWwks5tCuhtgaJpZM4REY2y> .

[GreggVan]

No the problem is that metadata needs to be normative. Or at least the Anchor in WCAG needs to be normative so that other metadata can be mapped to it. So you want to say that the anchor is normative but that authors can map other metadata to it and then use that metadata. But they need to say where the mapping is located so the AT can do the transformation. Gregg

…

On Dec 21, 2017, at 6:23 PM, Andrew Kirkpatrick ***@***.***> wrote: Until I was told that the names in the list were NOT normative There is some confusion here, probably caused by me. The items on the list are normative as purposes, but not as metadata values. So we could have: CP01. Table of Contents - View of go to a table of contents. and an author would do something like: Table of Contents <http://example.com/toc.html> Does that work, assuming that there are tools available that demonstrate accessibility support? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#635 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJph3rGL1AIcrycz2fXf3RuRDxOQOx0qks5tCuhwgaJpZM4REY2y>.

[GreggVan]

Great I would concatenate the CP01 as one string. That way it becomes a unique identifier. best gregg

…

On Dec 21, 2017, at 6:52 PM, John Foliot ***@***.***> wrote: If the WG supports prefixed numbers (CP 01) then I see no downside there, as it seems mostly editorial in nature (but I do see the disambiguation value). I'd be less enthusiastic of a prefix scheme in the format David proposed, as we'd also need to explain why we used A versus B versus C; it seems overly granular and I don't think it brings enough value to do that. JF On Dec 21, 2017 5:23 PM, "Andrew Kirkpatrick" ***@***.***> wrote: > Until I was told that the names in the list were NOT normative > > There is some confusion here, probably caused by me. > > The items on the list are normative as purposes, but not as metadata > values. So we could have: > > CP01. Table of Contents - View of go to a table of contents. > > and an author would do something like: > > Table of Contents <http://example.com/toc.html> > > Does that work, assuming that there are tools available that demonstrate > accessibility support? > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <#635 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/ABK-c1IgY7YW0CS5uua7Z6BEpiukgUWwks5tCuhtgaJpZM4REY2y> > . > — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#635 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJph3qXNlpsIcb49LcdV5jG-329EZIhaks5tCu8lgaJpZM4REY2y>.

[awkawk]

No the problem is that metadata needs to be normative. Or at least the Anchor in WCAG needs to be normative so that other metadata can be mapped to it.

Gregg, can you clarify what you mean for the latter half of this?

For comparison, in 4.1.2 we just say that the role needs to be conveyed. What if we had instead said that authors need to convey the following roles - list, slider, checkbox, text input (obviously not a comprehensive list). We wouldn't want to specify the specific string used to identify the role because that string varies by technology, we would want to say "Slider - a control type that...." and that name/descriptor is the normative reference".

Is it as simple as making each item take a form like:
<li id="cp01">CP01: Table of Contents - View or go to a table of contents</li>

Or something different?

[GreggVan]

In that case — you are exposing the role using the method used by the technologies — and supported by AT. In this case you are not using anything standard to the technologies. (e.g. html, or PDF etc) (if you were by the way - they would be english terms) Instead you/we are talking about creating our own standard out of whole cloth. And we define these purposes — but then we give them no name or handle by which to refer to them. (actually it LOOKS like we do - because we actually have a name for each one — followed by a definition. So we were all set — UNTIL we said — oh by the way — you can’t rely on that name being their name. A person can use any name they want to — and don’t have to map it back to that name — just the definition. And it doesn’t need to actually be that exact definition — just one that is close (so I can’t even do a definition string match). So how is a piece of AT (code) going to programmatically figure out what an arbitrarily named control’s purpose is if there is no determinate way to map this new name in a new schema back to the particular definitions in WCAG? Again — the solution is really simple. You just have the names we already have be normative. People can use any other names they want ( and definitions if they are close) as long as they map them back to the names in WCAG 2.1. And if you don’t want the official names to be in any language then you can name them with non-linguistic strings (e.g. CP01, CP02 etc) Make sense now? Gregg

…

On Dec 22, 2017, at 8:41 AM, Andrew Kirkpatrick ***@***.***> wrote: No the problem is that metadata needs to be normative. Or at least the Anchor in WCAG needs to be normative so that other metadata can be mapped to it. Gregg, can you clarify what you mean for the latter half of this? For comparison, in 4.1.2 we just say that the role needs to be conveyed. What if we had instead said that authors need to convey the following roles - list, slider, checkbox, text input (obviously not a comprehensive list). We wouldn't want to specify the specific string used to identify the role because that string varies by technology, we would want to say "Slider - a control type that...." and that name/descriptor is the normative reference". Is it as simple as making each item take a form like: CP01: Table of Contents - View or go to a table of contents Or something different? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#635 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJph3mG_pIBHHfbKxMyFGGx3aYkLdoWoks5tC7GlgaJpZM4REY2y>.

[awkawk]

(Official WG response)
Thanks for the comment. The new SC text has resolved this issue.