WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Fischer, Johannes
Date: Jul 31, 2018 12:22AM

Is the title attribute really not in the Accessible Name Calculation anymore? I think, it's still contained as last resort, look here: https://www.w3.org/TR/accname-1.1/#step2I
Letter I says: "Otherwise, if the current node has a Tooltip attribute, return its value".

When you click on "Tooltip attribute", you get the following definition: "Any host language attribute that would result in a user agent generating a tooltip such as in response to a mouse hover in desktop user agents."
In my opinion this is in the host language HTML the title attribute, because user agents generate a tooltip of this.

What else should letter I be about if not the title attribute?
Johannes

Von: WebAIM-Forum < <EMAIL REMOVED> > im Auftrag von Jonathan Avila < <EMAIL REMOVED> >
Gesendet: Dienstag, 31. Juli 2018 02:39
An: WebAIM Discussion List
Betreff: Re: [WebAIM] (Title element) WAS WCAG 2.1 - 1.3.5 - How to capture a violation?

I would oppose changes to drop the title attribute from being used for type input text and other form field name calculations. While it may not be preferred it has and continues to have widespread support and may be needed with certain CMS and legacy systems that don’t support aria additions.

Last I looked it was still listed.

Jonathan

Sent from my iPhone

> On Jul 30, 2018, at 4:19 PM, John Foliot < <EMAIL REMOVED> > wrote:
>
> Thanks Birkir,
>
> I am a tad concerned however that the original link I provided (Text
> Alternative Computation:
> https://www.w3.org/TR/accname-1.1/#mapping_additional_nd_te) did support my
> claim, but then going back and looking at other specs I realized the error,
> so it seems there may be a mis-sync within the group of specifications all
> related to this topic (accessible name calculation). I plan on raising it
> with the ARIA WG.
>
> From a practical perspective, I've long recommended that @title was not
> providing the accessible name consistently (certainly not for images), and
> so that technique should be avoided, but it seems that it still would meet
> the technical (legal) requirement. The third point of my 3-part answer is
> still accurate AFAIK
>
> JF
>
> On Mon, Jul 30, 2018 at 2:47 PM, Birkir R. Gunnarsson <
> <EMAIL REMOVED> > wrote:
>
>> Hey John
>> I thought it was a mistake, and nobody will balme you for getting this
>> thing wrong with the thorough and detailed explanation you were
>> providing on a different topic (that explanation has been duely saved
>> to my favorites and given a write up in my accessibility guide related
>> to WCAG 2.1).
>> NO problem, glad this was a minor mistake of yours and not a
>> substantive change in the W3C specifications.
>>
>>
>>> On 7/30/18, John Foliot < <EMAIL REMOVED> > wrote:
>>> So... I may have been wrong there...
>>>
>>> There are multiple documents now at the W3C related to name-calculation,
>> so
>>> that is a problem as well as a source of confusion.
>>>
>>> Further reading and research suggests that ARIA 1.1 no longer references
>>> the @title attribute directly, but the *HTML Accessibility API Mappings
>>> 1.0*
>>> Recommendation *does* (
>>> https://www.w3.org/TR/html-aam-1.0/#input-type-text-
>> input-type-password-input-type-search-input-type-tel-
>> input-type-url-and-textarea-element),
>>> as does the *Accessible Name and Description Computation 1.1*
>>> Recommendation (
>>> https://www.w3.org/TR/accname-1.1/).
>>>
>>> *The ARIA 1.1 *spec says this about @title:
>>>
>>> (The accessible)
>>> name comes from values provided by the author in explicit markup features
>>> such as the aria-label
>>> <https://www.w3.org/TR/wai-aria-1.1/#aria-label> attribute,
>>> the aria-labelledby
>>> <https://www.w3.org/TR/wai-aria-1.1/#aria-labelledby> attribute,
>>> or the host language labeling mechanism, such as the alt or title
>>> attributes
>>> in HTML, with HTML title attribute having the lowest precedence for
>>> specifying a text alternative.
>>>
>>>
>>> So I mis-spoke, and apologize for adding confusion. It was late, I was
>>> discussing a different topic, and didn't give enough research to that
>>> point.
>>>
>>> JF
>>>
>>> On Mon, Jul 30, 2018 at 12:40 PM, Birkir R. Gunnarsson <
>>> <EMAIL REMOVED> > wrote:
>>>
>>>> Agreed.
>>>> For clarity, we are talking about the title attribute, not the title
>>>> element.
>>>>
>>>> The Accessible name calculation algorithm has allowed use of the title
>>>> attribute as a source of accessible name for years.
>>>> It is accessible to more people than aria-label, which is purely a
>>>> screen reader solution, without CSS or JavaScript custom
>>>> implementation.
>>>> For focusable element the title attribute is supported as a source of
>>>> accessible name by the vast majority of common browser and screen
>>>> reader combinations.
>>>>
>>>> Removing a valid source of accessible name from the accessible name
>>>> algorithm that has been stable and used for years, on thousands of
>>>> pages, needs a pretty strong justification in my opinion.
>>>> It creates a lot of work and makes accessibility standards less
>>>> credible and robust.
>>>> Imagine recommending the use of a certain HTmL or ARIA attribute
>>>> because it solves a problem and it is a valid technique listed in a
>>>> standard.
>>>> If there is precedent that such attributes are removed from the
>>>> standard down the road, a product owner is not going to allocate
>>>> deverloper time to add this attribute.
>>>>
>>>> Assistive technology support is not a valid reason , as far as I know,
>>>> so what is?
>>>>
>>>>
>>>>> On 7/30/18, Joseph Sherman < <EMAIL REMOVED> > wrote:
>>>>> 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?
>>>>>
>>>>> Joseph
>>>>>
>>>>>
>>>>> -----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 (
>>>>> https://www.w3.org/TR/html-aam-1.0/#input-type-text-
>>>> input-type-password-input-type-search-input-type-tel-
>>>> input-type-url-and-textarea-element)
>>>>> 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
>>>>> <https://w3c.github.io/accname/>.
>>>>> 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.)
>>>>>
>>>>> >>>>> >>>>> >>>>> >>>>>
>>>>
>>>>
>>>> --
>>>> Work hard. Have fun. Make history.
>>>> >>>> >>>> >>>> >>>>
>>>
>>>
>>>
>>> --
>>> John Foliot
>>> Principal Accessibility Strategist
>>> Deque Systems Inc.
>>> <EMAIL REMOVED>
>>>
>>> Advancing the mission of digital accessibility and inclusion
>>> >>> >>> >>> >>>
>>
>>
>> --
>> Work hard. Have fun. Make history.
>> >> >> >> >>
>
>
>
> --
> John Foliot
> Principal Accessibility Strategist
> Deque Systems Inc.
> <EMAIL REMOVED>
>
> Advancing the mission of digital accessibility and inclusion
> > > >