- From: John Foliot <john.foliot@deque.com>
- Date: Wed, 12 Jul 2017 14:53:25 -0500
- To: "lisa.seeman" <lisa.seeman@zoho.com>
- Cc: "W3c-Wai-Gl-Request@W3. Org" <w3c-wai-gl@w3.org>, public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org>
- Message-ID: <CAKdCpxzQFbg_Ou49BvMzenR8i0u+w=wHcS5Gk0Qf5Nutbkb32Q@mail.gmail.com>
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
Received on Wednesday, 12 July 2017 19:53:58 UTC