WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: (Title element) WAS WCAG 2.1 - 1.3.5 - How to capture a violation?


From: Joseph Sherman
Date: Jul 30, 2018 10:39AM

I saw the exchange, that the Title element is no longer part of the accessible name calculation. We have been using the following code for some font icons- the plug in we are using allows only the addition of the Title element to the font icons repository. Manually adding labels for every use of the font icons is impractical, as most folks adding the icons are not code savvy, they just use the WYSWYG editor.

<a class="ts-font-icons-link " href="http://*/news/rss.html" target="_blank" title="RSS Feed"><i class="ts-font-icon icon-rss_ko" style="background-color:#ffffff; width: auto; height: auto; font-size: 31px; line-height: 100%;color:#353a3d;"></i></a>

Wouldn't it have be better to add the Title element to AT instead of removing it from the Specification?


-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of John Foliot
Sent: Friday, July 27, 2018 2:48 AM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] WCAG 2.1 - 1.3.5 - How to capture a violation?

Hi Jared,

(Quick related note - why is title attribute - https://www.w3.org/TR/WCAG20-TECHS/H65.html - sufficient to meet 1.3.1? This doesn't seem to meet your definition for "programmatically determined", right?)

ah yes, @title. A three part answer:

1) It is important to again remember that SC 1.3.1 wants a programmatically determinable way of determining the the label for the input - a machine recognizable identifier (for example @label or @title) that will have a value string that, for the purposes of the accessibility API's need for an "Accessible Name", can be a random string that can be both seen visually, but also can be presented in a different modality (audio). Again the *value* of the string here is for human consumption and cognition (thus a string that still needs to be "understandable" to meet SC 3.3.2), but the "association"
is programmatically 'determined' (aka identified and associated) using an attribute (fixed term) on the input element. (Remember too that it has to be a fixed term, so that the machine has a fixed text string to "look up"
or pattern match against.)

2) Originally, the HTML Accessibility API Mappings 1.0 (
included @title as part of the Accessible Name calculation:

1. If the control has an aria-label
<https://www.w3.org/TR/wai-aria-1.1/#aria-label> or an aria-labelledby
<https://www.w3.org/TR/wai-aria-1.1/#aria-labelledby> attribute the accessible
name <https://www.w3.org/TR/html-aam-1.0/#dfn-accessible-name> is to
be calculated using the algorithm defined in Accessible Name and
Description: Computation and API Mappings 1.1
2. Otherwise use the associated label element(s) accessible name
<https://www.w3.org/TR/html-aam-1.0/#dfn-accessible-name>(s) - if
more than one label is associated; concatenate by DOM order,
delimited by spaces.
3. Otherwise use the title attribute
4. If none of the above yield a usable text string there is no accessible
name <https://www.w3.org/TR/html-aam-1.0/#dfn-accessible-name>

However, as we know, in practice this wasn't working - @title was *NOT* being conveyed by screen readers as the accessible name. (I'll note that this is the fault of the Screen Readers for not supporting the spec, but also necessitating a change in the specification). This has been addressed with the publishing of Accessible Name and Description Computation 1.1 (W3C Candidate Recommendation 19 June 2018) (
https://www.w3.org/TR/accname-1.1/#mapping_additional_nd_te) which has removed @title from the calculation. As such it has negated that technique (note to self - action item two: more housekeeping)

3) We know that "technical conformance" does not equal "accessible", so the technique, while ineffective today (and I would recommend it be avoided) will none-the-less still meet the "technical conformance" that a legal reading of WCAG 2.0. conformance may mandate. (In other words, because it was an effective [sic] technique when 2.0 was published, we cannot un-ring the legislative bell that attached legal conformance to the technical
specification.) It sucks, mostly because legislation demands a fixed published spec, while technology changes daily from under our feet, but that is the answer to your question. (On a more positive note, because Techniques are non-normative, it may be easier to remove them, so I think we'll be able to do so, but I cannot "guarantee" that - we may have to settle with a WARNING in that technique.)