Re: Footnotes and Tooltips

Jeanna,
I owe you an apology because I left out context (my poor excuse is that I
should never respond via mobile as my mind seems to autopilot into
abbreviating my thoughts and leaving out extras, i'm on my laptop now).

By any chance is there a rough mock-up of the tooltip that you could share?
Often times when asked whether something is accessible or not, my response
is 'it depends' because context is needed.

The issue with our component was that it covered parts of what the user was
interacting with. I believe that's a key thing. The vendor's comment was
that "it obscures its visibility."

The items this comment was in reference to, were links with hovers. Our
design blocked users from reading the entire link text because the hover
overlapped it when the user tabbed to it. One example of how this is an
issue is that this may be troublesome for screen-magnification users who
navigate content a portion at a time. People may not have a full view of
the screen. Another item we had was a dropdown with the label on the
bottom, again the issue being that the dropdown covered the label when it
opened.

So this is where I feel the question of whether what we're designing forces
disabled users to work to benefit abled users comes in. It might sound a
bit harsh but it's more a question I ask myself and I think we humans tend
to be harder on ourselves.

I feel for screen readers it's easier to solve. Visually, there are some
options like making what triggers the tooltip a header in the text that
appears to help reinforce what that was related to when the user opens it
and directing designers to make sure that the important parts aren't
covered and still look related at the same time.

Hope this helps!
Caroline


On Tue, Apr 28, 2020 at 12:23 PM Guy Hickling <guy.hickling@gmail.com>
wrote:

> It isn't the mose hover functionality that is the problem in the popup
> method. In mouse use it doesn't matter if the popup overlays other content
> on hover because the user simply moves the pointer away to stop the hover
> and they can see the content again.
>
> The issue of obscuring content potentially occurs in keyboard navigation
> where users use the Tab key to jump from one link or button to the next. If
> the popup/tooltip appears as soon as keyboard focus lands on the footnote
> reference, then that is an accessibility issue for those users as it hides
> what's underneath (and also because it foreces them to see the popup text
> when they haven.t asked to do so). That is why the references must be
> marked up as buttons that only reveal the popup if the keyboard user
> presses Enter or Spacebar. That way the keyboard user can read the ordinary
> content first, and they only get to see the popup text if they specifically
> ask to, i.e. if they operate the button.
>
> So I hope that makes it clearer, and maybe it also explains why Caroline's
> vendor found an issue with it? (- if they had some other problem with it
> perhaps you could share exactly what they actually said about it so we can
> consider that. But I am not clear why you say the mouse user has to "click
> away" to see the underlying content if they used hover to see it? It looks
> like they weren't looking at a hover case).
>
> Jeanna, I suggested the popup method (and your client asked for that) as
> an alternative to showing footnotes, not in addition to them. There is no
> actual need to show the footnotes at all if the same texts are shown as
> popups. You might feel that it is good to show the footnotes at the bottom
> as well (and if the footnotes are specially important legally your legal
> people might insist on it), but in that case there would be no need to
> provide any mechanism to jump down to them from the references because the
> popup texts do that job for all users including blind and keyboard users -
> if marked up correctly. I agree trying to make the references both open a
> popup and provide a link to a footnote certainly would be difficult, but
> that is not the intention of this method.
>
> Finally, screen reader users can hear what's in the popup boxes when they
> appear. In your case the developer must give the popup container an
> aria-labelledby attribute that references the text in the popup (i.e. what
> you originally has as a footnote). Then when the popup appears they must
> use the JavaScript focus() function to place focus on the container; that
> triggers screen readers into announcing the text inside it. That is just
> standard practice for all popup dialogs. So all users are accounted for by
> this method, no one has to navigate down to footnotes at the bottom of the
> page.
>
> Regards,
> Guy Hickling
>
>
>
>