Add possibility to generate links from tooltips #397
Conversation
Sometimes, help descriptions are too long for a small tooltip and are better of at a different location. In these cases it would be nice to provide a direct link (opening in a new tab) instead. The option "linkTooltipsIfAvailable" does exactly that. The old behaviour is preserved if the option is false (default).
The tooltip buttons have no label and will therefore be read by a screenreader with a random id instead of a helpful message.
|
Any news here? Just wondering if you just haven't found the time yet or if there is anything wrong with this. Thank! |
Currently, when pressing the button to reveal the tooltip, the tooltip is not immediately read, because it is rendered somewhere else in the html tree. This forces the screen reader to read out the tooltip.
Martin-Idel
force-pushed
the
add_link_tooltips
branch
from
64b0a75
to
7592002
Compare
|
I added one minor commit to ensure that the description is immediately read by screen readers. |
|
Sorry about that, I am a little overworked in this period. But at some point soon I will catch up on pull requests. Hopefully in the meantime you can use your fork directly and are not too slowed down by me (it is pretty straightforward to build and push a fork on npm in another namespace). FYI the v2 will soon be considered maintenance only, I don't intend to add significant functionalities. Instead I intend to focus my efforts on working on a draft for the next major version. |
|
Hi, no big deal. Yes, I'm using my own branch with Regarding the next major version I'm totally on board. We want to switch to vue 3, too and vuetify and vjsf are the blockers for now. The current functionality for vjsf is good - most of our issues are smaller accessibility things. |
Closes #383
This PR adds a new option for tooltips
linkTooltipsIfAvailablewhich, if true (default should befalse) will render descriptions which contain just an URL not as tooltip but as directly clickable button which will open the link in a new window. If the the option is false, the old behaviour is preserved.I also added a test/dev-example to the docs demonstrating the behaviour.
In addition, I added a second commit which adds an aria-label to the tooltip buttons. Currently, the buttons have no label at all which makes screen readers read them as "unlabelled button 1234" with some ID. This is a second commit, if you don't like it or would want me to provide a second PR, I can do so.
If you like my accessibility commit, I will likely supply a couple of further accessibility fixes in the future.