I have a form in a few input fields. For one of the input field I have a length validation, for which I have used maxlength="20".
The issue here is that the JAWS users don't come to know that the max length has been reached in the input field, as JAWS continues to keep on reading the key they press on their keyboard.
Is there a way to make this accessible?
Regards,
Zeeshan
Three approaches, not mutually exclusive:
Include a statement about maximum number of characters before the element.
Implement a JavaScript-driven check on the number of characters when leaving the element.
Implement a JavaScript-driven check that is triggered by any input event on the element and that checks the number of characters on the fly.
Method 1 is simplest, but it might be too disturbing if we expect that in the vast majority of cases, the length is not an issue. Method 3 takes more programming effort than method 2 but provides for better accessibility: the user gets a message as soon as he tries to exceed the limit.
As #Quentin comments, this is really something that should be handled by JAWS. The maxlength attribute for input has been in HTML as long as it has had the element, from HTML 2.0 (1995), so there is little excuse for not having implemented it. I cannot check whether JAWS actually supports it, so I have written my answer assuming that it does not.
When the limit is reached you can detect that with JS and then announce it to assistive technologies e.g. screen-readers by insert the following after the <input/>
<p class="visually-hidden" aria-live="assertive" role="alert">Limit reached. You can only use 20 characters in this field.</p>
Note: remember to remove it if/when within the limit again.
You can hide .visually-hidden off-screen with CSS.. or this information could actually be useful for everyone so you could omit the .visually-hidden class if it fits your design.
And to let screen-reader users know about the limit you could put <span class=visually-hidden>Max 20 characters</span> inside your <label>
element. (and same goes here, perhaps all users could benefit from having that info visible..)
you can try it, mws-stat is your input field class name
<input type="text" class='mw' maxlength='20'/>
var a=$('.mw').attr('maxlength');
console.log(a);
and then
$('.mw').keyup(function(){
console.log($(this).val().length);
});
Use title attribute of the text field to convey the max length. It worked great for us on government project with users using JAWS. I believe NVDA also uses title attribute to convey the information. In addition you can use JavaScript to give audible "ding" to notify user that the field has reached the max limit.
You can do something like this
<script>
function show(){
var x=document.getElementById("text1").value;
var y=x.length;
document.getElementById("p1").innerHTML="Characters left" +(20-y);
}
</script>
<input type="text" id="text1" maxlength="20" onkeydown="show()">
<p id="p1"></p>
Here is the fiddle http://jsfiddle.net/EVrqP/1/
Related
I have a form that has a set of checkboxes. The user needs to check one or more of these. I'm confused as to how to deal with this via form validation and markup. I have an Error summary box that I can add a message, but my other form fields also have a message under each field that specifies the error, but since this is an issue with the set, I don't think that would be appropriate, so I assume just having it in the error summary box and being able to click on a link to the first of the set of checkboxes would be acceptable? Secondly, what about aria tagging? Would aria-required be appropriate? If so, how do you specify this for the entire set of checkboxes rather than each one individually, since none of these are required in and of themselves?
There isn't good markup to say a group of stuff is required but each one individually isn't necessarily required (although at least one is required). It's hard enough to express that in English :-)
With aria, you can sort of get around that.
<div role="group" aria-label="my list of checkboxes, you must select at least one">
<input type="checkbox"...>
...
<input type="checkbox"...>
</div>
aria-required="true" isn't allowed on the group.
I've seen the same thing enough times now that it's sparked my curiosity. It's even on this site!
The <input id=title ... > element on the "https://stackoverflow.com/questions/ask" sets maxlength=300 and data-max-length="150".
Namely, the input box will allow you to type 300 characters into it, but the form will not accept anything above 150.
Is there a reason one might do this?
It's most likely to prevent user from loosing end of the text while not noticing that input is limited or when pasting. After getting an error user can edit input while text is intact.
here is my code :
<textarea name="doctornotes" id="doctornotes" cols="80" rows="10" spellcheck="true"></textarea>
in this text area i am entering below text :
This is a medicine name : CROCIN TABS
here CROCIN is medical term and red line is coming and i don't want red line below my text if it is medical terms.
You cannot. The spellcheck attribute is vaguely defined, and there is no way to specify which kind of spelling checks are to be performed (and probably won’t be anytime soon). Currently, browsers that support spellcheck use fairly simple spelling checkers, which might be user-customizable, but not author-customizable.
Here’s a possible scenario for a workaround: Use <div contenteditable> instead of <textarea> (so that the content can contain markup), and add event handlers that react to user input and process check whether the word entered is in your list of terms, and if it is, wrap it inside <span spellcheck=false>.
Im not sure on how to explain this but, what I want to know is there if there is any way to "lock" just one part of an text area in a html form. Example:
<input name="example" type="text" id="example" valeu="__this part cant be modified__, and here user insert aditional info" />
And then I get this field value as like: "this part cant be modified + what user typed"
Thank you
I don't think you can, your best bet would probably to just append your default value to their input upon submission.
No, there isn’t, not for input elements, not for textarea elements.
You can however create an impression of such behavior, e.g. having some text and an input element on the same line and setting their style as similar as possible (setting all text, background, and border properties). Of course, the form data would still consist of the input value. And prepending the fixed text to it in client-side JavaScript would be possible but normally pointless, since it would be inherently unreliable and since you can simply make the form handler behave as if it got that string (i.e., make it have it as built-in data).
To get additional ID information (like the page name) about the page when it's submitted.
Thanks
No, it shouldn't matter, as long as it is within the form.
It must be within the form. It doesn't matter where, unless you do something like this:
<form>
<input type="text" name="data[]" value="value1" />
<input type="hidden" name="data[]" value="value2" />
<input type="text" name="data[]" value="value3" />
</form>
In this case the data array isn't associative, so the position of the elements does matter.
Similarily, if you'd traverse your POST / GET data with a foreach loop without paying attention to the array keys, you could get problems (but if you have an associative array, you should use the associations, especially in user input).
I mention these things just to make the answer more complete. In most cases the simple answer applies - position of hidden fields does not matter.
No. Values from an HTML form are mostly treated as being an associative array. To that end, the order in which the elements appear are of hardly any concern.
It matters in the sense that the order of data fields in submitted form data normally corresponds to the order of fields in HTML markup. You can see this easily if you use the default method (GET), so that the fields will appear in the URL.
There is no requirement on this; it is just how browsers tend to behave. Any robust form data processing does not count on any particular order.
I have sometimes observed browser rendering oddities that seemed to depend on the placement of hidden fields. It sounds weird, because hidden fields should not affect rendering.