E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 18 (In chronological order)

From: Nick Bromley
Date: Thu, Sep 07 2023 3:01AM
Subject: Providing accessible names with <title>
No previous message | Next message →

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

From: Steve Green
Date: Thu, Sep 07 2023 3:20AM
Subject: Re: Providing accessible names with <title>
← Previous message | Next message →

The "title" attribute has been part of the Accessible Name Computation for a long time, so all user agents should use it if an accessible name is not provided by a higher priority method. It's certainly sufficient for WCAG conformance, even if it's a bit nasty.

I don't know of any assistive technologies that don't use the "title" attribute if necessary. There might be some, but now we're returning to the age old question of whether we need to worry about user agents that don't support current standards.

I just had the same issue on a website and recommended that the accessible name should be implemented as hidden text if possible (because non-ARIA solutions should be the first choice), otherwise by an "aria-label" attribute.

Steve Green
Managing Director
Test Partners Ltd

From: Birkir R. Gunnarsson
Date: Thu, Sep 07 2023 3:26AM
Subject: Re: Providing accessible names with <title>
← Previous message | Next message →

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 ADDRESS 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
>
> > > > >


--
Work hard. Have fun. Make history.

From: Nick Bromley
Date: Thu, Sep 07 2023 3:35AM
Subject: Re: Providing accessible names with <title>
← Previous message | Next message →

I think the vast majority of the user group of this particular site are likely to be using non-ancient tech, but I think I'll still log a recommendation to update the naming approach while still retaining the <title> attribute as it does provide some benefit for certain users. Good point about use of hidden text.

From: Nick Bromley
Date: Thu, Sep 07 2023 3:47AM
Subject: Re: Providing accessible names with <title>
← Previous message | Next message →

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.

From: Jeremy Echols
Date: Thu, Sep 07 2023 7:20AM
Subject: Re: Providing accessible names with <title>
← Previous message | Next message →

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.

From: Yeti
Date: Thu, Sep 07 2023 8:10AM
Subject: Re: Providing accessible names with <title>
← Previous message | Next message →

Hello Listers,

Using the code below I have tested all combinations of the current versions of NVDA, JAWS and Narrator / FF, Edge and Chrome under Windows 10-64 with TTS and braille and could did not find any differences.

But I also have a stomach ache with the use of titles. And this is the reason:

Wherever I look, I find information like "Title provides additional information" or "The title contains descriptive text.".

However, the name of a function is “elementary information” for a button. So it doesn't belong in the title.

And so is the label for an input …

Ad Astra

Yeti

Code:
<html lang="en">

<head>
<meta charset="UTF-8">
<title>
Title or not
</title>
</head>

<body>
<h1>
Title or not
</h1>
<p>
Here is an input field with title instead of label:
<input title="titledEdit" type="text" name="titledEdit" id="titledEdit">
Here is an input field with label:
<br>
<label>
labeledEdit
<input type="text" name="labeledEdit" id="labeledEdit">
</label>
<br>
<button>classic</button>
<button title="titled"></button>
<br>
And this is the final line.
</p>
</body>

</html>

From: Mark Magennis
Date: Thu, Sep 07 2023 9:58AM
Subject: Re: Providing accessible names with <title>
← Previous message | Next message →

Nick, when you say the <title> attribute provides some benefit for certain users, do you mean that browsers sometimes generate tooltips containing it? If so, I wouldn't refer to this as a benefit because if a button needs a tooltip, and in my opinion all icon-only buttons do need tooltips, then the browser-generated tooltip will only be displayed by some browsers and support is dwindling. It used to be only Firefox that didn't display a tooltip with the <title> but now I believe it's Chrome and Edge as well. So this isn't a reliable method of providing a benefit and if it is needed it can't really be called a benefit.

From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > on behalf of Nick Bromley < = EMAIL ADDRESS REMOVED = >
Sent: Thursday 7 September 2023 10:35
To: 'WebAIM Discussion List' < = EMAIL ADDRESS REMOVED = >
Subject: [EXTERNAL] Re: [WebAIM] Providing accessible names with <title>

[You don't often get email from = EMAIL ADDRESS REMOVED = . Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

I think the vast majority of the user group of this particular site are likely to be using non-ancient tech, but I think I'll still log a recommendation to update the naming approach while still retaining the <title> attribute as it does provide some benefit for certain users. Good point about use of hidden text.

From: Nick Bromley
Date: Thu, Sep 07 2023 10:16AM
Subject: Re: Providing accessible names with <title>
← Previous message | Next message →

It was mainly for the tooltip, yes. These particular examples are still displaying as expected in my versions of Firefox, Chrome, Edge, plus Safari on Mac, which I think are all up to date. Are you seeing a different experience more generally?

Ideally I'd recommend the client creates bespoke tooltips, but there are so many more significant issues to deal with that the request would be way, way down the priority order. So keeping 'title' retains at least some benefit for now.

From: Jeremy Echols
Date: Thu, Sep 07 2023 10:26AM
Subject: Re: Providing accessible names with <title>
← Previous message | Next message →

FYI title-based tooltips are not accessible: they only display for mouse users (e.g., sighted keyboard-only users don't get anything). If they have custom JS that renders an accessible tooltip you may be fine, but if not, and those tooltips convey important information, they may in fact be non-compliant.

From: Mark Magennis
Date: Thu, Sep 07 2023 10:30AM
Subject: Re: Providing accessible names with <title>
← Previous message | Next message →

Yes, that's what I meant. They don't display on focus, only on hover.
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > on behalf of Jeremy Echols < = EMAIL ADDRESS REMOVED = >
Sent: Thursday 7 September 2023 17:26
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: [EXTERNAL] Re: [WebAIM] Providing accessible names with <title>

FYI title-based tooltips are not accessible: they only display for mouse users (e.g., sighted keyboard-only users don't get anything). If they have custom JS that renders an accessible tooltip you may be fine, but if not, and those tooltips convey important information, they may in fact be non-compliant.

From: Nick Bromley
Date: Thu, Sep 07 2023 11:12AM
Subject: Re: Providing accessible names with <title>
← Previous message | Next message →

Of course, there are plenty of things wrong with this kind of tooltip but it's arguable in this case whether they're a technical conformance fail. Even if they are, and I haven't finished assessing them to be certain, upgrading them would be a much lower priority. Most of the (not proper) buttons aren't even focusable, for a start...

From: Kevin Prince
Date: Thu, Sep 07 2023 4:07PM
Subject: Re: Providing accessible names with <title>
← Previous message | Next message →

Agreed - title will still be providing a tooltip (cos that's one of its purposes) for mouse-users.

K
Kevin Prince
Product Accessibility & Usability Consultant

From: Kevin Prince
Date: Thu, Sep 07 2023 4:11PM
Subject: Re: Providing accessible names with <title>
← Previous message | Next message →

Depends whether they are displaying information not available elsewhere - they are important for mouse users - but the message may be comveyed by other means (accessible name?0 for other modalities. Remember it's the function of the feature not every object on a page that needs to be accessible.

Kevin

From: Jeremy Echols
Date: Thu, Sep 07 2023 4:40PM
Subject: Re: Providing accessible names with <title>
← Previous message | Next message →

There are a lot of sighted keyboard-only users out there who don't use things like screen readers - we use things plugins (like "vimium" and "SkipTo Landmarks and Headings") help navigate. We never see the tooltip, so having it in the accessible name but not visible is still a pretty big problem.

I'm fortunate in that I can still use the mouse - it is just painful. Some can't us it at all.

This is why it's important that information be visible if it conveys necessary information, not simply be part of the name calculation.

From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Kevin Prince
Sent: Thursday, September 7, 2023 15:12
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Providing accessible names with <title>

Depends whether they are displaying information not available elsewhere - they are important for mouse users - but the message may be comveyed by other means (accessible name?0 for other modalities. Remember it's the function of the feature not every object on a page that needs to be accessible.
Kevin Prince
Product Accessibility & Usability Consultant

Foster Moore
A Teranet Company

E = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >
Christchurch
fostermoore.com<https://urldefense.com/v3/__http:/www.fostermoore.com/__;!!C5qS4YX3!B1JxdbWBPDUHdXfT77q7Gg9BGIpBMJjnjnZHlv_xFWyW9GO62b5wn_CfMzOlF-qkckp_cFZEe68J12_00Huuxtr6YMjZ$>

From: tim.harshbarger
Date: Fri, Sep 08 2023 7:51AM
Subject: Re: Providing accessible names with <title>
← Previous message | Next message →

Do we know if it works for Voiceover on Mac as well?

If I were going to summarize the conversation on this, I think I might summarize it this way.

The title attribute will be read by screen readers because it is part of the accessible name/description calculation. If that is the only reason it is being used, then it is a viable technique. However, there are other techniques that should be used first and it is better only to use this technique if it is the only option available to use or the only one that fits the parameters of the problem you are trying to solve.

Do not use the title attribute if you are using it at all for the visible tooltip. While a screen reader might read the information and the mouse pointer will display the tooltip, it won't be displayed for anyone using a keyboard or touch to interact with the element.

If you need a visible tooltip, you should look at other techniques that will make that information available whether the person is using a mouse, keyboard, touch, and screen reader.

Thanks,
Tim

From: L Snider
Date: Fri, Sep 08 2023 9:26AM
Subject: Re: Providing accessible names with <title>
← Previous message | Next message →

With the screen reader users (who rely on them, not test with them) I know,
they don't bother with the title. So in this case, I would use
ARIA...appropriate and not overriding any label or text that could be
provided and mirroring any link that is there for voice users. Others may
differ.

Cheers

Lisa

On Thu, Sep 7, 2023 at 6:02 AM Nick Bromley < = EMAIL ADDRESS 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
>
> > > > >

From: L Snider
Date: Fri, Sep 08 2023 9:27AM
Subject: Re: Providing accessible names with <title>
← Previous message | No next message

Oh and most of the people I work with don't access them, or it is far too
much work to get to them.

On Fri, Sep 8, 2023 at 12:26 PM L Snider < = EMAIL ADDRESS REMOVED = > wrote:

> With the screen reader users (who rely on them, not test with them) I
> know, they don't bother with the title. So in this case, I would use
> ARIA...appropriate and not overriding any label or text that could be
> provided and mirroring any link that is there for voice users. Others may
> differ.
>
> Cheers
>
> Lisa
>
> On Thu, Sep 7, 2023 at 6:02 AM Nick Bromley < = EMAIL ADDRESS 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
>>
>> >> >> >> >>
>