I have a simple textbox:
<input type="text" aria-label="First Name" title="First Name" />
I am showing the tooltip First Name on hover of textbox.
I used the aria-label as well as aria-labelledby but neither are working with Chrome or Firefox.
It's working on selection of the textbox, but not working on mouse hover.
But it's working fine with IE on mouse hover as well as on textbox select.
I am using the screen reader NVDA.
Its working on selection of textbox, but not working on mouse hover.
It's not intended to work on mouse hover.
NVDA reads the label for input elements on mouse hover, not the accessible name.
If you want something to be read, you have to add a label.
Just to avoid confusion the correct method for labelling an input is to simply use a <label>.
So you should have
<label for="firstName">First Name</label>
<input id="firstName" name="firstName" type="text"/>
The way to link labels and inputs is using the for attribute and point that at the input's ID.
The added benefit of this is that if you click on the label it will focus the corresponding input, which other solutions will not.
Should you for some reason require an input without a label then the following example illustrates how to do this correctly. (please do not do this if you can avoid it, labels are important for people with anxiety disorders to be able to check that they have filled in the correct field - however I know that sometimes 'designers' just won't budge and you have to workaround them....)
In this example we 'visually hide' the label using CSS and add placeholder text to the element. Just to reiterate this is a last resort for those designers who will not listen about accessibility and you should use visible labels.
At least doing it this way the input will function correctly for screen reader users.
.visually-hidden {
position: absolute !important;
height: 1px;
width: 1px;
overflow: hidden;
clip: rect(1px 1px 1px 1px); /* IE6, IE7 */
clip: rect(1px, 1px, 1px, 1px);
white-space: nowrap; /* added line */
}
<label for="firstName" class="visually-hidden">First Name</label>
<input id="firstName" name="firstName" placeholder="First Name" type="text"/>
Edit
Finally got chance to test this, works in Firefox, Internet Explorer and not in Chrome for announce on hover.
However if the label is visible it does work fine (if you hover the label, it does not announce if you hover the input itself even with a visible label), it also works fine for if you focus the input.
Final thoughts - show the labels (third time I said this in one answer. hehe), problem solved, no need to make it complicated.
Also, I am not sure why you think this is important, if someone uses a screen reader to assist while using a mouse they will click on an input, I have never come across anyone who would find not having a form field read on hover an accessibility issue if it works correctly once you click into the field.
Also the only people possibly affected by this are:-
screen reader users,
who use the mouse,
who have a sight impediment,
who use Google Chrome,
who also use NVDA,
and do not use a screen magnifier.
pretty specific, so not likely an issue.
I tested with NVDA on Firefox and Chrome and I can confirm the screen reader doesn't announce the value of aria-label on the input
I looked at 2.10 Practical Support: aria-label, aria-labelledby and aria-describedby and found out that aria-label isn't supported for input elements, but aria-labelledby and aria-describedby are. Taken from the link above:
aria-labelledby and aria-describedby are robustly supported for interactive content elements such as links and form controls including the many input types.
So I changed the code this snippet works with NVDA on Chrome and Firefox.
<input type="text" aria-labelledby="label" />
<span id="label">First Name</span>
Make sure to enclose the input and the "label" inside form for it to work optimally.
Related
I'm improving accessibility for a website. There are edit and delete buttons with an icon in them. We used this trick to make them readable by screen readers, but it only works when tabbing:
.screenreader {
position: absolute;
width: 1px;
height: 1px;
padding: 0;
margin: -1px;
overflow: hidden;
clip: rect(0, 0, 0, 0);
border: 0;
}
html:
<button class="btn-link">
<span class="screenreader">edit e-mail</span>
<span class="icon icon-md icon-create"></span>
</button>
But I want visually impaired users, who use a mouse, to be read to when hovering over the buttons. I cannot get it to work however. Hope someone can help me out!
There is only one subtle change you should need to make for this to work.
If you hide the icon with aria-hidden then the screen reader will fall back to the visually hidden text that you have provided (as at the moment it is probably attempting to decipher the icon).
The example below works in JAWS and NVDA after a quick test.
.screenreader {
border: 0;
padding: 0;
margin: 0;
position: absolute !important;
height: 1px;
width: 1px;
overflow: hidden;
clip: rect(1px 1px 1px 1px); /* IE6, IE7 - a 0 height clip, off to the bottom right of the visible 1px box */
clip: rect(1px, 1px, 1px, 1px); /*maybe deprecated but we need to support legacy browsers */
clip-path: inset(50%); /*modern browsers, clip-path works inwards from each corner*/
white-space: nowrap; /* added line to stop words getting smushed together (as they go onto seperate lines and some screen readers do not understand line feeds as a space */
}
<button class="btn-link">
<span class="screenreader">edit e-mail</span>
<span class="icon icon-md icon-create" aria-hidden="true">ICON</span>
</button>
As an aside I used a slightly different screen reader only class that is more robust for edge cases and future proofed, if you are able to then I would suggest replacing it with the visually hidden class detailed in this answer I gave.
First off, kudos for trying a combination that is rarely tested by accessibility professionals. Using mouse tracking with a screen reader is certainly a combination that some users require but it's not often tested.
I think you found this NVDA bug - https://github.com/nvaccess/nvda/issues/12047
Your original code and #graham's code both work with JAWS on Firefox, Chrome, and Edge. I hear "edit e-mail" when I hover the mouse over the button. You have to enable mouse echo in JAWS to hear the text under the mouse hover because mouse echo is not on by default.
However, with NVDA, it only works on Firefox. Both Chrome and Edge don't read the "edit e-mail" text with mouse hover. (Edge is based on the chromium engine so it makes sense that if Chrome doesn't work, Edge won't work either. The NVDA bug mentioned at the top also says it doesn't work in Edge).
By default, NVDA has mouse tracking on. You can toggle it with Ins+M or go into Settings and toggle the "Enable mouse tracking" checkbox.
The accessibility properties of the "edit e-mail" button are correct on Chrome.
Notice the "Name" (which is the accessible name) is "edit e-mail" and comes from "Contents". The accessible name should be read when the element receives focus. As you noted originally, it works fine with TAB but not with mouse hover.
So if the accessibility properties look correct in Chrome and JAWS works correctly with Chrome by announcing "edit e-mail" when you hover with the mouse, why doesn't NVDA read the text? NVDA certainly has access to the accessible name. NVDA reads the accessible name just fine in Firefox. So why does NVDA work on Firefox but not Chrome? I'm not sure (sorry). Potentially Chrome is not surfacing some information that NVDA needs, although JAWS works perfectly fine without this other information, which is why I think this is an NVDA bug.
So now you have to decide if you want to code around the NVDA bug. Sometimes that can lead to very messy code that potentially causes other problems. My recommendation is to use the code you currently have, since it's coded properly, and update the aforementioned NVDA bug.
I'm using the latest version of Chrome (74.0.3729.169) and noticed something slightly frustrating/interesting.
In the example below, begin typing an email address that you've used before. Once Chrome's suggestions appear, hover over one of them. Notice how dramatically the input shrinks.
input { padding: 5px; border: 1px solid #ccc; }
<input id="email" name="email" type="text" placeholder="Email">
I apologize if this doesn't recreate the behavior, however I've now been able to recreate it with this snippet across multiple computers, so I'm fairly confident this should work.
Additionally (to dip my toes into Meta a bit here) there's a fairly dramatic example of this on StackOverflow's very own login screen, in which the entire form shrinks as a result.
Compare the width of the two images below. Or, in the second image, compare the width of the "suggestion" with the input to which it corresponds.
From inspecting the input itself, I don't see any new styles that would explain this behavior. It doesn't seem related to padding either, as an input without padding still demonstrates this behavior.
My question is two-fold: Why does hovering a suggestion cause the input to shrink, and, is there a method/workaround to prevent this, other than fixed width or disabling suggestions entirely?
(I think that both of these workarounds are conditional. There are instances where you may not want to specify an input width for styling purposes, and disabling suggestions seems excessive and harmful to UX)
Or perhaps a Chromium bug ticket somewhere (I've searched with no luck - googling anything related to Chrome's autofill/autocomplete is a mess of unrelated articles about security)?
What you are facing is related to :-webkit-autofill pseudo class that is applying some default styling to the input with an autocomplete.
The :-webkit-autofill CSS pseudo-class matches when an element has its value autofilled by the browser.
Unnfortunately, I am not able to find where exactly those styles are defined but here is an example to confirm this. If you try to use the same value of width you will avoid the shrink effect:
:-webkit-autofill {
width: 173px;
}
<input id="email" name="email" type="text" placeholder="Email">
In the above link you can also read:
Note: The user agent style sheets of many browsers use !important in their :-webkit-autofill style declarations, making them non-overrideable by webpages without resorting to JavaScript hacks.
So even with !important you won't be able to override some styles:
:-webkit-autofill {
width: 173px;
background:red!important; /* will not work*/
border:2px solid blue;
margin-left:150px;
}
<input id="email" name="email" type="text" placeholder="Email">
For the width issue, I guess the only way is to define an explicit width as I have tried auto, initial, unset, etc and they aren't working.
If you cannot set a width and you want the default one, you can consider JS to do this:
document.querySelector('#email').style.width=document.querySelector('#email').offsetWidth+"px";
<input id="email" name="email" type="text" placeholder="Email">
I have the following HTML code :
<input name="uploadFile" id="uploadFile" style="width: 650px; background-color: rgb(255, 241, 187);" onchange="resetUpload()" type="file">
My problem is that on IE11, the background color of the input is not appearing - whereas on Chrome and IE 9 it is working fine. How we can fix that?
I know this is an old question, but for the benefit of anyone else finding it, I discovered a weird IE11 behaviour which I got around by using the ::selection pseudo-class.
It appears...and I haven't found anywhere that explains this, just my observations...that IE11 attempts to do something "clever" with the selection colour of text in an input field if you assign a "lighter" colour via CSS (for example #CFE8F5 or #F47B19).
For example, try this Fiddle: IE11 Link Text Test.
Try tabbing between the three input fields and see how IE11 inverts the text selection color in the first input field but does the expected thing on the second (no CSS applied) and third (::selection pseudo-class applied) input fields.
Hope this helps someone.
Useful link: Overriding default text selection colour
I am using a search input in my markup like so:
<input type="search" placeholder="search" />
Webkit styles an input element of type 'search' in a number of ways.
One feature is that when you start entering input - you see a cancel ('x') button on the right hand side of the input element.
However, if you are using a right-to-left language such as Hebrew or Arabic - the webkit cancel button still appears on the right hand side (instead of the lhs).
Here is a fiddle which demonstrates this point.
Is this a webkit bug?
If it is a bug - Is there a workaround where I can still use type="search" in my markup
It’s not a bug in the strict sense, since there is no public specification on the cancel button. It’s a (mis)feature, or incomplete localization. It has been reported e.g. as Bug 51499 at WebKit Bugzilla in 2010, and looks like it won’t be fixed.
Just for completeness, I just found a workaround for this problem on this post
The following code will enable you to style and position the 'x' button according to your needs.
input[type="search"]::-webkit-search-cancel-button {
/* Remove default */
-webkit-appearance: none;
/* Now your own custom styles */
...
...
}
See a LIVE DEMO of this.
Similarly you could remove the webkit cancel button entirely like this:
input[type="search"]::-webkit-search-cancel-button
{
display: none;
}
I am trying to simulate the look and feel of a Firefox disabled text input: textarea and input text.
The only browser compatibility I have to worry about is Internet Explorer 8. I do NOT have to worry about anything earlier (Intranet)
Internet Explorer does not allow one to change the text color of a disabled test input. It does allow background color to be changed but gray text on a gray background color was beyond illegible.
I have an input box and text area declared as follows:
<input name="Count" id="Count" onfocus="this.blur()" type="text" readOnly="readonly" value="0"/>
<textarea name="Notes" id="Notes" style="width: 100%;" onfocus="this.blur()" rows="10" cols="20" readOnly="readonly"/>
I have the following styles applied through a CSS:
input[readonly], textarea[readonly] {
color:black !important;
background-color: threedface !important;
}
Visually, this works excellently in both Firefox and IE. However, IE still allows a cursor into the text area or text box. What am I missing?
ADDITION
By cursor, I am referring to a keyboard cursor such as when you are typing a reply here.
Maybe my problem is better stated as a user can still click on the text area and have a keyboard cursor show up. It appears that the blinking cursor disappears quickly though.
try adding a cursor property to your css
input[readonly], textarea[readonly] {
color:black !important;
cursor: default;
background-color: threedface !important;
}
http://www.w3schools.com/cssref/playit.asp?filename=playcss_cursor&preval=default
--- 12/01/27
Revisiting this solution, I found the following to work for me, hopefully its helpful to you as well:
Use this simple jQuery function in script tag for all readonly input fields.
You can even use any specific ID or Class if you need for a particular item only.
$('input[readonly]').focus(function(){
this.select();
});
Can you use disabled=disabled instead of readonly=readonly?