I want to control the keyboard displayed when using WKWebView.
I have the following swift code starting the webview:
let webView = WKWebView(frame: self.view.bounds, configuration: configuration)
webView.navigationDelegate = self
It will load html that looks like this:
<!DOCTYPE html>
<html>
<head>
<title>Test</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
</head>
<body>
<div class="inputElement textFieldInput">
<input type="text" id="textField" value="" data-clear-btn="true"/>
</div>
</body>
</html>
Normally the keyboard is controlled by the type option on the input field. "num" for a numeric keyboard and "text" for a alphanumeric keyboard. But I want to have more control.
I have done enough research to know that this can not be accomplished by using the option on the text box. I am fully expecting to write modify the code that opens the webview.
How can I modify the swift code to allow me to do this?
Ideally, I could define multiple keyboards and allow the html code to control them something like this: <input type='customkb1'> and <input type='customkb2'>
My immediate need is to disable the emojis button on the keyboard but I would like a generic solution as I will be able to really improve the usability of my application if I can define a keyboard specific to what the user is inputting.
Here is what we have found so far:
That is trick I know and use for native part of the application:
https://stackoverflow.com/a/25861718/1885345
But it doesn't work for webViews
That is the way to specify keyboard from WKWebView:
https://stackoverflow.com/a/28533488/1885345
But it doesn't have the option to set keyboard without emojis
That is what I use to disable third-party keyboards:
https://stackoverflow.com/a/34863426/1885345
Nice challenge! So far I have tested it on an iPad and got it half-working (with a caveat) by declaring the input field's pattern as such:
<input type="text" pattern="[0-9]*" value="" data-clear-btn="true"/>
The thing is that the keyboard actually pops up first with the numeric view but it allows to toggle the alphanumeric (without emojis) view via the lower ABC side-buttons.
With Javascript I copied the entered value to another field and the Regex does not actually filter out the entered alphanumeric characters. So far so good.
As soon as you put A-Za-z (as prefix or postfix) into the pattern, the emoji button comes back though.
I have tried catching the UIResponder.keyboardWillShowNotification but does not return the keyboard object, as I wanted to set its UIKeyboardType programmatically then, but this attribute only reflects UITextViews apparently.
Alternatively you could declare the input field of password type, clearing the dots with Javascript and displaying the actual value to another non-editable field...
If I find a more elegant way, I will update my answer as it is getting quite late. Cheers.
EDIT: Apparently only using a TextInput element with ReactNative you can directly prop the keyboardType to the ascii-capable iOS keyboard which shall set us free from Emojis.
If you’re looking for a way to only allow certain characters to be entered in an input field, disabling keyboard modes (the emoji keyboard, for example) isn’t the best option. There are many ways to type in unwanted characters: they can be pasted from the clipboard, or even entered in the result of text replacement (for example, you can make :) turn into 😁).
Input validation should be done on the webpage side, not with WKWebView.
Related
I have the following page I'm displaying in WkWebView
<html>
<textarea name='message' placeholder='Type your message here'/>
</html>
And when entering text to this field, the keyboard displays a normal "Return" key.
I would like to change the label of the return key to "Send" just for this field.
Is that possible in WKWebView?
I'm aware of this answer: How to change keyboard button "Return" to "Search" for input in a UIWebView?
But the proposed solution only works in UIWebView.
For someone who is still looking for the answer, we have html enterkeyhint property nowadays: MDN.
<input id="send" enterkeyhint="send" />
<!— or —>
<textarea enterkeyhint="send"></textarea>
Most of the enterkeyhint values (enter/done/go/next/previous/search/send) have their iOS UIReturnKeyType counterparts, and the return key changes to the corresponding appearance.
i'm building an ios app that is made with AppFramework Intel and Xcode.
The files (html, js, css, img) are inside the app and are loaded by UiWebView.
I have some forms that require the user include some values.
When the input fields are pressed for some reason the keyboard is bigger than the conventional:
Here is how the keyboard looks like and should be.
http://backstagedigital.com.br/stackoverflow/keyboard-issue.png
Any help is welcome.
Thanks!
According to apple documentation:
Configuring the Keyboard for Web Views
Although the UIWebView class does not support the UITextInputTraits protocol directly, you can configure some keyboard attributes for text input elements. For example, you can include autocorrect and autocapitalize attributes in the definition of an input element to specify the keyboard’s behaviors, as shown in the following example.
<input type="text" size="30" autocorrect="off" autocapitalize="on">
You can also control which type of keyboard is displayed when a user touches a text field in a web page. To display a telephone keypad, an email keyboard, or a URL keyboard, use the tel, email, or url keywords for the type attribute on an input element, respectively. To display a numeric keyboard, set the value of the pattern attribute to "[0-9]" or "\d".
These keywords and the pattern attribute are part of HTML 5 and are available in iOS. The following list shows how to display each type of keyboard, including the standard keyboard.
Text: <input type="text"></input>
Telephone: <input type="tel"></input>
URL: <input type="url"></input>
Email: <input type="email"></input>
Zip code: <input type="text" pattern="[0-9]*"></input>
You can find the complete article here https://developer.apple.com/library/ios/documentation/StringsTextFonts/Conceptual/TextAndWebiPhoneOS/KeyboardManagement/KeyboardManagement.html
I am trying to get VoiceOver to say something other than the specified text content in an HTML span element:
<span tabindex="0" class="myClassName" id="DateLabel" role="heading">1:02a</span>
Consider the case where I might like VoiceOver to say the full time text.
When I add the aria-label attribute, VoiceOver is still reading the text, despite desktop browsers like IE and Chrome correctly reading the aria-label instead.
When I add the aria-labelledby attribute plus a hidden aria label element, I am able to get VoiceOver to read the alternate narration, and NOT the text content. However, I find this only works if the aria-role is a widget role like button or link. This is bad because I don't want to imply to users that this is an interactive element they can activate. VoiceOver annoyingly appends "button" to the end of the narrated sequence. I would prefer to use a structural role like "heading" but then VoiceOver just reverts reading the text content instead of reading my hidden narration.
Please help! I've been bashing my head against this but I simply cannot stand iOS's non-standard implementation of ARIA. I don't understand why they must be different from desktop browsers for something so simple but they are in so many places and I cannot find a good document outlining the exact behavior anywhere.
You can use aria-label like this:
<span tabindex="0" class="myClassName" id="DateLabel" role="heading" aria-label="1 0 2 am">1:02a</span>
However, why are you setting tabindex to 0? For a heading this is not a good practice because screen reader users can navigate between headings using the keyboard commands. Also, you will want to set aria-level on your heading to indicate what level it is.
The best markup to use for this is:
<span class="myClassName" id="DateLabel" role="heading"
aria-level="2" aria-label="1 0 2 am">1:02a</span>
Update: This appears to no longer work for at least some versions of VoiceOver, it will read the visible content and ignore the aria-label. See this bug - https://bugs.webkit.org/show_bug.cgi?id=160009
In my case I used for iOS VoiceOver:
<span role="text" aria-label="audible text">visible text</span>
it is important to add the attribute role="text" so that VoiceOver reads the attribute aria-label=""
In this case you could use a pattern that hides the visual text from screen-readers and hide the screen-reader text from showing visually. Like this:
<span aria-hidden="true">1:02a Dec</span>
<span class="visually-hidden">1:02 AM December</span>
and use CSS to hide .visually-hidden for example like this:
.visually-hidden {
position: absolute;
left: -999em;
}
Don't use display:none since it removes the element from being sent to the accessibility API.
As a side note: use role="heading" carefully if ever, and if so use an appropriate aria-leve="#" number/level.
You could use the abbr html element.
For example :
<abbr title="HyperText Markup Language">HTML</abbr>
I'm using contenteditable in several sections of our time keeping app. Since we're logging time, naturally, I want the keyboard to automatically switch to the number keyboard for ipad users. I've tried adding all the attributes to the elements that I can think of such as:
Type=number
Type=tel
pattern=[0-9]*
but ipad still loads the default keyboard.
Here's an example:
<div class="editable validate numbers-only" contenteditable="true" type="number" pattern="[0-9]*">3</div>
Are there any tricks that I can use to display the number keyboard for my ipad users?
you can set the inputmode attribute on a contenteditable element to control which keyboard is displayed, at least in chrome and mobile safari. for example:
<div contenteditable=true inputmode=decimal><div>
i tested out a few more examples here: https://notatoad.github.io/inputmodes.com/
I read in this post that you can use the \d* pattern to make the number keyboard appear on iOS, so a basic form with a number keyboard would look like:
<form>
<input type="text" pattern="\d*">
<button type="submit">Submit</button>
</form>
which should cause a number keyboard to automatically appear on iOS when entering form information.
Now, I'm pretty sure we could extrapolate this and say that we could use \d* on the contenteditable div to answer the question:
<div class="editable validate numbers-only" contenteditable="true" type="text" pattern="\d*">3</div>
I hope this works out for you?
I am not sure how you are using the keyboard here? Means, Is the user adding / Updating time or something? If they do, make the input type to number. This is will tell the browser (safari) that this is input for only numbers and it will tell the iOS to show number pad automatically.
<input type="number">
Checkout my fun project called weight calculator. Check how it will prevent any other keys inside input as well as it will show Number pad in mobile device.
Weight Calculator
<form>
<input type="text" pattern="\d*">
<button type="submit">Submit</button>
</form>
then
<div class="editable validate numbers-only" contenteditable="true" type="text" pattern="\d*">3</div>
<input type="tel" pattern="[0-9]*" novalidate>
This should give you the nice numeric keyboard on Android/iOS phone browsers, disable browser form validation on desktop browsers, not show any arrow spinners, allows leading zeros, and allows commas and letters on desktop browsers, as well as on iPad.
I have a data entry form in a HTML5 application that users will be filling in on an iPad 2.
Is there any way to make the iPad keyboard default to the "Symbols" view (i.e. the keyboard with the numbers 1,2,3,4,5,6,7,8,9,0)?
They will only be entering numbers in these fields, and it's quite frustrating every time you hit "next" it reverts back to the QWERTY view.
You could do this on the iPhone by using some -wap CSS, but it doesn't work on the iPads unfortunately.
Wossname's solution above works well, but if you are also using this method to hide the spin buttons that Webkit add to <input type="number" /> in desktop Safari, it will also disable the placeholder attribute in desktop Safari.
Using type="text" pattern="[0-9]*" instead of type="number" seems to fix both of these issues.
I haven't tested this myself, but according to Apple's docs this should work:
<input type="number">