I am using Tooltip for multiple input elements and showing the Tooltip on input elements both hovering and clicking. I need to prevent the JAWS reader from reading the Tooltip content while hovering. I have tried to remove the "role" attribute and set the "aria-hidden" attribute as true.
But none of this way works and the Tooltip still readable. Any assistance would be appreciable. we are using JAWS 2020.2008.24 ILM
There could be several things at play here. The first is that JAWS, by default, does not announce anything when you move the mouse so I'm puzzled why you are hearing something read when you hover. There's a "mouse echo" setting in the JAWS Setting Center but that's off by default for JAWS (unless you're running ZoomText). Did you specifically turn that feature on?
Secondly, you say you are showing the tooltip. So you're not relying on the default tooltip feature of browsers via the title attribute? You are handling the tooltip yourself and displaying it via javascript? JAWS will not announce newly displayed text unless the new text is in an aria-live region. Are you using live regions?
And lastly, if a tooltip attribute is being used, such as the title attribute, then the tooltip text might be used in the accessible name calculation or in the accessible description. It's the last attribute looked at (step 2.I). If it's being used in that manner, then you would not want to turn that off. It's expected behavior by JAWS users.
You may want to post some code to clarify all these issues in order to get a more accurate answer.
Related
I'm upgraded to Vaadin 23.3 Preview because of Tooltip component. Works and looks great. Only one question - I use the tooltip as a toggletip. I added an icon to my textfield and manually open tooltip by clicking it. In order to close the tooltip, I have to click the icon one more time. Is it possible somehow to close the tooltip by clicking the tooltip text also?
That's not supported, as the Tooltip feature is not intended to be used for anything interactive. As the docs say:
Tooltips only support plain text content. They aren’t focusable and
can’t contain interactive elements.
Due to technical (and especially accessibility) reasons, interactive popups like that need a different implementation. There are some vague plans to add such a feature to the Vaadin platform in the future, however.
One component in the Vaadin's Directory that can be considered better suited for the task is Popup.
I am trying to use select2 for creating tags, but when I'm writing a new tag and I lose the focus of the field (click somewhere else, for example) what I was writing gets deleted.
Is there a way that after losing focus to the input of the select2, a new tag gets created?
From the documentation:
$('select').select2({
selectOnClose: true
});
This will capture the selection and create a tag if the user clicks elsewhere.
It looks like the browser problem that i've seen.
It seems that the tags option doesn't work correctly on ie11.
I don't have the same behavior between ie11 and chrome (and edge). If you check the example https://select2.github.io/examples.html#tags with ie, it is not possible to add tag. You can start taping letter but you lose the focus immediately.
Everything works on Chrome and Edge.
Is it this sort of problem, you've got.
I have the example code in my Angular.Dart component:
<paper-input bind-value="value" label="MyLabel" floatingLabel></paper-input>
The paper input shows the value that is in my Angular.Dart component, but the floatingLabel does not appear. However, upon clicking the input, the label appears with the standard animation as if it was hidden. It seems as though this is a bug with the "constructor" of the paper-input element. I expected the floating label to appear above the input field when text is in the input field regardless if it was newly created or not. Is there a way to fix this glitch?
Progress: (github.com/Polymer/paper-input/issues/117)
I am looking intensively at the issue listed above, however implementing the fix accordingly is not as easy. As suggested by #GünterZöchbauer, I can use the dart:js library. However it appears that the solution was designed specifically for PolymerJs and not particularly for PolymerDart. Maybe I am overthinking things, but I am unable to perform a simple port.
But the issue does bring up a good point. The element is unable to detect the change (for what ever reason). So something needs to poke it to trigger an update. I currently have the dart context to the Element, however the class (paper-input is the class) does not contain the method inputAction upon inspection with WebStorm. However assuming that the inputAction method was firing an event, I can simply use the dispatchEvent method. However which event will trigger the event without modifying the object itself? And not crashing the browser would be great (I have been crashing the webpage with Chrome's Aw, snap! blue screen of death with some event tests).
I'm aware of how to make invisible elements keyboard focusable and read by screenreaders, however for the purpose of a student-led survey - I would like certain elements to be invisible to screenreaders / keyboard focus to be less distracting, but have them visible for tutors to use using a mouse.
I've tried using iframes, however the keyboard can still 'tab' into them. I was considering a pop-up window that can control the parent window? - but might have some issues with blockers etc.
Many thanks! Mike
One of the simplest ways to get content ignored by a screen reader is to place it into an image and then set the alt text on the image to be "" in your HTML. This will cause the screen reader to skip this content since it can't interpret it. This will also eliminate any tabbing or keyboard focus since the web browser will treat it like any other image in your page.
Another way to do this, and a bit more complicated, is to detect if your page is being pulled into a screen reading browser and set the CSS properties of the content you don't want read by the reader to be have the following:
visibility: hidden; display:none;
Screen readers will ignore anything that is invisible and/or not displaying, thus it will not be read to the user. This is also a bit cleaner since you're not destroying the SEO ranking of the page but are just modifying the content displayed to users who don't need to see/hear it.
a good way to prevent screen readers from viewing an element is to apply the aria-hidden="true" attribute; this is fairly well supported by browsers, and will prompt JAWS and other screen readers to skip the content. You can also use role="presentation" - there's a good article on this here: http://john.foliot.ca/aria-hidden/
Applying tabindex=-1 will only only allow the element to be focused on by scripts and not keyboard input, so this will work too. Additionally, although I don't recommend it, I found while tearing my hair out over someone else's script, that if you don't have an 'href' attribute defined for a link element, (making it invalid) this also prevents focus.
I've got a site that's using sIFR, and some of the replaced text is being stretched vertically in IE9. It's only happening in places where the text wraps 2 lines, and it fixes itself when I hover my cursor over it. The sIFR text is a link, but I'm not sure if that has any correlation.
I've tried various settings changes like fitExactly, forceClear, and forceSingleLine (though I want it to be able to wrap), and those didn't work. I've tried changing the font-size, line-height, and all other dimensions to px instead of em. innerHTML isn't being used anywhere on the page. It's frustrating that it works after being hovered on, but not before.
And I know you're probably thinking "use cufon or #font-face, dummy" but I'm stuck with sIFR for now. The client wants what the client wants...
I've found a solution,
if you try to hover with mouse cursor the text will display correct so..
I write few line of code to put in sifr-config.js
forcing flash reset "onReplacemment" callback only when IE9 is detected
you must use Jquery for browser detection or use another javascript way
see the link below:
http://www.voo-doo.net/robotphobia/2011/05/fix-sifr-ie9