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 31, 2018 6:38AM

Johannes,

Please see my earlier response.

JF

On Tue, Jul 31, 2018 at 1:22 AM, Fischer, Johannes < <EMAIL REMOVED> >
wrote:

> Is the title attribute really not in the Accessible Name Calculation
> anymore? I think, it's still contained as last resort, look here:
> https://www.w3.org/TR/accname-1.1/#step2I
> Letter I says: "Otherwise, if the current node has a Tooltip attribute,
> return its value".
>
> When you click on "Tooltip attribute", you get the following definition:
> "Any host language attribute that would result in a user agent generating a
> tooltip such as in response to a mouse hover in desktop user agents."
> In my opinion this is in the host language HTML the title attribute,
> because user agents generate a tooltip of this.
>
> What else should letter I be about if not the title attribute?
> Johannes
>
> > Von: WebAIM-Forum < <EMAIL REMOVED> > im Auftrag von
> Jonathan Avila < <EMAIL REMOVED> >
> Gesendet: Dienstag, 31. Juli 2018 02:39
> An: WebAIM Discussion List
> Betreff: Re: [WebAIM] (Title element) WAS WCAG 2.1 - 1.3.5 - How to
> capture a violation?
>
> I would oppose changes to drop the title attribute from being used for
> type input text and other form field name calculations. While it may not
> be preferred it has and continues to have widespread support and may be
> needed with certain CMS and legacy systems that don't support aria
> additions.
>
> Last I looked it was still listed.
>
> Jonathan
>
> Sent from my iPhone
>
> > On Jul 30, 2018, at 4:19 PM, John Foliot < <EMAIL REMOVED> > wrote:
> >
> > 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
> >>>>>
> >>>>>
> >>>>> -----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.
> >> > >> > >> > >> > >>
> >
> >
> >
> > --
> > John Foliot
> > Principal Accessibility Strategist
> > Deque Systems Inc.
> > <EMAIL REMOVED>
> >
> > Advancing the mission of digital accessibility and inclusion
> > > > > > > > > > > > > > > > >



--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
<EMAIL REMOVED>

Advancing the mission of digital accessibility and inclusion