Re: support personlization - John concerns with programmatically determined loophole

Hi John

I think we are addressing these concerns in the definitions. For example "common form elements," - you ask what is included and we have addressed that concern by making a very specific list of included elements in the definition of  common form elements so it is extreamy clear what is included. 


We are solving your issue with title in a similar way if the requirement is that the context is programmaticaly available and we define that such as the UAGG definition that includes - "Something is programmatically available if the entity presenting the information does so in a way that is explicit and unambiguous, in a way that can be understood without reverse-engineering or complex (and thus potentially fallible) heuristics..."


We can further clarify this in the Understanding section. 


If you still feel that thus  is not clear then we can use a different term such as  "programmaticaly  clarified" that we can write our own new definition that included the above but also would include as much clarifying information as you want such as  "the information is machine such that user agent can map it uniquely  to a set of preferences, or user agent support  without requiring interpretation or NLP solutions"


would you prefer that?


All the best

Lisa Seeman

LinkedIn, Twitter





---- On Wed, 12 Jul 2017 22:53:25 +0300 John Foliot<john.foliot@deque.com> wrote ---- 

Hi Lisa,


As I noted to you in our private exchange, I DO NOT have a problem with "programmatically determined" (nor do I have an issue with "programmatically available") - my issue is that under either wording or condition, it still makes using @title to furnish the contextual information you seek a valid option (which, as I have explained, is the declared reason for @title in HTML in the first place). Quoting directly from the HTML5 Specification:


The title attribute represents advisory information for the element, such as would be appropriate for a tooltip. On a link, this could be the title or a description of the target resource; on an image, it could be the image credit or a description of the image; on a paragraph, it could be a footnote or commentary on the text; on a citation, it could be further information about the source; on interactive content, it could be a label for, or instructions for, use of the element; and so forth. The value is text.






For the benefit of the list, this is what else I wrote to you privately:


For example, based on the current wording, I would argue​-for​
 (and pass) the following code example:


<nav​​
 title="main navigation"​
>
  <ul​
>
     <li><a href="" title="Home Page​ for the ACME Company​
">Home</a></li>
     <li><a href="" title="Ways of contacting the ACME ​C​
ompany">Contact</a></li>
     <li><a href="" title="The history of the ACME Company">About</a></li>
 </ul>
</nav>

That code above meets all of the functional requirements laid out in the draft text:For pages that contain interactive controls, one of the following is true:
a mechanism is available for personalization of content that enables the user to add symbols to common form elements, common navigation elements and common interactive controls OR
contextual information is available for common form elements, common navigation elements and common interactive controls is programmatically determinable.

The <nav> element has strong semantics: it is the landmark identifier for code that is for navigating the page/site. Above it puts the Un-ordered List of links into the context of "Page navigation".


The @title attribute, as an attribute, is always applied to an element (thus the programmatic linkage) - it is an attribute of that specific element, and is not shared over multiple instances of the same HTML element on a page. 
Lisa, the language here is clear: a description of a target resource or a label or instructions for how to interact with an element is *exactly* what I would call contextual information, and further, because the @title attribute is directly and programmatically linked to the element it is applied to, it *IS* meeting the wording of the SC.


Now, don't get me wrong, using @title here would not be a great solution for a variety of reasons, and even HTML5 warns about using @title:



WARNING: Relying on the title attribute is currently discouraged as many user agents do not expose the attribute in an accessible manner as required by this specification




​...however, we cannot "forbid" content authors from using valid HTML for the purpose it was intended to meet: the lack of support is not the fault of HTML5 (or the content author), but rather the user agents.​ (Thus, from a legal compliance perspective today, I will argue that my solution meets the requirement)



So, if you are prepared to agree that the solution I have just shown above (the "loop-hole") is acceptable, then carry on. 





But I suspect it isn't, and further, if it is, it will do nothing to advance the cause or demand for coga-semantics, as it's pretty simple to apply @title with an undefined string value (as opposed to using coga-semantics with a prescribed taxonomy).




However, let's, for a minute, put @title aside. We also have aria-label, which almost meets the same use-cases:

​There may be instances where the name of an element cannot be determined programmatically from the content of the element, and there are cases where providing a visible label is not the desired user experience. Most host languages provide an attribute that could be used to name the element (e.g., the title attribute in HTML), yet this could present a browser tooltip. In the cases where a visible label or visible tooltip is undesirable, authors may set the accessible name of the element using aria-label.​

​I'm not sure if aria-label would be wholly appropriate here, however it too seems to suggest that it could be used to provide programmatically linked information about an element (although it may conflict with screen reader usage, or at least have a negative user-experience due to verbosity issues). 


But given the vagueness of the draft language, I suspect we'd start to see that in the wild as well, with content authors arguing that they are correct in using aria-label this way. Yes, we can perhaps tighten this up in the non-normative Techniques section, but we cannot outright "forbid" it in the actual normative SC if it can be shown that it is meeting the functional requirement per the existing specification(s). 

(In fact, we really cannot forbid *anything*, all we can do is require functional outcomes.)





​********

MY OTHER CONCERN:


Finally, I have ongoing concerns about "common", as in "common form elements, common navigation elements and common interactive controls"... what is "common"?  According to whom?

Without a pre-defined taxonomy of those "common" elements and controls (which controls, how many, determined again by whom?), we may also see site-owners, more interested in meeting the minimum legal requirement rather than truly meeting the needs of all users, artfully decide that all but the "Home" button/link on their site is "common" - that by *their* definition, all other links are uncommon, or rather, "unique" to their site. 


Likewise for form inputs: after "Name" and perhaps "email address" every other form input can be a subjective call, making measuring and testing for compliance almost impossible to do consistently - a significant showstopper for me (and the company I work for and represent).


​********

SUMMARY:


I don't have an easy answer for you, however today I am leaning toward suggesting to remove the "loop-hole" and simply create a AAA requirement to apply meta-data (i.e coga-semantics, but it could be others) on a pre-defined list of page elements and controls (where the list of defined elements and controls do not rely on "naming" but rather functionality). Additionally, with that fixed taxonomy we can in fact measure and test with accuracy and consistency, which is a foundational requirement for all new SC going forward (right?).


This incremental step for WCAG 2.1 (which can be advanced to AA in WCAG 2.2, or 2.3, or Project Silver - all down the road a bit) gets the *real* desire of the COGA TF into WCAG 2.1, but also leaves room for coga-semantics to mature and see some adoption in the wild: Alistair's voiced concerns over scalability are ones I also share. (And no, the one solution you have shown, all using the UserFirst add-on solution, isn't really evidence of scale, it's one implementation repeated over multiple sites.)


JF






On Wed, Jul 12, 2017 at 2:06 PM, lisa.seeman <lisa.seeman@zoho.com> wrote:
John had concerns with the words programmatically determined which he feels leave a huge loop hole that people could add some ambiguous text in the title tag. 

I would like to go with Gregg we change the wording from programmatically determined to programmatically available using deffinition from UAAG 2.0
IE:
Information that is encoded in a way that allows different software, including assistive technologies, to extract and use the information relying on published, supported mechanisms, such as, platform accessibility services, APIs, or the document object models (DOM). For web-based user interfaces, this means ensuring that the user agent can pass on the information (e.g. through the use of WAI-ARIA). Something is programmatically available if the entity presenting the information does so in a way that is explicit and unambiguous, in a way that can be understood without reverse-engineering or complex (and thus potentially fallible) heuristics, and only relying on methods that are published, and officially supported by the developers of the software being evaluated.


I think that will address these concerns. Let me know if there is any objection. 

All the best

Lisa Seeman

LinkedIn, Twitter













-- 
John Foliot


Principal Accessibility Strategist

Deque Systems Inc.

john.foliot@deque.com



Advancing the mission of digital accessibility and inclusion