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: Birkir R. Gunnarsson
Date: Jul 30, 2018 1:47PM

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.