E-mail List Archives
Re: Providing accessible names with <title>
From: Jeremy Echols
Date: Sep 7, 2023 7:20AM
- Next message: Yeti: "Re: Providing accessible names with
" - Previous message: Nick Bromley: "Re: Providing accessible names with
" - Next message in Thread: Yeti: "Re: Providing accessible names with
" - Previous message in Thread: Nick Bromley: "Re: Providing accessible names with
" - View all messages in this Thread
One thing I've run across recently with NVDA and Firefox is when people use title too much, they start putting it on things that already have text just because they get in the habit of adding a title to every last thing. With Firefox and NVDA, a link with a title will double up the announcement. For instance, this markup results in "Next - Setup and Installation link Setup and Installation":
<a href="somewhere" title="Setup and Installation">Next - Setup and Installation</a>
This is still probably not a WCAG conformance issue, but it can be confusing, and is just one more reason to try to push people away from using it. Note that I hear similar issues when there's both a title and another accessible name, such as "aria-label".
I'm not sure why NVDA and/or Firefox are using both values instead of ignoring the title here, but it's definitely sub-par. And once devs get in the habit of using it, they seem to just love to put it on everything. The example above is from a documentation project I'm working on, and it's got titles in some of the weirdest places.
-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Nick Bromley
Sent: Thursday, September 7, 2023 02:47
To: 'WebAIM Discussion List' < <EMAIL REMOVED> >
Subject: Re: [WebAIM] Providing accessible names with <title>
Can you remember what combination generated that result and did it differ if another naming mechanism was used?
NVDA, for example, always states "button" followed by the name when browsing with arrow keys, regardless of how the name is provided (nested text label, aria-label, or title). By contrast, JAWS always announces the name of the button first, again regardless of how that name is provided.
I agree that semantically <title> isn't great but clients often don't care about that argument (understandably) if ultimately it works.
-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Birkir R. Gunnarsson
Sent: Thursday, September 7, 2023 10:27 AM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] Providing accessible names with <title>
I have found some combination of browsers/screen readers to still treat the title attribute as accessible description, even if it is the only source of accessible name. E.g.:
They announce the title value after the word "button" but not before, so for an instance you think the button is not labeled when you are exploring in browse mode with arrow keys the title value does not always show up, you need to focus the button to hear it Granted I last tested this a year or two ago so it may have changed.
And, on the other hand it could be argued that using title is better for some users because it naturally shows up, at least for mouse users who hover over the button, whereas aria-label is purely intended for assistive technology users.
The final and most semantic argument is that the intended use of the title attribute is to provide information about the element, not to name it, but that's all pretty theoretical.
Last and least, I personally just don't like it (which is a pretty weak argument).
On 9/7/23, Nick Bromley < <EMAIL REMOVED> > wrote:
> I'm testing a site that has a whole load of icon-based buttons that
> are named only with the <title> attribute. I know this isn't
> considered a good method of providing an accessible name, but it works
> across multiple browsers, devices, screen readers, and voice control
> software (although all reasonably modern, it has to be said). So when
> the W3C states in its
> <https://www.w3.org/WAI/ARIA/apg/practices/names-and-descriptions/>
> 'Providing Accessible Names and Descriptions' authoring practice
> guidance that fallback mechanisms (of which <title> is one) "typically
> yield low quality accessible names that are not effective", is there
> anything I'm missing? Perhaps some more niche assistive technologies
> that I haven't verified it with? Or does it date back to a time when
> support was more patchy?
>
> I'm minded to log a best practice recommendation to use aria-label
> instead, but could do with a bit more specific justification, if any exists.
>
>
>
> - - -
>
> Nick Bromley
>
> Director & Accessibility Consultant
>
> Red Kite Digital Accessibility Ltd
>
> > > archives at http://webaim.org/discussion/archives
> >
--
Work hard. Have fun. Make history.
- Next message: Yeti: "Re: Providing accessible names with
" - Previous message: Nick Bromley: "Re: Providing accessible names with
" - Next message in Thread: Yeti: "Re: Providing accessible names with
" - Previous message in Thread: Nick Bromley: "Re: Providing accessible names with
" - View all messages in this Thread