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