E-mail List Archives

Search E-mail List Archives for

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

From: GILLENWATER, ZOE M
Date: Wed, Dec 07 2011 12:09PM
Subject: best tooltip markup and behavior?
No previous message | Next message →

I'm trying to decide on the best markup and behavior for help icons that show tooltips on hover and focus. There's not much out there on this topic; the description in the ARIA documentation is pretty brief and incomplete (http://www.w3.org/TR/wai-aria-practices/#tooltip<;http://www.w3.org/TR/wai-aria-practices/>;). Most examples out there deal with tooltips on form fields or link text, but I'm specifically wondering about tooltips on image icons, which seem to have some unique issues.

1. Is the trigger element-in this case, a question mark icon to denote "help" or "more info"-best marked up as a <button> surrounding an <img>, with alt text on the <img> saying "help" or similar? I don't think a link is right, since the link wouldn't actually go anywhere. Then again, similarly, maybe <button> isn't best since the button wouldn't do anything-would a plain <img> be better? (Tabindex and scripting would allow focus to get to it, of course.)

2. Is the tooltip best marked up as a span that follows the trigger (or in the trigger?), initially hidden with display:none and then revealed on hover and focus? Another option is to put the tooltip text in the img title attribute and use scripting to reveal and style that title attribute, but this didn't seem ideal to me as the tooltip wouldn't be visible to those with JavaScript disabled.

3. I don't think the tooltip text should be read by the screen reader in normal mode, just reading straight down the page. The trigger text like "help" would be, of course, but I guess this means the user would have to press enter when reading over the trigger in order to activate it, reveal the tooltip, and read the tooltip text. So maybe <button> does make sense...

4. When the screen reader user instead tabs directly to the trigger, should the tooltip immediately be read (again, following the reading of the trigger text)? Or is it better to have the screen reader user have to activate the button or use "say all" to choose to read the tooltip text?

Thanks for your insight,
Zoe


Zoe Gillenwater
Technical Architect, Design Standards Accessibility
Creative Experience Team
AT&T eCommerce

o: 919-241-4083
e: = EMAIL ADDRESS REMOVED =

This e-mail, and any attachments, are intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. It is the property of AT&T. If you are not the intended recipient of this email, you are hereby notified that any dissemination, distribution or copying of this email, any attachments thereto, and any use of the information contained is strictly prohibited. If you have received this email in error, please notify me at 919-241-4083 and permanently delete the original and any copy thereof.

From: Jared Smith
Date: Wed, Dec 07 2011 1:24PM
Subject: Re: best tooltip markup and behavior?
← Previous message | Next message →

On Wed, Dec 7, 2011 at 12:06 PM, GILLENWATER, ZOE M wrote:

> 1. Is the trigger element-in this case, a question mark icon to denote "help" or "more info"-best marked up as a <button> surrounding an <img>

I would make it a link. The truth is that there isn't really a native
element for this type of thing - interactive, but not a link or
button. I think buttons should be reserved for form submission or
button-like actions. Links, on the other hand, are used for all sorts
of things.

> would a plain <img> be better? (Tabindex and scripting would allow focus to get to it, of course.)

This seems like a lot of effort when a link will do this naturally.

> Another option is to put the tooltip text in the img title attribute and use scripting to reveal and style that title attribute, but this didn't seem ideal to me as the tooltip wouldn't be visible to those with JavaScript disabled.

If you need something that works without JavaScript, then title
attribute is your only possibility, but this would rarely be read by a
screen reader, and isn't available to keyboard users, touch screen
users, etc.

> 3. I don't think the tooltip text should be read by the screen reader in normal mode, just reading straight down the page.

> 4. When the screen reader user instead tabs directly to the trigger, should the tooltip immediately be read

If the tooltip appears when the user hovers the mouse over an element,
the equivalent keyboard action is generally onfocus - it should appear
when they tab to it. In this case, you can simply duplicate hidden
text or place the tooltip text within the link. Or you could use
aria-describedby on the link to reference the visible tooltip element
(with role="tooltip"). In both cases it would be read on link focus.

If the tooltip only appears on mouse click, the keyboard Enter or
Space is the equivalent. In ARIA jargon, this isn't a tooltip, but...
hmmm.... it appears that, surprisingly, there isn't an ARIA widget or
pattern for this type of thing. It's not really a "dialog" and it's
not really a "menu". I would assume that adding aria-haspopup to the
link and treating it as a menu or dialog, but without giving it one of
these roles would do the trick.

Does anybody else have ARIA recommendations for keyboard activated
(meaning Enter, not focus) tooltips?

Jared

From: GILLENWATER, ZOE M
Date: Wed, Dec 07 2011 1:45PM
Subject: Re: best tooltip markup and behavior?
← Previous message | Next message →

Thanks for your response, Jared. So is this the sort of HTML you had in mind?

<a href="#">
<img src="icon.gif" alt="help">
<span role="tooltip">This is the tooltip text.</span>
</a>

Hide the span with display:none, reveal it on hover and focus. Use scripting to return false on that link (or some other method to take care of the bogus # link destination).

This would allow screen readers to not have to read the tooltip text if they don't need it, as only the alt text and not the span text would be announced when reading straight through, but the span text *would* be automatically announced when they focus directly on the link. What about when the screen reader user is reading straight through, they hear something like "same-page link help", and they decide they want to follow that link to hear the help text? They press enter, and then what happens? That's not hovering or focusing, so the span wouldn't reveal. Does the script need to take over at this point so that pressing the Enter key when on the link also reveals the span?

Thanks,
Zoe

Zoe Gillenwater
Technical Architect, Design Standards Accessibility
Creative Experience Team
AT&T eCommerce

o:  919-241-4083
e:   = EMAIL ADDRESS REMOVED =

This e-mail, and any attachments, are intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. It is the property of AT&T. If you are not the intended recipient of this email, you are hereby notified that any dissemination, distribution or copying of this email, any attachments thereto, and any use of the information contained is strictly prohibited. If you have received this email in error, please notify me at 919-241-4083 and permanently delete the original and any copy thereof.

-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jared Smith
Sent: Wednesday, December 07, 2011 3:26 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] best tooltip markup and behavior?

On Wed, Dec 7, 2011 at 12:06 PM, GILLENWATER, ZOE M wrote:

> 1. Is the trigger element-in this case, a question mark icon to denote "help" or "more info"-best marked up as a <button> surrounding an <img>

I would make it a link. The truth is that there isn't really a native
element for this type of thing - interactive, but not a link or
button. I think buttons should be reserved for form submission or
button-like actions. Links, on the other hand, are used for all sorts
of things.

> would a plain <img> be better? (Tabindex and scripting would allow focus to get to it, of course.)

This seems like a lot of effort when a link will do this naturally.

> Another option is to put the tooltip text in the img title attribute and use scripting to reveal and style that title attribute, but this didn't seem ideal to me as the tooltip wouldn't be visible to those with JavaScript disabled.

If you need something that works without JavaScript, then title
attribute is your only possibility, but this would rarely be read by a
screen reader, and isn't available to keyboard users, touch screen
users, etc.

> 3. I don't think the tooltip text should be read by the screen reader in normal mode, just reading straight down the page.

> 4. When the screen reader user instead tabs directly to the trigger, should the tooltip immediately be read

If the tooltip appears when the user hovers the mouse over an element,
the equivalent keyboard action is generally onfocus - it should appear
when they tab to it. In this case, you can simply duplicate hidden
text or place the tooltip text within the link. Or you could use
aria-describedby on the link to reference the visible tooltip element
(with role="tooltip"). In both cases it would be read on link focus.

If the tooltip only appears on mouse click, the keyboard Enter or
Space is the equivalent. In ARIA jargon, this isn't a tooltip, but...
hmmm.... it appears that, surprisingly, there isn't an ARIA widget or
pattern for this type of thing. It's not really a "dialog" and it's
not really a "menu". I would assume that adding aria-haspopup to the
link and treating it as a menu or dialog, but without giving it one of
these roles would do the trick.

Does anybody else have ARIA recommendations for keyboard activated
(meaning Enter, not focus) tooltips?

Jared

From: Jared Smith
Date: Wed, Dec 07 2011 4:00PM
Subject: Re: best tooltip markup and behavior?
← Previous message | Next message →

On Wed, Dec 7, 2011 at 1:45 PM, GILLENWATER, ZOE M wrote:
> So is this the sort of HTML you had in mind?
>
> <a href="#">
>  <img src="icon.gif" alt="help">
>  <span role="tooltip">This is the tooltip text.</span>
> </a>

In this case, the role="tooltip" is not necessary. Instead, you would
position the text off-screen (NOT with display:none) and then position
it into the tooltip position when the link receives focus. You could
even do this entirely with CSS and not use scripting at all.

If you want to position the tooltip element outside the link, then it
would be something like:

<a href="#" aria-describedby="helptooltip"><img src="icon.gif" alt="help"></a>
<div id="helptooltip" role="tooltip">This is the tooltip text.</span>

The tooltip text would be hidden with display:none and then revealed
and positioned on hover and focus with JavaScript.

> Hide the span with display:none, reveal it on hover and focus.

Except that you need to be careful with display:none if the text is
inside the link. If link text is styled with display:none and then
changed to display:block when the link receives focus, JAWS will not
be read it because the text of the link is determined the moment it
receives focus (i.e., the text is invisible when it receives focus,
but when it becomes readable a slight moment later it is too late).

> This would allow screen readers to not have to read the tooltip text if they don't need it, as only the alt text and not the span text would be announced when reading straight through, but the span text *would* be automatically announced when they focus directly on the link.

If you use off-screen text, it will always be read as the reader is
going through the page. If you use display:none, it won't be read, but
in order for it to be read in JAWS on focus, it will have to be
outside the link, which necessitates JavaScript and ARIA.

> What about when the screen reader user is reading straight through, they hear something like "same-page link help", and they decide they want to follow that link to hear the help text? They press enter, and then what happens?

The screen reader won't trigger the link unless it has focus. They
would have to Tab to the link in order to activate it (except in
VoiceOver, which focuses links in reading mode).

But this still highlights an inherent issue with using links for
things that are not really links - the user might try to activate it
to go to a "Help" page. As I mentioned before, there's no suitable
alternative. If you use a <div> with tabindex=0, JAWS and NVDA read
"clickable", which isn't really much different than hearing "link".

To test things out, I put together a page at
http://webaim.org/temp/tooltip.htm that you can play with. It uses
very basic styling and inline scripting, but demonstrates how each of
these scenarios works a bit differently in different screen readers.

Jared

From: GILLENWATER, ZOE M
Date: Thu, Dec 08 2011 7:21AM
Subject: Re: best tooltip markup and behavior?
← Previous message | Next message →

Hi Jared,

Thanks again for more info. I don't know how to respond inline with yucky Outlook, so I'll paste the relevant pieces up here instead. I hope it's clear!

You said:
In this case, the role="tooltip" is not necessary. Instead, you would
position the text off-screen (NOT with display:none) and then position
it into the tooltip position when the link receives focus. You could
even do this entirely with CSS and not use scripting at all.

My response:
Yes, which is nice. But the disadvantages are that the user has to hear the tooltip text when reading through the page (I consider that a disadvantage in this case, though it could be argued otherwise), you get a focus outline around the tooltip instead of just the trigger, and a user might try to activate the bogus link.

You said:
If you want to position...

My response:
I want whatever is best. :-) What do you think I should do? Anyone else want to weigh in too?

You said:
If link text is styled with display:none and then
changed to display:block when the link receives focus, JAWS will not
be read it...

My response:
I didn't know this! Thanks very much for the info. Dang, though! It would have been so nice to be able to only let the text be read on focus.

You said:
The screen reader won't trigger the link unless it has focus. They
would have to Tab to the link in order to activate it (except in
VoiceOver, which focuses links in reading mode).

My response:
Surely this isn't true? I just opened up a screen reader again myself to make sure I'm not crazy and misremembering something major. :-) If I just let the screen reader read through the page, and it starts to read the text of a link, I just press Enter to activate that link. I don't have to press Tab to focus the link and then Enter. Are we misunderstanding each other?

Thanks,
Zoe


Zoe Gillenwater
Technical Architect, Design Standards Accessibility
Creative Experience Team
AT&T eCommerce

o:  919-241-4083
e:   = EMAIL ADDRESS REMOVED =

This e-mail, and any attachments, are intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. It is the property of AT&T. If you are not the intended recipient of this email, you are hereby notified that any dissemination, distribution or copying of this email, any attachments thereto, and any use of the information contained is strictly prohibited. If you have received this email in error, please notify me at 919-241-4083 and permanently delete the original and any copy thereof.


On Wed, Dec 7, 2011 at 1:45 PM, GILLENWATER, ZOE M wrote:
> So is this the sort of HTML you had in mind?
>
> <a href="#">
>  <img src="icon.gif" alt="help">
>  <span role="tooltip">This is the tooltip text.</span>
> </a>

In this case, the role="tooltip" is not necessary. Instead, you would
position the text off-screen (NOT with display:none) and then position
it into the tooltip position when the link receives focus. You could
even do this entirely with CSS and not use scripting at all.

If you want to position the tooltip element outside the link, then it
would be something like:

<a href="#" aria-describedby="helptooltip"><img src="icon.gif" alt="help"></a>
<div id="helptooltip" role="tooltip">This is the tooltip text.</span>

The tooltip text would be hidden with display:none and then revealed
and positioned on hover and focus with JavaScript.

> Hide the span with display:none, reveal it on hover and focus.

Except that you need to be careful with display:none if the text is
inside the link. If link text is styled with display:none and then
changed to display:block when the link receives focus, JAWS will not
be read it because the text of the link is determined the moment it
receives focus (i.e., the text is invisible when it receives focus,
but when it becomes readable a slight moment later it is too late).

> This would allow screen readers to not have to read the tooltip text if they don't need it, as only the alt text and not the span text would be announced when reading straight through, but the span text *would* be automatically announced when they focus directly on the link.

If you use off-screen text, it will always be read as the reader is
going through the page. If you use display:none, it won't be read, but
in order for it to be read in JAWS on focus, it will have to be
outside the link, which necessitates JavaScript and ARIA.

> What about when the screen reader user is reading straight through, they hear something like "same-page link help", and they decide they want to follow that link to hear the help text? They press enter, and then what happens?

The screen reader won't trigger the link unless it has focus. They
would have to Tab to the link in order to activate it (except in
VoiceOver, which focuses links in reading mode).

But this still highlights an inherent issue with using links for
things that are not really links - the user might try to activate it
to go to a "Help" page. As I mentioned before, there's no suitable
alternative. If you use a <div> with tabindex=0, JAWS and NVDA read
"clickable", which isn't really much different than hearing "link".

To test things out, I put together a page at
http://webaim.org/temp/tooltip.htm that you can play with. It uses
very basic styling and inline scripting, but demonstrates how each of
these scenarios works a bit differently in different screen readers.

Jared

From: Steve Faulkner
Date: Thu, Dec 08 2011 7:30AM
Subject: Re: best tooltip markup and behavior?
← Previous message | Next message →

hi Zoe, have a look at how i implemented display of figcaptions here
it may be helpful:

http://www.html5accessibility.com/tests/figures-nested.html#re2

<figcaption class="nest"><a id="caption2" tabindex="0"><img
height="17" border="0" width="17" alt="" src="i.png"><span
class="hid1">caption </span></a><span class="hid">Oil-based paint on
canvas. Eloisa Faulkner, 1756.</span></figcaption>


regards
steve
On 8 December 2011 14:21, GILLENWATER, ZOE M < = EMAIL ADDRESS REMOVED = > wrote:
> Hi Jared,
>
> Thanks again for more info. I don't know how to respond inline with yucky Outlook, so I'll paste the relevant pieces up here instead. I hope it's clear!
>
> You said:
> In this case, the role="tooltip" is not necessary. Instead, you would
> position the text off-screen (NOT with display:none) and then position
> it into the tooltip position when the link receives focus. You could
> even do this entirely with CSS and not use scripting at all.
>
> My response:
> Yes, which is nice. But the disadvantages are that the user has to hear the tooltip text when reading through the page (I consider that a disadvantage in this case, though it could be argued otherwise), you get a focus outline around the tooltip instead of just the trigger, and a user might try to activate the bogus link.
>
> You said:
> If you want to position...
>
> My response:
> I want whatever is best. :-)  What do you think I should do? Anyone else want to weigh in too?
>
> You said:
> If link text is styled with display:none and then
> changed to display:block when the link receives focus, JAWS will not
> be read it...
>
> My response:
> I didn't know this! Thanks very much for the info. Dang, though! It would have been so nice to be able to only let the text be read on focus.
>
> You said:
> The screen reader won't trigger the link unless it has focus. They
> would have to Tab to the link in order to activate it (except in
> VoiceOver, which focuses links in reading mode).
>
> My response:
> Surely this isn't true? I just opened up a screen reader again myself to make sure I'm not crazy and misremembering something major. :-) If I just let the screen reader read through the page, and it starts to read the text of a link, I just press Enter to activate that link. I don't have to press Tab to focus the link and then Enter. Are we misunderstanding each other?
>
> Thanks,
> Zoe
>
>
> Zoe Gillenwater
> Technical Architect, Design Standards Accessibility
> Creative Experience Team
> AT&T eCommerce
>
> o:  919-241-4083
> e:   = EMAIL ADDRESS REMOVED =
>
> This e-mail, and any attachments, are intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. It is the property of AT&T. If you are not the intended recipient of this email, you are hereby notified that any dissemination, distribution or copying of this email, any attachments thereto, and any use of the information contained is strictly prohibited. If you have received this email in error, please notify me at 919-241-4083 and permanently delete the original and any copy thereof.
>
>
> On Wed, Dec 7, 2011 at 1:45 PM, GILLENWATER, ZOE M wrote:
>> So is this the sort of HTML you had in mind?
>>
>> <a href="#">
>>  <img src="icon.gif" alt="help">
>>  <span role="tooltip">This is the tooltip text.</span>
>> </a>
>
> In this case, the role="tooltip" is not necessary. Instead, you would
> position the text off-screen (NOT with display:none) and then position
> it into the tooltip position when the link receives focus. You could
> even do this entirely with CSS and not use scripting at all.
>
> If you want to position the tooltip element outside the link, then it
> would be something like:
>
> <a href="#" aria-describedby="helptooltip"><img src="icon.gif" alt="help"></a>
> <div id="helptooltip" role="tooltip">This is the tooltip text.</span>
>
> The tooltip text would be hidden with display:none and then revealed
> and positioned on hover and focus with JavaScript.
>
>> Hide the span with display:none, reveal it on hover and focus.
>
> Except that you need to be careful with display:none if the text is
> inside the link. If link text is styled with display:none and then
> changed to display:block when the link receives focus, JAWS will not
> be read it because the text of the link is determined the moment it
> receives focus (i.e., the text is invisible when it receives focus,
> but when it becomes readable a slight moment later it is too late).
>
>> This would allow screen readers to not have to read the tooltip text if they don't need it, as only the alt text and not the span text would be announced when reading straight through, but the span text *would* be automatically announced when they focus directly on the link.
>
> If you use off-screen text, it will always be read as the reader is
> going through the page. If you use display:none, it won't be read, but
> in order for it to be read in JAWS on focus, it will have to be
> outside the link, which necessitates JavaScript and ARIA.
>
>> What about when the screen reader user is reading straight through, they hear something like "same-page link help", and they decide they want to follow that link to hear the help text? They press enter, and then what happens?
>
> The screen reader won't trigger the link unless it has focus. They
> would have to Tab to the link in order to activate it (except in
> VoiceOver, which focuses links in reading mode).
>
> But this still highlights an inherent issue with using links for
> things that are not really links - the user might try to activate it
> to go to a "Help" page. As I mentioned before, there's no suitable
> alternative. If you use a <div> with tabindex=0, JAWS and NVDA read
> "clickable", which isn't really much different than hearing "link".
>
> To test things out, I put together a page at
> http://webaim.org/temp/tooltip.htm that you can play with. It uses
> very basic styling and inline scripting, but demonstrates how each of
> these scenarios works a bit differently in different screen readers.
>
> Jared
>

From: Jared Smith
Date: Thu, Dec 08 2011 9:09AM
Subject: Re: best tooltip markup and behavior?
← Previous message | No next message

On Thu, Dec 8, 2011 at 7:21 AM, GILLENWATER, ZOE M wrote:

> But the disadvantages are that the user has to hear the tooltip text when reading through the page

It may be a disadvantage. If the text is useful, I don't see a problem
having it read linearly in the page. If it's lengthy text, then this
could be burdensome.

> you get a focus outline around the tooltip instead of just the trigger, and a user might try to activate the bogus link.

This can be resolved with styling - remove outline and add a border
(or whatever styles match your focused links).

> Dang, though! It would have been so nice to be able to only let the text be read on focus.

I can't think of a way to do this without JavaScript. The text is
either readable or it isn't. To toggle its readability state
(display:none) on focus AND have JAWS pick up that change requires
JavaScript.

> I don't have to press Tab to focus the link and then Enter. Are we misunderstanding each other?

VoiceOver works this way because it focuses links in reading mode. I
see that JAWS allows you to press Enter while reading to activate the
link - if your timing is just right. Unless I'm confused, with NVDA,
you must tab to the link.

Jared