Skip to content

Add "tooltip" display on focus / hover event #327

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
prushforth opened this issue Mar 1, 2021 · 7 comments · Fixed by #328
Closed

Add "tooltip" display on focus / hover event #327

prushforth opened this issue Mar 1, 2021 · 7 comments · Fixed by #328
Assignees
@prushforth @ahmadayubi
Labels
accessibility enhancement

Comments

@prushforth
Copy link
Member

prushforth commented Mar 1, 2021 •
edited
Loading

In testing the first experiment with @shepazu, we found that (due to my misunderstanding earlier comments) the user experience is not great for sighted keyboard users, since there is no display of the feature's accessible name on focus. The default <title>Feature</title> is being generated in paths today (which if features existed in HTML would not be necessary because of a default that we'll establish), and is presumably read by screen readers (I tried to download NVDA but their download is out of order at the moment).

In reviewing the svg <title> element, it looks like it would be reasonable to add <title> as an optional child of <feature>, which would have the <properties> and <geometry> siblings.

I added a feature request to the GeoServer MapML extension to allow the user to map content to the generated <feature><title> so that there is a meaningful experience available there.

Aside: <properties> is starting to look a lot like svg's <desc>, which is OK; we can have the conversation about that element's name in a working group. "properties" comes from GeoJSON and is meant to be familiar to developers familiar with that format.
@prushforth prushforth mentioned this issue Mar 1, 2021
Closed
@ahmadayubi ahmadayubi mentioned this issue Mar 1, 2021
Merged
@shepazu
Copy link
Member

shepazu commented Mar 1, 2021

I suspect SVG's <title> element is not a good fit for this design. The tooltip generated by browsers for SVG's <title> element has a considerable lag in first appearance, and typically disappears after some time, making it unsuitable for many users. IIRC, it also doesn't appear on focus, only on hover. Finally, it's not controllable by the user or the developer, and may appear atop developer-generated popups, obscuring them, so it's not suitable even for a fallback mechanism.

We need a more persistent popup tooltip. I'm writing up a description of what we need, which I'll deliver today.

@prushforth
Copy link
Member Author

The tooltip generated by browsers for SVG's <title> element has a considerable lag in first appearance, and typically disappears after some time, making it unsuitable for many users. IIRC, it also doesn't appear on focus, only on hover. Finally, it's not controllable by the user or the developer, and may appear atop developer-generated popups, obscuring them, so it's not suitable even for a fallback mechanism.

Should we not separate implementation mistakes from the markup design? What I mean is, proposing to create another similar element e.g. <ftitle> that ostensibly has the correct behaviours (and spelling), doesn't seem like a sustainable practice. Am I wrong?

@shepazu
Copy link
Member

shepazu commented Mar 1, 2021

Are we talking about the MapML spec, or the MapML-Viewer implementation?

If we're talking about the spec, I have other concerns with the <title> element in HTML, but I wouldn't push back on it in on the grounds I just suggested.

If we're talking about our implementation, I'm simply trying to address the realities of current browser behavior, which we need to work around to get proper behavior in our implementation.

@prushforth
Copy link
Member Author

prushforth commented Mar 1, 2021 •
edited
Loading

A bit of both: for the MapML spec, I suggest that we could add <feature><title> as a way of allowing author content intended for this use case. For the mapml-viewer, Ahmad will be able to create an implementation that uses the Leaflet popup, hopefully on both focus and hover. How that gets implemented by browsers is for a later discussion, maybe around the time just before the heat death of the universe.

@shepazu
Copy link
Member

shepazu commented Mar 1, 2021

If we're not talking about using the SVG <title> in our implementation, my comments above are irrelevant.

But for the spec, the HTML <title> element would be a strange choice, because it's only used in the HTML <head> element, not in the <body>, so using it this way would be unorthodox. I'd suggest reusing <label>, <caption>, or some other body-level element associated with labeling images or symbols.

In general, I wouldn't advise trying to port SVG element naming conventions into MapML, since the intent seems to be to integrate MapML into HTML, while SVG was designed during the period when it was assumed that namespaces would distinguish vocabularies, which made the later integration of SVG into HTML needlessly complex. To this day, there are painpoints in developers using SVG in HTML, which we can avoid by designing MapML to be a formal extension of HTML from the beginning.

@prushforth
Copy link
Member Author

prushforth commented Mar 1, 2021 •
edited
Loading

If we're not talking about using the SVG <title> in our implementation, my comments above are irrelevant.

We do currently use the <path><title> element to serialize the word "Feature", and I imagine we would need to continue to use it under the hood, assuming we adopt <label> or <caption> or some other body-level element associated with labelling.

<label> doesn't look like the correct choice, as it is associated to form controls via either containment or the for attribute.

<caption> doesn't look like the correct choice, because it is associated to the <table> element, so much like <head><title> it would seem to be a one-trick-pony.

<figcaption> looks to have the correct processing semantics (flow content, no extraneous attributes, associated to a figure by parentage), but also looks like they distinguished captions for tables from captions for figures by prepending "fig", so maybe it also is a one-trick pony and maybe that's the pattern we'll be following here: i.e. <featurecaption>?

@shepazu
Copy link
Member

shepazu commented Mar 1, 2021

I don't have a strong opinion about the name, other than that it shouldn't overload <title> for my aforesaid rationale. (FWIW, I wasn't concerned about the one-trick-poniness, but the parentage of <head> rather than <body>.)

It might be prudent to look at how the <figcaption> came to be introduced, to inform the choice:
http://html5doctor.com/the-figure-figcaption-elements/

Ultimately, this will be for a Working Group to decide; I just think it's smart to find a reasonably viable option in the meantime.

@Malvoz Malvoz mentioned this issue Jul 13, 2021
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@prushforth prushforth

@ahmadayubi ahmadayubi

Labels
accessibility enhancement
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Add tooltip on focus + hover ahmadayubi/Web-Map-Custom-Element
3 participants
@shepazu @prushforth @ahmadayubi