Re: support personlization - John concerns with programmatically determined loophole

Hi Lisa,

As I noted to you in our private exchange, I DO NOT have a problem
with "programmatically
determined
<https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-programmatically-determined-head>"
(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
<https://www.w3.org/TR/html51/dom.html#the-title-attribute>:

The title attribute represents
<https://www.w3.org/TR/html51/dom.html#represent> 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
<https://www.w3.org/TR/html51/dom.html#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.


   1. The <nav> element has strong semantics
   <http://w3c.github.io/html/sections.html#elementdef-nav>: 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".

   2. 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
<http://w3c.github.io/html/dom.html#element-attrdef-global-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
<https://www.w3.org/TR/wai-aria-1.1/#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
<https://www.w3.org/TR/html5/dom.html#the-title-attribute>), 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