WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: best tooltip markup and behavior?

for

From: Steve Faulkner
Date: Dec 8, 2011 7:30AM


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