I'm looking for something that behaves like a text box and a drop-down for numbers. It has "up" and "down" buttons on the side. Clicking or holding "up" increases the number on the text box. Clicking or holding "down" button decreases it.
I remember seeing it in Visual Basic forms but I'm wondering if there is a web equivalent of such a thing; in the form of a jquery plugin or something.
I need it to look something like this.
Bonus points: If I could click on the "up" arrow and drag it upwards, the number should increment faster and vice-versa.
The name of the widget is apparently "numeric textbox". Kendo has a numeric textbox widget that gives this exact behavior, but it's not free.
I found another free widget called jstepper, but it's probably buggy and doesn't provide the behavior I'm expecting.
Related
I have a button in Android which has text "Next" written on it.
when, I have the accsessibility cursor focus on the button, it reads out "Next button". This is something I don't want. I want whenever, the cursor to have focus on the "Next" button, it must read out as "Next button. Double tap to select". This I can easily do, by setting the
btn.contentDescription("Next button. Double tap to select"),
but then it reads out as
"Next button. Double tap to select button", means it additionally reads out the last button, which seems very odd, with the "button" text getting read twice.
Is there any way, by which I can stop the last button to be announced?
You're trying to do things that are the responsibility of the AT. The AT knows that the object is a button due to its class type. The AT knows that it is clickable, because Clickable is a valid accessibility action.
TalkBack will then share this information, here is the breakdown:
"Next button, (pause) double tap to select"
"Next" -> Content Description/Text. This is the part you control.
"Button" -> Calculated in TalkBack based off of the valid actions and type(class) of the object.
"Double tap to select" -> This announcement is based off of Clickable being a valid accessibility action.
SO, when you set the contentdescription to "Next ....." you end up with an announcement of "next ....... button (pause) double tap to select" and no, there is no way to override this.
IF you are absolutely intent on making your app less accessible, you could create a custom control, write your own gesture recognizers (as in not using "onClick" events, because this would make your element accessibility clickable) to recognize tap gestures. And then write your own content description, that includes name, role, and instructions yourself.
This would be very silly in my opinion! Just let the content-description be "next" and let TalkBack tell users that your element is a button and how to interact with it. While perhaps not the "perfect" wording you/whoever this requirement came from's vision. It will be the way TalkBack users are accustomed to having this type of control announced. Consistency is sometimes more important than having things "just so".
I know I'm way late to the game, but posting an answer here for anyone that may happen to come across this post.
The others are right... we should not be putting the type of widget or how to interact with the widget in the content description. However, all is not lost.
Starting with API 21, there is a way to customize the interaction text through AccessibilityNodeInfo. You can use this class in two different ways:
AccessibilityNodeInfo has a getActionList() method. You can add customize the text that is read out by TalkBack by adding a new item to that list:
info.getActionList().add(new AccessibilityNodeInfo.AccessibilityAction(AccessibilityAction.ACTION_CLICK, "select");
The above code should change "Double-tap to activate" to "Double-tap to select". I say should because I'm just writing that code from memory... I haven't verified it's 100% correct, but it should be something along those lines.
There are two ways to utilize that class, and the one you choose is going to depend on your situation.
Method 1: Subclass your view:
If you create a subclass of the view you are using (in the case of the OP it would be a subclass of Button) then you can override the onInitializeAccessibilityNodeInfo() method and put the code there.
Documentation: https://developer.android.com/reference/android/view/View.html#onInitializeAccessibilityNodeInfo(android.view.accessibility.AccessibilityNodeInfo)
Method 2: Create a view accessibility delegate
This can be a bit more tricky and involved, but it does offer a ton of flexibility because you don't have to subclass the views you are working with.
Every view has a method that allows you to set an accessibility delegate, which acts like a man-in-the-middle and you can tweak things for accessibility purposes before the info goes to TalkBack.
Documentation: https://developer.android.com/reference/android/view/View.html#setAccessibilityDelegate(android.view.View.AccessibilityDelegate)
So basically you create a subclass of View.AccessibilityDelegate and override it's onInitializeAccessibilityNodeInfo() method with the code I posted above.
Documentation: https://developer.android.com/reference/android/view/View.AccessibilityDelegate.html#onInitializeAccessibilityNodeInfo(android.view.View,%20android.view.accessibility.AccessibilityNodeInfo)
Last but not least...
I did come across a way to stop the "Double tap to activate" text from being spoken out by Talkback. This should only be used when it really does make sense to remove it.
I repeat... this is not normally something you want to do.
I did recently come across a case where it made sense. I was using a TabLayout, and I noticed that Talkback would always read out "Double-tap to select" when the focus was on the selected tab (yes, I had used the method described above to change the text). Well... we don't want to tell the user to select a tab that is already selected, especially when the action results in a no-op. So, I used this little trick to get rid of that, but only for the currently selected tab. I left the unselected tabs alone so that Talkback would still give them the interaction text.
In your onInitializeAccessibilityNodeInfo() method, you can put the following code to remove that text:
info.addAction(AccessibilityNodeInfo.ACTION_FOCUS);
Again, I'm writing this code from memory, so I don't know if that's 100% there, but it gives you the gist of what to do.
Try to uncheck the setting in TalkBack -> verbosity -> speak element type -> uncheck. Now talkback will not announce class type of view at end of content description.
What you want to do is employ android:hint to provide information on inputting information (instead of adding it to the label).
Your label would be "Next" (either using labelFor with an onscreen label or android:contentDescription for hidden labeling)
Then your hint would be "Double tap to select" (using android:hint)
I'm having what seems to be an odd problem, and I'd greatly appreciate any suggestions which might help.
I'm trying to achieve due diligence by testing on a variety of screen form factors, but I'm having a problem when it comes to the default ( AKA Google ) keyboard on an emulated Nexus 4 using API level 19. AFAIK, according to the on-line specs the Nexus 4 was released with API 17, so it would seem to me that 19 ought to be able to handle any hardware in the Nexus 4.
I'm working with an app that displays a document and if the User wishes, allows notes about the document to be entered, at the same time the document is being viewed. By default most of the screen is taken by the view of the document. But when a Button is pressed to allow notes about the document to be entered, Views are re-arranged to allow for a soft keyboard to be displayed along with an EditText view to accept the notes and still allow for as much of the document to be viewed, as conveniently as possible, and scrolling is provided.
In the default "portrait" orientation I'm able to shoehorn in what I need with out too many problems; but oddly in "landscape" orientation, no matter how I try to constrain it, the on-screen keyboard itself occupies fully half the screen "height" and takes the other half with a separate input area it displays, several lines high; the "DONE" button is displayed separately about half way up the height of the input area near the right screen edge.
In order to keep the soft keyboard and any associated input area as small/simple as possible, I've supplied these attributes for the EditText:
android:inputType="text|textNoSuggestions|textShortMessage"
android:singleLine="true"
and this for the themes in my styles.xml file :
<item name="android:windowSoftInputMode">stateUnchanged</item>
I've even considered going as far as building a custom keyboard structure in XML, etc.. But my understanding is that Android won't allow a keyboard definition to be used "privately" for just one app; instead it requires a custom keyboard description to be approved by the User as the User's standard keyboard, or won't allow the custom keyboard to be used at all.
Have I've missed something? Am I not making the correct use of attributes for my purpose? Is there something else I need to do in order to get the desired effect? Does the actual Nexus 4 behave as I've described? Or is there a problem with the Emulation?
I'd be very grateful for any helpful thoughts.
Hopefully some images will help to illustrate the issue.
Default document viewing mode:
After the User presses the "MAKE NOTES" Button, note taking mode. This is before the User presses within the EditText view ( which is displaying the hint string "To enter notes, press here" ) :
When the "MAKE NOTES" button is pressed I rearrange things. It appears to me that the controls fit roughly in the upper left quadrant,
the document view is placed in the notably smaller scrollable area roughly in the upper right quadrant; I request that the keyboard be displayed, and it fits on the screen below those things. Since the keyboard does fit, I wouldn't have expected the "extract" view; especially since by the time I got these emulator screen snapshots, I had restricted the EditText view to one text line, so I would expect input to occur in place, within the
EditView, just as it does in "portrait" orientation...
Instead, when the User presses within the EditText view:
There is no way to change the height of the keyboard. The keyboard itself sets that, in the onComputeInsets of the InputMethodService class, combined with the height of the view returned in onCreateInputView.
You actually can create a keyboard just for your app, but your users will hate you. You aren't going to write Swype functionality, or good autocorrect, or anything else without spending the years on it the other companies have.
What you seem to be describing is a full-screen editing situation called extract view where the keyboard takes over the full screen in landscape mode. THat's the standard Android experience for phones because too little of the screen is left for apps to be usable. Is that what you're seeing, or is it something else? If it is extract mode, try adding android:imeOptions="flagNoExtractUi" to the textview.
When typing in an EditText control - some autocomplete/autosuggest words are made available at the top of the control.
Like below:
I have a situation where the user should only be entering words from a pre-known set of existing words. As such it would improve the user experience to control the autosuggest list, and have only words from this list appear.
All my searches on this subject have turned up is suggestions to use AutoCompleteTextView for this purpose, however this is not 100% ideal - below is a screenshot of AutoCompleteTextView in action:
The suggestions show as a popup list, and the top of the on screen keyboard now has unnecessary blank spaces.
So while this sort of 'works' - it isn't a 100% ideal user experience, it will feel 'hacky' to the user, and not as native/seamlessly integrated with the android experience as it should be.
So my main question(s)
1) Is there a way to either have the AutoCompleteTextView show its suggestions at the top of the on screen keyboard?
2) Or even better/alternatively, is there a way to hook into the autosuggest/spelling feature of the on screen keyboard for EditText itself instead?
Yes, you can. InputMethodManager.displayCompletions will give the keyboard a list of possible completions. Depending on the keyboard, it should display those but it may ignore them. That's how ACTV works behind the scenes.
I'm designing my first Android IME and am a bit overwhelmed. My goals are accessibility-related, and as such I wonder if perhaps I'm trying things with the IME framework that just aren't possible. I've taken the default softkeyboard example and have it working along with some of my modifications, so I've definitely understood at least some of this, but there isn't a whole lot of documentation on some of the things I'm attempting. Here's what I mean:
Currently, Android phones with touchscreen-only keyboards are inaccessible. I currently have an accessible touchscreen keyboard using methods similar to those used in IOS/VoiceOver, so that part of the project is done and fairly straight-forward to accomplish in the IME framework.
Currently, Android's accessibility API doesn't provide accessible feedback for navigating text fields. That is, with an Android screen reader loaded, if you type the word "this", you'll hear individual characters spoken as you type them, but if you then try left-arrowing over the "s", that isn't spoken. So I want to trap movements and provide spoken feedback for the elements navigated past. Here's where I start encountering problems.
I currently have speech feedback for left and right arrowing, using getCurrentInputConnection.getTextBeforeCursor(1, 0) for arrowing left, and a similar call for arrowing right. This gets the character currently under the cursor after the movement is processed, and all is good.
My challenge, though, comes when arrowing up and down between lines. Ideally, I'd like to grab the current line of text and speak that, but I don't see any way to do that. The only thing I can think of is some combination of getTextBefore/AfterCursor(Integer.MAX_VALUE, 0) and combining those values, determining the current line by filtering for the previous and next \n. Is there another way--getting the entire text content of the field as a single block of text and using the cursor position to determine which piece of that text represents the current line? I'm seeing something about extracted text in the various input method classes, and it seems like there may be a way to monitor that, but I don't know if that is at all useful to me (I.e. would that return the entire field content?)
My next goal is providing standard text navigation capabilities. Android accessibility doesn't currently include touchscreen exploration, so it is impossible to otherwise scroll a large block of text. I don't necessarily expect folks to write novels on their phones, but I'd like to provide quick gestures or commands to move up/down paragraphs, and to the top/bottom of longer fields. Does the IMF provide methods for cursor movement, or is that outside of its authority?
Honestly, I didn't get the first part :(
For your second question, you will need to handle it by hand.
For instance, to add a key with a down drawable and make it work you will need to:
In the onKey method check for the code.
If it's 20, you should do a sendDownUpKeyEvents of that key event.
Does anyone of you friendly coders know how to change the text on the return key of the android keyboard. I am catching the return event of an EditText element to start an action. So I would like to show the user, that he can start the action with that key. Some applications do that. E.g. they replace the key with a search symbol.
I am also wondering why apps always have an additional button aside the text field. Clearly, this takes away screen space. But it may be necessary for some purpose I am not aware off. The one problem I could imagine is task switching. After switching back, the user would have to call the keyboard before he could start the action. The other is a hardware keyboard, but anyone will assume that the return key will start the action.
R.G.
There are some ways to change the behaviour of the return button on your software keyboard. If you want to have the search Icon on your keyboard you have to add android:imeOptions="actionSearch" to your EditText View. There are some other actions that you can set for an overview over the available options have a look at the documentation of the TextView.
I would guess the reason that there are buttons next to many textfields to trigger the action is because users are used to it and would be a little bit at loss if the button is missing especially users with a hardware keyboard or if the software keyboard disappeared. One additional problem is that the return key is also used to create line breaks this means that if you want to have a multi line text field you cant use the return key to start an action.
If you want, you can hide the additional button beside the text area by adding the attribute
android:imeOptions="flagNoAccessoryAction" to your TextView or add it in code using
myTextView.setImeOptions(EditorInfo.IME_MASK_ACTION & EditorInfo.IME_FLAG_NO_ACCESSORY_ACTION);.
This is generally advised against, however, because of the user not being able to see what action will be performed when, say, the return key is pressed, or not being able to perform an action at all.
More info in this blog post: http://android-developers.blogspot.dk/2009/04/updating-applications-for-on-screen.html.