E-mail List Archives
Re: Providing accessible names with <title>
From: Nick Bromley
Date: Sep 7, 2023 3:47AM
- Next message: Jeremy Echols: "Re: Providing accessible names with
" - Previous message: Nick Bromley: "Re: Providing accessible names with
" - Next message in Thread: Jeremy Echols: "Re: Providing accessible names with
" - Previous message in Thread: Nick Bromley: "Re: Providing accessible names with
" - View all messages in this Thread
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: Jeremy Echols: "Re: Providing accessible names with
" - Previous message: Nick Bromley: "Re: Providing accessible names with
" - Next message in Thread: Jeremy Echols: "Re: Providing accessible names with
" - Previous message in Thread: Nick Bromley: "Re: Providing accessible names with
" - View all messages in this Thread