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 11:40AM

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.