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 2:19PM

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