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: Jonathan Avila
Date: Jul 30, 2018 6:39PM

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
>>>>>
>>>>>
>>>>>