I have few controls on a form. I have to set the tabIndex in an order that is not natural to their order of creation on HTML. There is a button at the fag end and the tabIndex is not getting set (it's never focussed) only on this element.
<button id="btnSave" tabindex = "86" title='click here'>Submit Here</button>
What may be the reasons??
Appreciate your help.
Tabindex Best Practices
Commonly, I would suggest that do not set Tabindex with any incremental values because for any fields/components in your web page if we follow this rule then we need to maintain the same tabindex incremental values for upcoming fields too and also we mostly show/hide the fields/components based on some conditions so that time the tab index will not work consistently.
I strongly suggest the best practice is that we should not use Tabindex Greater than 0 and use only Tabindex -1 and 0 wherever required
tabindex="-1"
Setting tabindex="-1" allows you to set an element’s focus with the script, but does not put it in the tab order of the page. This is handy when you need to move focus to something you have updated via script or outside of user action.
tabindex="0"
Setting tabindex="0" will take an element and make it focusable. It doesn’t set the element’s position in the tab order, it just allows a user to focus the element in the order determined by its location with the DOM.
tabindex="1" (or any value > 0)
Do not set a tabindex="1" or any value greater than zero (or any positive value).
If you set tabindex only on the button element, then this element will be the first in navigation, which means that you don’t get to it from the last input field directly (but only via some browser-dependent items in the browser’s own user interface, such as search box and address box). See the HTML 4.01 spec on tabindex.
If you have set tabindex on other fields as well, please post a demo that exhibits the behavior—in a simple test on several browsers, tabindex worked fine when set on all fields.
try :
<input type="button" value="Sumit here" tabindex="90" />
check that , your index will be counted form zero under it's parrent! index 90 is too much for a html.
Related
Using the Siteimprove extension v. 126 for Chrome the following HTML snippets are all reporting an issue "Input field has no description 1.3.1"
It seems like no description should be needed as the aria-hidden attribute should completely remove the element as far as the accessibility API is concerned. Likewise the tabindex=-1 attribute value indicates this element is not intended for interaction nor presentation.
Moreover, the extension reports this as an issue even after adding role="none" per the following doc, which is the first cross-referenced solution in the tool:
ARIA4: Using a WAI-ARIA role to expose the role of a user interface component
<input aria-hidden="true" tabindex="-1"
class="MuiSelect-nativeInput"
value="SORTING_OPTIONS_ENDDATE"
style="">
<input aria-hidden="true" tabindex="-1"
class="MuiSelect-nativeInput" role="none"
value="SORTING_OPTIONS_ENDDATE"
style="">
Note: this hidden input element is generated as part of a <Select /> component via Material UI. It's used to hold the selected value
Yes, this is a false positive.
It likely flags this as an issue as it cannot know whether you intend to "unhide" the <select> in the future, at which point it would be inaccessible due to the lack of label.
You can safely ignore this error as the input is never designed to be accessed so the tabindex and aria-hidden states will never change.
One thing I did notice though is they set the opacity to 0 instead of hiding the input, not entirely sure why that is but it may be the other reason it complains as technically anything with 0 opacity could still be accessed by some older screen readers that do not honour aria-hidden. If you could change that to display: none it would be more robust (this needs to be added by JS as otherwise if you set this in the CSS and the JS fails the whole input would be hidden).
I have a paper-textarea inside of a drawer. When I go to the page the paper-textarea autofocuses, which opens the drawer. I've tried to get rid of the focus by trying autofocus="false" and autofocus="off", but neither have worked for me. Any help would be appreciated.
<paper-textarea id="descriptionInput" label="Description" invalid="{{descriptionError}}" error-message="please enter a valid description" value="{{description}}" autofocus="false"></paper-textarea>
Update: Another way to go about this might be to remove the focus programatically, but I've tried this.$.descriptionInput.blur() inside of the attached function, and it's not working either.
This is due to iron-autogrow-textarea's autofocus property default value being set to "off". The autofocus attribute is active if it exists, the only way to disable it is to remove it all together (ie, autofocus="disabled" or autofocus="off" will still autofocus the tag).
I've created a pull request and this will hopefully be fixed in future versions.
For the time being, you can create a disabled input tag before the textarea with an autofocus attribute and visibility set to hidden and this will prevent the textarea from gaining focus.
<input disabled autofocus style="visibilty: hidden">
I ran into an issue with the answer by Kevin Ashcraft, on Safari it was not working.
Here is another option, since the issue it due to the presence of the autofocus attribute, you need to remove that attribute. So I have polymer element and in there I have the following
ready:function(){
var list = Polymer.dom(this.root).querySelectorAll('iron-autogrow-textarea');
list.forEach(function (e) {
e.textarea.removeAttribute("autofocus")
});
}
This scans my dialog, finds all iron-autogrow-textarea and removes the attribute from them... you can change the selector to get only the ones you need.
Update this has been fixed as of latest version Should mention this has been fixed in latest version of https://github.com/PolymerElements/iron-autogrow-textarea/releases/tag/v1.0.8
I know about HTML5's autofocus attribute, but AFAIK it only applies to input tags.
Is there a way to set the focus automatically (and preferably without JS) on, say, a scrollable div with text, so that the viewer can immediately scroll using keyboard ? Or would it be browser-specific ?
I can't find useful ressources online so I'm wondering if "focus" if the right word.
<div tabindex='0'>
this will receive the focus immediately
</div>
tabindex="0"
The tabindex value can allow for some interesting behaviour.
If given a value of "-1", the element can't be tabbed to but focus
can be given to the element programmatically (using element.focus()).
If given a value of 0, the element can be focused via the keyboard
and falls into the tabbing flow of the document.
Values greater than 0 create a priority level with 1 being the most
important.
For more info you can look at the following link http://snook.ca/archives/accessibility_and_usability/elements_focusable_with_tabindex
UPDATE
The other option is to try something like this.
Add the following code to the body tag, substituting the form and field names for your own:
<body OnLoad="document.myform.mytextfield.focus();">
<form name="myform">
<input type="text" name="mytextfield">
<button type="button" onclick="javascript:alert('testing')" name="myButton">Click Me!</button>
</form>
In my AngularJS project I have an account details page where you can change your personal account information. This page allows for multiple phone numbers and e-mailaddresses to be supplied. Using mouse input (or tabbing to buttons and pressing them with space bar) works perfectly, however I'd like to add the convenience of the enter key pressing the 'logical' buttons.
My form looks like (accidentally forgot to translate a few items):
A simplified version of the HTML for the form can be found on PasteBin, I've mainly removed the directives for managing the lists.
All buttons are <button> elements except for the cancel button which an <a> to the previous page, and the submit button is <button type="submit">.
When selecting any text box and pressing enter, the first (non-disabled) <button> element is 'clicked'. Meaning if I would change the last name, hit enter, the first phone number would be removed.
When you're in a new entry of phone numbers or e-mailaddresses (the row with the green + button) it should click that button, and if it's disabled do nothing.
When you're in any other text box on the form it should hit the save button, and also if the save button's disabled, do nothing.
Both buttons will be disabled based on form validation.
There'd be no trouble in changing the type of a button from button to submit if that'd help.
I would preferably have an all HTML solution, using just semantics, but I doubt that's really possible. So the logical alternative would be to use an AngularJS directive.
Please do not provide a jQuery or plain JavaScript solution relying on IDs or something like that. I don't want to hack my way around AngularJS, rather embrace it.
In the meantime I've worked on a directive that allows me to declare what I've called 'submit scopes'.
In essence you have actions (inputs) and targets (buttons), they're bound through a service by a key you can assign in the template. To avoid keys from clashing and from simple annoying work you can create a submit-scope which will cause it's children to prepend a unique key to the value they're accessing.
Within a submit-scope you can still override an action to use a global key instead by setting the attribute global-submit="true".
Example code:
<div submit-scope>
<input type="text" submit-action />
<button type="button" submit-target>Pressing enter in the above field will click this button.</button>
</div>
You can view the entire source code and a slightly larger example on Plnkr.
I just tried to replace
<button>Cancel</button>
with
<input type="button" value="Cancel">
and it seems to work correctly...
I have a bunch of optional "write-in" values for a survey I'm working on.
These are basically a radio button with a textbox within the answer field - the idea being that you would toggle the button and write something into the box.
What I'd like to do is have the radio button toggled whenever a user clicks in the text field - this seems like a use-case that makes a lot of sense.
Doing this:
<input type="radio" id="radiobutton"><label for="radiobutton">Other: <input type="text" id="radiobutton_other"></label>
works fine in Chrome (and I am guessing, other WebKit browsers as well), but there are weird selection issues in Firefox, so I'm assuming its a non-standard practice that I should stay away from.
Is there a way to replicate this functionality without using JavaScript? I have an onclick function that will work, but we're trying to make our site usable for people who might have NoScript-type stuff running.
Putting an input inside a label actually has a slightly different meaning. It doesn't make the input itself a label, it implicitly associates the label with the input in the same way as if they were linked by a for/id.
However, this only happens when the label doesn't already have a for attribute to override that (see HTML4 s17.9: “When present, the value of this attribute must be the same as the value of the id attribute of some other control in the same document. When absent, the label being defined is associated with the element's contents.”). It is unclear according to spec what should happen when both containment and for are present.
(And also it doesn't work in IE, which makes the point moot in practical terms.)
No, you'll need some scripting for this.
<input type="radio" id="radiobutton">
<label for="radiobutton_other">Other:</label>
<input type="text" id="radiobutton_other">
<script type="text/javascript">
var other= document.getElementById('radiobutton_other');
other.onchange=other.onkeyup= function() {
if (this.value!=='')
document.getElementById('radiobutton').checked= true;
};
</script>
It (an input inside a label) validates just fine as HTML 4.01. One potential issue I can see with your code is that both radio elements have the same ID in your example. Element IDs must be unique in HTML and XHTML documents and you should use the name attribute instead to identify a radio group.
If you are still having trouble after changing this, you will have to move the input outside of the <label> element and use scripting.