We Keep Coding

Input fields needing mouse click

I'm building a simple HTML page, and I have an input field followed by a search button; this is the code:
<input type="text" id="sfield" placeholder="Write something">
<button id="search">Search!</button>
I'm currently writing the javascript to assign some actions to the button and to the input field, when I thought that it would be a good idea to add a feature that needs the cursor to be on the field for the search to start. I'll explain it better: if someone wants to search something, it will appear just like a normal input field and work like that. However, if someone tries to launch a script for auto-submitting the form, it'll act like no input was inserted.
For example, if someone tries to inject this script:
document.getElementById('sfield').value="Some stuff";
document.getElementById('search').click();
the search would start but the "Some stuff" string wouldn't be saved, as if the user clicked the search button without writing in the search field. Furthermore, adding the line
document.getElementById('sfield').focus();
should also do nothing, so that the only way to put the cursor in the field would be a manual action by the user.
I'm wondering if it's possible to make such thing; I already managed to get the search field blank with EventListener, but I don't have a clue about making the script discern whether the user put the cursor on the field or not.
I'd prefer not using JQuery but it's ok also with it. Any idea would be greatly accepted. Thanks.

In that case, the program needs to retain state. I'd do it like this...
http://jsbin.com/hopicucuyi/edit?js,console,output
<input type="text" id="sfield" placeholder="Write something" data-validated = "false">
<button id="search">Search!</button>
<script>
const inputField = document.getElementById('sfield');
const searchButton = document.getElementById('search');
inputField.onfocus = () => {
inputField.setAttribute("data-validated", "true")
}
searchButton.onclick = () => {
const isValidated = inputField.getAttribute("data-validated");
console.log('Is Validated: ' + isValidated);
}
</script>

Generally neither of these solutions will stop a bot that uses a browser (which is a bot that runs javascript). There is no 100% solution, but there are stronger solutions than checking if something has focus or not. Remember the javascript environment is completely controllable from the browser side of things. For instance, all I would have to do to get past your security is change the state of the input in question to data-validated="true" and your security falls apart.
However, the browser vendors have taken this possibility into account and provide you with a little-known solution. Look at the event data coming from a mouse click or a keystroke. This event data can be generated. It used to be easier in the older browsers to spoof an event just by using new Event(), but now modern browsers use specific events for keyboard and mouse. The part that makes spoofing these very hard is that in the event there are properties that are read-only. More specifically there is an event property called "trusted" that cannot be set by javascript. If you spoof a MouseEvent or KeyboardEvent, the "trusted" property is set to false, but if you use the actual mouse or keyboard "trusted" is set to true.
Info on the isTrusted property here: https://developer.mozilla.org/en-US/docs/Web/API/Event/isTrusted
Note: this is also not 100% as the bot can run a keyboard/mouse macro that creates genuine "trusted" events. However, it does make the system much harder to crack as many people dont know about this security trick, and most bots will not have mouse/keyboard control built in. If you encounter a bot that uses mouse/keyboard, you've reduced the security playing-field and further analysis of the events and interface usage can take place.
If you combine this method with other methods like browser fingerprinting etc. it makes your overall anti-bot security that much stronger and discourages many more possible bots.
Edit: Don't just use this method and others, obfuscate your code so that any attacker will have to take the time to deobfuscate and wade through a bunch of poorly labeled functions and encrypted strings if they want to see how your security works.

Adding WAI-ARIA attributes with JS

At work I have been optimizing one of the sites I have helped developed for one of our clients (I can't say who) for be ADA compliant using WAI-ARIA attributes. I've been wondering if it wouldn't just be easier to create a small JS library that does things like add "role=button" to anchors I've styled to look like a button, add "tabindex=0" to elements I want to be "tabable" etc.
I was wondering if it is a good practice to add in WAI-ARIA attributes with JS or is that frowned upon. Some accessibility evaluation tools won't run the page's JS when evaluating it so it will think these are pain points when they are really not.

this may be helpful Add ARIA inline or via script?
Also note that if you use role=button it needs to act like a button (i.e. provide appropriate keyboard interaction behaviour)

I think in the interests of progressive enhancement, it might be best to put all your ARIA inline and not rely on script to add it.
If there are other script errors, if the connection gets dropped, if there is a blocking script in the way, etc., then your library may not come into play and your efforts at remediation will be lost.
I'd also like to build on what Steve said above about using role=button on a link. Especially when you consider that a visual style (to make a link look like a button) is meaningless to a screen reader use (for whom many ARIA roles benefit). I addressed other keyboard interaction gotchas in more detail in another SO answer, but here is one to consider when you try to turn a link into a button:
A hyperlink (<a href>) can be fired by pressing the enter key. But a true <button> can be fired by pressing the enter key or the space bar. When a hyperlink has focus and the user presses the space bar, the page will scroll one screenful. Users of some assistive technology will expect behavior based on the element used.
Also, I caution against putting a tabindex=0 an an element you want to be tabbable unless it is an interactive element. For example, do not put it on a heading (<h#>) just so someone can tab to it as screen readers (for example) already allow navigation by headings.

Create new type of input type

I was wondering if it was possible to create a new kind of input, as opposed to the normal number, text, etc. For example, I am making a forest fire model for my internship, and one thing I am trying to add is wind. I was wondering if I could do something like <input type='wind'/> and define what that would look like and how it would behave. I could do it some other ways, but I also just wanted to know if it would be possible to do something like this.
Thanks

The list of available input types is here: http://www.w3.org/community/webed/wiki/HTML/Elements/input
The type attribute is enumerated (i.e. you can only use those values) with default of text.
However there is nothing stopping you from adding class="wind" or the like to the input and using JavaScript to alter the behavior of all such inputs.

In practice, nothing really prevents you from writing <input type='wind'/> in HTML and styling and scripting it, e.g. (using jQuery) $('input[type=wind]').click(handler). It won’t be valid HTML, but this just means it does no conform to specifications; browsers don’t care about that. They will treat the element as a normal text input box, because they do not recognize the attribute value and will therefore use the default type='text'. This means that the DOM node has text as the value of the type property, but its attributes array (well, array-like object) still has wind as the value for type
So it would be like using <input class='wind'>, as suggested by #ExplosionPills, just using a different attribute name, and with extra complications. Either way, the fallback (in situations where scripting is disabled) is an ordinary text input box.
If the fallback is not relevant (the page would not work at all without JavaScript), it would be simplest to use a span or div element with class and implement it the way you like. Then you would not have to deal with the default rendering and behavior of normal text input box; it can be a bit tricky to wipe them out in favor of your own rendering and functionality.

Open dropdown from javascript

I there ANY way in javascript that we could trigger a select element (dropdown list) to open (i.e. drop)?
After searching alot on the web, it seems the answer to this question is no, but I decided to give it a try on here as well.
I know there are some css tricks that you can set the opacity of your select to 0 and place it over other elements to receive click, but that is not useful in my case.
Also there are tons of js APIs that bring the same dropdown functionality to browsers but they are not good solutions for me because then on mobile browsers (where the OS has a totally different mobile-friendly popup for dropdowns) the functionality would be seriously poor.
[Note] I specifically need to do this in an android browser, in case there is a hack for this special case.
Thanks.

You could assign a value to the size attribute. This causes the number of visible options to change. This simulates a "drop-down". Add position:relative to a container, and position:absolute to the select to prevent the element from pushing other elements away.
Demo: http://jsfiddle.net/HQwXj/

Partially select checkbox with javascript

Is there a way using Javascript and HTML(5) to make a checkbox be partially selected, like the checkboxes in a program installation menu when you select only some of the sub options?

HTML5 defines the indeterminate boolean property.
I've tested it only in the latest Safari, Chrome, and Firefox. They all support the indeterminate state.
Example: http://jsfiddle.net/5tpXc/
Edit: Note that this wont work with older browsers and maybe not with current versions of IE. You'd need to rely on hacks as described in other answers here if you want to support all browsers.

HTML checkboxes (that is, input elements of type checkbox) don't have a third state (partially checked). So no, there is no direct way to do this.
What you'd probably have to do is make a custom checkbox-looking image and bind to its various events (click, for example) to store its current "state" in a hidden form field via JavaScript. You may run into a number of issues with this approach, though.
For example, keyboard navigation of the form may not be possible for this particular element. (Can one tab to an image and send it keyboard events? I'm not sure.)
Additionally, you could try manipulating custom attributes on a checkbox element via JavaScript to store a third state. But the rendering of the element itself has no visual indicator of something like that. You could probably manipulate its style (color, background color, border color, etc.) to try to mimic the visual behavior. But you may not be able to achieve the exact visual style that you're using for reference.
It's certainly an interesting prospect, and I'm intrigued enough that I may try to implement something like this in the near future. But with a native checkbox element, it's not possible. It has only two states.
Edit: Refer to #kassens' answer for doing this in HTML5. If you're limited to previous versions of HTML for any reason, then it's going to have to be a hack as described here. But if you can rely on users supporting HTML5, then it looks like native support is there.

Nope. You would have to make a custom checkbox graphic and fake it.
Edit: Refer to #Kassen's answer for a way to have partially checked boxes in HTML5-compliant browsers.