I'm researching a website for accessibility issues and I found an image only submit input field for a search field.
Code of this input field is.
<input type="submit" value="Search">
I'm wondering if, giving this input field a value name 'Search' is sufficient to pass as an alternative text for succescriteria 1.1.1?
The value attribute provides the accessible name and visual label for a submit input, so the example should be sufficient.
If an actual image-input was used, the alt attribute must be used to provide an accessible name:
<input type="image" alt="Search" src="…">
Otherwise, it depends on the way the text is replaced with the image, as CSS can influence whether something is accessible or not. If the input element itself is still visible and focusable, it’s fine. If the whole element is hidden, especially from assistive technology, it’s not.
You can verify by inspecting the magnifying glass element in your browser, or by inspecting the accessibility properties. The name should be exposed.
Related
This is happening on an asp.net webforms application, using Chrome Version 72.0.3626.109 (Official Build) (64-bit).
The site is password-protected. The user logs in with a username and password. After a successful login the user is redirected to the "Loan Search" page. The Loan Search page contains a handful of text inputs.
The problem is Chrome will autofill my username into one of the text inputs (see image). "tregan" is the username I entered into the login page.
Chrome always selects this particular text input to autofill the username ("Contact Mailing Address"). This is happening to myself and several dozen other users of our web site.
Any idea why Chrome is doing this autofill, and is there anything I can do to prevent it? I cleared my Chrome autofill cache, but that did not fix the problem.
The answer is to add an invisible text input to the asp.net form called "username".
Several years ago we were having the same problem with a different input. The answer was to add an invisible input of type "password", as explained in this SO answer, scroll down to the phrase "It is so simple and tricky...":
Disabling Chrome Autofill
Below is the complete fix, I added these two elements inside the form element in our site's master page. Per #Jeff_Mergler's comment below, put these inputs at the top of your form tag:
<input type="text" id="username" style="width:0;height:0;visibility:hidden;position:absolute;left:0;top:0" />
<input type="password" style="width:0;height:0;visibility:hidden;position:absolute;left:0;top:0" />
Some more ways to try to workaround this:
Add autocomplete="off" to the <form> and/or to the <input>
Change the field's name/id
to something that does not have "name" or "user" in it
If it is not already inside <form> wrap the element with empty <form> tag
Randomize the name attribute of the input, or use data-name instead of name. You'll have to change the code that process the data accordingly.
Also I think it'll help to report this issue to Google via ⋮→Help→Report an issue (or Alt+Shift+I) to encourage them to fix these issues.
I was facing the same issue, i found a fix by wrapping my div inside a form tag and added a property autocomplete="off" in the form tag.
......
.....
Same here. This needs to be resolved by chrome. This is just dumb to have to add tags around textboxes. Also, quick tip to anyone needing to add form tag without having to re-do your CSS. Add "display:contents;" to the form. It will act as if its not even there.
We have enabled autocomplete property true for all input fields. We didn't use form tags in the templates. The input fields don't fetch the previously entered data. So how can we implement autocomplete property.
Firstly, this is not specific to Aurelia. Once the element is in the DOM, it is a feature of the browser to offer the user a previously entered value for that field given that an assumption can be made about what the field is supposed to be!).
Depending on the browser, the autofill feature relies on having 'known' input attributes (name and type) and possibly even the surrounding text, including label text.
If you are not getting the expected results, try making sure your inputs have very obvious name attributes, first. Eg.
<input type="text" name="email">
If you could share a snippet of code, I might be able to offer more help.
Is the following valid per WCAG 2.0?
<span id="my-label">Your photo</span>
<input id="my-upload" type="file" aria-labelledby="my-label">
The OS X screen reader understands this, e.g. reading the label for the input when it gets the focus, but Total Validator complains as follows:
You can try it yourself by running Total Validator on this page. Is Total Validator correct to report this error, or is this a bug in Total Validator?
(Obviously, in this particular example, I could use a <label for="my-upload">, instead of relying on the aria-labelledby. One could even argue that using a <label> has more semantic weight and should be prefered. But that is not the question I'm asking, as in my real-life scenario using a <label> can't be done.)
aria-labelledby is used to provide information to accessibility devices like screen readers. It won't be of any help if you do not use such specific device.
It won't give any information to 99% of people. So yes, Total Validator is correct to report this as an error as WCAG does not require to use a specific device. That being said, you can use the title attribute in situation where you can't use a label tag.
See: H65: Using the title attribute to identify form controls when the label element cannot be used
It is ok to use aria-labelledby as a way of creating an accessible name where a visible label already exists. It is better to provide a label association using for-id because that will allow clicking on the label text to place the focus in the input field (or select the checkbox or radio button).
Your accessibility analyzer is old. If you use the aXe accessibility analyzer, you will notice that it will not complain about this issue.
I couldn't find anything in the angularjs docs, nor online, about this specific aspect of form validation. You know when someone writes something in an input field (example: name, phone number, email etc.), and then there is a green checkmark that appears? Or an X that appears implying it's wrong, incomplete etc.
So, I have those images in my folder and ready for use in either situation. Problem is, I can't find the documentation to properly achieve what I would like to achieve. I am thinking that angularjs would be the solution to use, as the rest of my code in is angular.
Since this is angularjs, the only post and documentation that presented a viable option (which does not work for a few reasons) are the following options:
How to put an image in div with CSS?
https://docs.angularjs.org/tutorial/step_09
I was thinking of using CSS to trick the browser into making the one or the other image appear as it validates. I thought it might force the image in my other div to appear, but to no avail.
For example, in this CSS, I tried this:
.ng-valid.ng-dirty .div.test{
border-color: green;
content:url(http://example.com/image);
}
Using this in my HTML:
<div class="test">
<label style="float:left">by:</label>
<input class="form-control controltwo" required ng-model="reviewCtrl.review.author" name="email" id="email" type="email" style="width:350px;" placeholder="Email Address"/>
</div>
As I said before, I am trying to achieve something using angularjs. As CSS can be used for styling, it cannot be tricked into being a styling option and a complex validator. I've tried a few tricks as show on the links, but they don't work. As for the second link, it just isn't made for this purpose, and considering they are made only for filters and images, the docs for the filters don't help a bit.
A simple way of achieving what you want is to look in to the $valid or $invalid properties of your form control.
For example, to show a small message when the email is invalid, you would put this element in your markup.
<div ng-show='reviewForm.email.$dirty && reviewForm.email.$invalid'>Invalid Email</div>
Where reviewForm is the name of your form, and email is the name of your input control.
Here is a plunkr demonstrating this: http://plnkr.co/edit/tUuToy99xjfMhbyMd3eV
You can replace the element with whatever else you want
You can do this with ng-show, ng-src and ng-model depending on what you're validating.
https://docs.angularjs.org/api/ng/directive/ngModel
https://docs.angularjs.org/api/ng/directive/ngShow
https://docs.angularjs.org/api/ng/directive/ngSrc
The example under ng-model:text shows pretty much what you want. If you're not using forms, you should be able to use ng-change to fire off a check and change the image to the appropriate one.
https://docs.angularjs.org/api/ng/input/input%5Btext%5D
If ng-show watches the $valid attribute of the field in question you can hide the check mark when validation is false, and show it when true. You can flip the logic if you want an X.
what are benefits of using a hidden field in ASP.NET when we can use another invisible element such as label or text box?
The hidden field generate <input type="hidden" /> element on the page, which cannot be seen but the client can get the element, set the data and pass to the server:
document.getElementById('<%= SomeHiddenField.ClientID %>').value = "data_pass_to_server";
after postback you can get the value:
var clientData = SomeHiddenField.Value; // "data_pass_to_server"
If you're using invisible textbox (<asp:TextBox Visible="False" />), there's no element generated in the html file.
Either way works, for text box, don't use .visible="false"
use
yourTextBox.Style.Add("display", "none")
or
yourTextBox.Style.Add("visibility", "hidden")
A hidden field renders as input type="hidden" in the resulting HTML. Being an input the value in the input is submitted to the server on postback while this is not the case with a label. Depending on whether or not you want that value submitted to the server you should use input or label. If you don't want the value to be submitted then label is the right solution and hidden field is wrong.
I am not sure what you mean by invisible textbox but if you are trying to make it invisible via CSS keep in mind that the input type has semantic meaning to search engines, bots, etc. Also at some point your HTML might be served without CSS or with different CSS and the text box will become visible to the user. Otherwise there are no differences between hidden field and invisible text box as both of them render inputs.
Practically you can achieve the same thing with any of them, but since you want a "hidden field", semantically speaking the hidden field in ASP.NET is your best bet for readability reasons.