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: John Foliot
Date: Jul 30, 2018 1:36PM

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