Given that
The Browser has a page loaded with an exisitng field (call it ef) with tabindex=1,
Two new fields are inserted via bookmarklet (nf1 and nf2)
first time (incorrect behavior)
When the mouse is clicked on nf1 followed by a tab
the focus acts as if the tab was entered from field ef and goes to a place
other than nf2.
second time (correct behavior)
Now, if the same actions were repeated i.e. mouse clicked on nf1 followed
by a tab the focus goes to nf2.
One way I've ensured that the focus goes to nf2 from nf1 the first time around is
to hardcode tabindex values to fields nf1 and nf2. But this is suboptimal as one
needs to make sure that there are no tabindex conflicts i.e. if there are two fields
where tabindex=1 than focus goes from one to the other instead of to the
proximate tabindex=2
So, what can be done to ensure that the behaviour that manifests
on the second time manifests on the first time.
ps: jquery is available on the page
I rarely use the tabindex attribute so I haven't encountered this property. However, I have written interfaces with similar functionality (fields are added dynamically) with normal tab behavior. I would suggest just removing the tabindex attribute and see if that fixes the problem.
Related
My job is to order diagnostic tests for patients and I need to write 6-7 characters value for each diagnostic test. I have 24 different values and I need to fill it many thousands of times. I am thinking to create 24 different scripts with Tampermonkey to speed up my job by clicking on the script box.
So the thing is that I need to fill this
box. Here are the input id and everything of that box in the console. Then I type the value manually, I get popup list which updates every time I type one character (same principle as google or youtube search box), here is the popup list after I type a value and if I want that diagnostic test, I need to click on it from the popup list, I cannot just simply click enter. So this is the code I have to fill the box by a value:
document.body.appendChild(element)
element.addEventListener('click', function(){
document.querySelector("input#generic_test_order_search.ui-autocomplete-input").value = '15002 '
})
The script fills the value, but the popup list doesn't appear and I need to click on the box, delete one character and write it again to get a list and then to choose a diagnostic test from it. Still, time-consuming.
I wonder, is it possible to make a script to add automatically a diagnostic test from the list like this example? If no, is it somehow possible to make that popup list would appear and I won't need to click on the box, delete one character and write it again? At least, could I make that the box is clicked after a value has been filled? I tried this code but doesn't work: document.querySelector("input#generic_test_order_search.ui-autocomplete-input").click()
Please help me to make it as automatic as possible, which would save me hundreds of hours in the long-term.
1 - As for the second part of the question. Picture 4.
It is pretty simple to make an auto-fill for the dropping parametres, we just might need the html-code of the elements.
For example,
document.getElementsByTagName('input')[0].click(); clicks the first input checkbox from the first input
document.getElementsByTagName('select')[0].selectedIndex = 1; selects the second value from the first select
document.getElementsByTagName('button')[0].click();clicks the first button
To make it more precise you might use class at first, at then tag:
document.getElementsByClassName('testClassDependingOnExistingClasses')[0].getElementsByTagName('button')[0].click(); for example.
Anything you do manually on a page like that can be done automatically with JS.
2 - As for the first part of the question. Picture 2.
Here is the part of the answer.
How to trigger arrow down press in js?
Maybe this code might help, but not enough information, since no data on html-code of the dropped elements.
document.getElementById('generic_test_order_search').clildren[0].click();
I have a web page that interacts with two servlets and consists therefore of two forms. First form sends data to servlet one to prepare some data to fill drop down menus in the second form depending on the selection. Second form holds four drop down menus which represent different attributes of an object (and interacts with servlet two).
Not all combinations of selections from the drop down menus are valid in step two, therefore I want to show some texts beneath the drop downs to make the user aware of invalid combinations. I used onchange="checkValues()" to generate these texts, which works fine per se. (onsubmit() later prevents invalid combinations from submitting)
The Problem: Unfortunately, the preset combination is an invalid one. I want to show the texts also, when second form is loaded for the first time. I tried to use onsubmit="checkValues()" in form one, but it has no influence on the texts as the drop down menus (and therefore the values to be checked) are loaded after the submit.
Which event would be more appropriate to cover onchange and the first combination after initialization of the drop downs?
Use an other preset combination is not an option.
The best way to do this would be to wrap your site in a single div and attach a single event listener to that div.
Then you can listen to everything without having to make a ton of different event listeners and slowing down your site. You can tell where it came from by evaluating the ID as long as you set one, of course
I have multiple tabs and each tab has its own iframe. During the first rendering tab 1's input text field has focus using JQuery. After switching to tab 2 and coming back on tab 1 does not put back focus on the input field from tab 1.
As per my understanding focus will be set during DOM construction phase and will be rendered by the browser as it is. But on repaint no DOM re-construction happens so JQuery can not put back focus on the input field.
function clearSearchTxtInput(resetResults) {
$("#searchTxt").val('');
$("#searchTxt").focus();
}
Above code is called onload.
Is there a non-blocking way to put back focus on the input field?
I'm pretty sure I can't do what I'm actually asking, but am wondering if there is some sort of workaround for the issue.
I have a page that has a drop down SELECT form element with several options. If one particular option (in this case, the first item) is selected, we show additional content (via jQuery). This works fine.
What happens, though, is that if I select item 2, the additional content disappears, as it should. I then go to a different page and then hit BACK. A that point, the page properly has kept that additional content hidden (as it was the last state) but the SELECT menu has been reset to the first item. I then have to click the SELECT, pick a different option, then select it again picking the first option, which finally brings the additional content back.
I can't trigger Javascript from what I can tell on a cached page (or is there a way?) Any other clever options?
One option I've come up with is to apply some sort of mouseover action to the area that houses the SELECT menu that does a quick 'reset elements' check. This seems a bit hacky and, of course, will produce an odd screen redraw unexpectedly for people.
You can record that the user action has taken place and re-execute it using JavaScript. You can store it in a cookie, then check for it on page load and reset the elements you want.
If I have a form that is the main part of a page's content, will assigning focus to the first form field via JavaScript on page load have any negative effects on accessibility?
The short answer is no it doesn't make things inaccessible but it can make it confusing. The longer answer follows. Will your users know that there going to a page with a form, and does there need to be any descriptive text you should read before filling out the form? I'm a screen reader user and it can be annoying having focused put in random fields. It's clear why your focus winds up in the Google search box so that doesn't bother me. If my focus were automatically placed in the answer edit field every time I viewed a question on Stackoverflow I would be annoyed since I'd have to force my screen reader to navigate away from the form field and to the top of the page.
It might a bit, if we've got a keyboard user (either using a screen-reader, or just a habitual keyboard user) who's expecting to be navigating the links at the top of the page on first Tab press. For screen readers, you could also consider adding WAI-ARIA to add directions if users who don't expect to be dumped into the middle of a form.
If it's much more likely that the user's going to be wanting to type in the field straight away, then I think the autofocus is worth it. But for the reason above I wouldn't use it on every page with an input field.
If you do autofocus, make sure to do it right away, in a script as soon as possible following the input element, or in future using the HTML5 autofocus attribute. Don't do it as late as window.onload. It's annoying to have clicked the focus elsewhere only to have the document belatedly finish loading and steal the focus onto another element as you type.
A lot of sites will do this, google is a good example, the only issue is when you are typing something into the address bar, or into the search input in your browser, the action of focusing the form field tends to steal focus from where you are typing. It's a small nuisance.
will assigning focus to the first form field via JavaScript on page load have any negative effects on accessibility?
I can't think of any. In between fields might irritate whatever assistive software a user might be running, but the first field - hardly. I have no experience with braille and similar clients.
Seeing as even Google do it on their front page, I don't think it can be that big a deal either way.
Quoting MDN autofocus -> accessibility considerations (retrieved 9/28/2022):
Automatically focusing a form control can confuse visually-impaired people using screen-reading technology and people with cognitive impairments. When autofocus is assigned, screen-readers "teleport" their user to the form control without warning them beforehand.
Use careful consideration for accessibility when applying the autofocus attribute. Automatically focusing on a control can cause the page to scroll on load. The focus can also cause dynamic keyboards to display on some touch devices. While a screen reader will announce the label of the form control receiving focus, the screen reader will not announce anything before the label, and the sighted user on a small device will equally miss the context created by the preceding content.
To add some practical examples, at the time of writing, https://www.google.com autofocuses on the search box, while Wikipedia and Amazon don't. If typing into a search box is the sole purpose of the page and the risk of confusion is low, then it's worth considering autofocusing on it. Otherwise, probably skip autofocusing.
I wouldn't say so, fragments are an ingredient of HTTP and they set the focus of an *html page..
I wouldn't say so. A screenreader will probably not even notice this since it doesn't interpret the JavaScript on the page.
Another user which has a "normal" browser will get the advantage of having the cursor already at the right place which facilitates the navigation by using just the keyboard.