I've run into this weird problem while developing an app for KaiOS using Svelte3. When the input field is set to type number the backspace doesn't work. At all.
<input
bind:this={ref}
bind:value
type="number" />
When it's set to "text" it works perfectly fine. Backspace removes characters as it's pressed. Backspace in this case is the "Call End" button on KaiOS devices. I don't know if this is a KaiOS problem or a Svelte3 problem.
I'm not very skilled in WebDev technologies, so I don't know what else to try. Some additional info that might point towards something.
I have one listener globally
window.addEventListener("keydown", onKeyDown, true);
Which is attached in my KeyListener that I use to control my app navigation through selectable elements. This also doesn't fire when the backspace is pressed while an input field has focus. Things I have tried.
Assign functions to onkeydown, onkeyup, onkeypressed (none of them fire the backspace call)
Removed the event listener that I mention above, changes nothing.
Assign the functions in a non-svelte way as pure JS inline functions.
On KaiOS only onkeydown fires, incase that might give any of web dev JS experts a hint. I don't know what else to do. Any suggestions would be appreciated.
We have no idea why this works but setting the input type to "tel" makes the backspace key fire and the input field to act as normal while still allowing numbers only.
To handle events on window you can use <svelte:window>. For example:
<svelte:window on:keypress={handleKeypress}/>
But if all you want to do is monitor keypresses on an input you can do it on the <input> directly with <input on:keypress={...}/>.
Here's an example of handling keypress on an input: https://svelte.dev/repl/bfd93b0799c142979eefa1f2558bfb96?version=3.20.1
Related
I'm struggling to implement an accessible input with increment/decrement behaviors, using an <input type="text" role="spinbutton" /> element in HTML/JavaScript. But it seems like with VoiceOver there are custom (fake?) input events for incrementing/decrementing which change the input's value in unexpected ways.
How do I make sure a user navigating the page with assistive technology doesn't get bad guidance from VoiceOver while trying to interact with my widget?
For example, using super trimmed-down code like this:
function logIt(...args) {
document.getElementById('output').appendChild(
document.createTextNode(`${args.join(', ')}\n`)
);
}
document.getElementById("myInput").addEventListener('input', (e) => {
debugger;
logIt(e.type, e.data, String(e));
e.target.setAttribute('aria-valuenow', e.target.value);
}, false);
document.getElementById("myInput").addEventListener('keydown', (e) => {
logIt(e.type, e.data, String(e));
}, false);
<input
id="myInput"
type="text"
role="spinbutton"
autocomplete="off"
defaultValue="1"
aria-valuenow="1"
aria-valuemin="0"
aria-valuemax="100"
/>
</div>
<pre id="output"></pre>
... VoiceOver will describe the input as a "stepper" and give instructions on how to increment/decrement using the keyboard. But using those keyboard commands results in some weird math, as seen in this screen cap:
You can also see (from the "logging" in the screen cap) that when the user types input, an InputEvent is triggered with event.type being input - but when the VoiceOver keyboard command for increment/decrement is used, a base-type Event is triggered with event.type again set to input.
And this doesn't seem to be unique to my implementations of role="spinbutton". The jQuery UI spinner doesn't behave well when incremented/decremented using VoiceOver keyboard commands:
I even tried some of the w3c's examples for role="spinbutton":
The font size widget on https://www.w3.org/TR/wai-aria-practices/examples/toolbar/toolbar.html
The date picker on https://www.w3.org/TR/wai-aria-practices/examples/spinbutton/datepicker-spinbuttons.html
... and even though VoiceOver described each of those UI controls as a "stepper" and gave instructions on how to increment/decrement them using the keyboard, those instructions didn't seem to work. Other keyboard behaviors worked - but the ones VoiceOver suggests don't.
What can I do to make sure that role="spinbutton" markup works correctly with VoiceOver's increment/decrement keyboard commands?
I don't believe role="spinbutton" is compatible with VoiceOver as it seems that VoiceOver hijacks the keydown events when using the VoiceOver cursor. So when focusing on an element with role="spinbutton" VoiceOver instructs the user to use "Control-Option DownArrow" or "Control-Option UpArrow" to decrement or increment the value. When those keys are pressed the event does not make it to any JavaScript keyDown event handler so we can't detect that those keys have been pressed and can't implement the actual incrementing or decrementing of the value. So I'm not sure there is any way to use role="spinbutton" and make it work with VoiceOver. The user will be given instructions that don't work and will be confusing.
As a workaround for an application that I'm working on I've implemented the key handling behavior described in the WAI ARIA authoring practices for spinbutton but I have not added role="spinbutton" or the other aria attributes listed. Instead, I've added aria-live="assertive" so that when the value is changed either by keyboard or clicking the increment/decrement buttons the user hears the new value. Additionally, I've added some visually hidden text that instructs the user on how to increment/decrement the value with the keyboard and associated that with the input using aria-describedby.
I just visited w3's spinbutton example, and it seems to be keyboard operable in VoiceOver Mac (OS Version 10.15.1 with Safari). You can inspect the code they have used, and get inspiration there.
However, the w3 spinbutton example does not announce the current value when the stepper receives focus, or the changes as you step up and down. I tried Medium and High verbosity settings with no luck.
This failure to announce the value (either aria-valuetext or aria-valuenow or perhaps both) seems to be a bug on Apple's side, so I just reported it. Good catch.
This could perhaps be hacked-in with an aria-live region, but you might end up with duplicate announcements on other browser/screen reader combinations.
I'm developing a iOS browser application(html + javascript), and there's something wrong with the fixed-bottom(from twitter bootstrap) feature when virtual keyboard is pop up, so I want to disable it before virtual keyboard is pop up. Is there any event can do that ?
I've tried focus event when focusing an input field, but it's too late, the fixed bottom element will be already affect by virtual keyboard, Any solution ?
Have you tried on checking mousedown / touchstart which occurs before the focus? Just check whether the event.target.nodeName.toLowerCase() is "input" or "textarea" when it's dispatched.
I've also created https://github.com/zvona/Servant.js, which is an initial version of advanced keyboard handling. It supports "keyboardshow" but not "beforekeyboardshow". I'll check whether it can be implemented and to help in your case.
.
In Objective C you would register for one of the keyboard notifications. The one you would need is called UIKeyboardWillShowNotification. I don't know what literal string that translates to. I'd have to write a bit of code in order to figure out the string literal.
I don't know if you can register for notifications in Javascript.
Please check onresize event of body element in your html.
if you are using jquery you can use this plugin.
If I use xss, what's the difference between typing in ALERT('DSSA');, or just paste it to a search textfield? In a site, typing works, and makes the alert, but if I just paste it, than it doesn't. To prevent the question, I don't want to hack any site, I'm just interested in network security.
thanks for the answer
This will be because the programmer who built the website is lazy and hasn't listened for the onpaste event.
Typing fires the onkeydown, onkeypress and onkeyup events, and are the standard events to consider when watching for user input.
It would seem those are the only events the programmer has listened for (which makes this irrelevant of network security).
If this is not the case, then he'll be using two different event handlers for the events; one which escapes the input, and in the other he's forgotten.
I may not have understood the question properly.
Typing triggers keyUp, keyDown and keyPress events on the element. If the codes are programmed to capture them only, then only those events will be captured.
Pasting can be done using keyboards, mouse and browser options. So this depends on which events you are listening too. There is a separate event called onpaste which will ease everything.
What I mean is, lets say my code is written to capture the pasting my pressing "Ctrl" + "v" only, but if mouse and browser options are used to paste on the
element, then it is configured to capture mouse events also, it cannot
be captured.
In the form that I am developing, I need to implement a screen rule which is - Clear button is greyed out until atleast one input field is not null. For this, I have added a js function which checks all input fields and gets called during "onmousemove" event. I have added this to body tag.
I does work, but I suspect if this is the best way it can be done.
Are there better ways to implement this?
No, it's not a good idea to bind to onmousemove, especially on body — that means every time someone moves their mouse, your function is called. What you really want is to bind to blur (navigates away from an input field) or change (the value of a field is changed – be careful with IE). If you really want to get granular, you can check one of the keyboard events — keyup, keydown, keypress. And you should bind these events to the input fields themselves.
I'm working a web page where I'd like to run some JavaScript code when a user alters text in a given input field, but I can't figure out which event to trap (assuming one exists) that would give me the behavior I'm looking for. onFocus happens too soon -- if the user selects the field but doesn't change any text, I don't want anything to happen. But onChange is too late -- I'd like the JavaScript to fire as soon as the user starts typing, not when the user is done typing and clicks something else. How could I accomplish this?
onkeydown (although it wouldn't work for pasted data, where onchange is probably better).
There are a couple events that can help you:
onKeydown (fired when a key is pressed down)
onKeyup (fired when a key is released)
onKeypress (fired when a key is pressed and then released)
keydown / keyup / keypress?