what should be the Talkback behavior on the truncated view. In one application talkback is reading entire message along with the view more button. Functionality is like that when using click on more detail additional detail what expanded and more details button become the less details, problem is that when focus went to truncated messages talkback is reading entire message which could be of one paragraph to too many paragraphs or so on. Ideally it should read only display message however functionality has been designed in such a way that entire text is coming in application and through UI it has been hide.
My questions are
1 is there a way to read only that part of text which has been displayed even whole message has been provided
2 if not possible above approach, who'd be the length of characters talkback should read and stop as i can do so
I also keep this thing in mind that length in truncated view can be increase or decrease depending on screen xiae
Thanks
Anubhav
Set the view's content description to be the truncated version of the text. Update the content description when the truncated text changes, ex. if the view size changes.
someView.setContentDescription(truncatedText);
Related
I tried Talkback accessibility service on my app.
When I navigate through my app I have:
some line seperators, where Talkback reacts sensitive and talks something on that seperator which does not make any sense.
images beneath its explanation text, where talkback reacts sensitive to the images, instead of jumping to the text beneath and read the text here.
How can I ignore UI elements like seperators completely?
How can I ignore some certain designated images and navigate to their text explanation beneath instead?
Kudos for implementing/testing accessibility in your app!
To disable accessibility behavior, since API 16 you can use the android:importantForAccessibility="no" attribute, or programmatically via
myView.setImportantForAccessibility(View.IMPORTANT_FOR_ACCESSIBILITY_NO)
or
ViewCompat.setImportantForAccessibility(myView, ViewCompat.IMPORTANT_FOR_ACCESSIBILITY_NO);
To ignore some certain designated images and use their text explanation beneath you can set the text explanation as the contentDescription on the image. Talkback will read a views contentDescription.
myImageView.setContentDescription (string-value-from-caption)
I have a filters view which upon dismissing, I'd like to do 2 accessibility things:
announce "$listSize items in list" since applying the filters will change the list size
set focus to the "Add filters" button
I tried the following:
filtersButton.announceForAccessibility("$listSize items in list")
filtersButton.sendAccessibilityEvent(AccessibilityEvent.TYPE_VIEW_FOCUSED)
I would expect TalkBack to read, in order:
"20 items in list"
"Filters button"
However, it usually skips the first read-out and only reads the text on filtersButton. Sometimes it will read only part of the first before skipping to the second.
How do I force TalkBack to read out both accessibility events?
It is good practice, and a recommended approach, to make the textual and audible information similar. Try to avoid announcements, instead make the screen reader read the information that is shown. The method announceForAccessibility() is intended to inform visual changes that otherwise would be unnoticed.
Do you have a view on your screen that shows the total number of items? If you don't have a visual clue of the item count, you shouldn't announce it on TalkBack. Either the information is important and you should present it visually to all users, or the information is not that important to be displayed on the screen, and shouldn't be announced on the screen reader.
If you have it visible on the screen, you may use the AccessibilityLiveRegion to let the reader announce the changed value, and keep the focus on the Add filters button. Another approach would be simply setting the first focus to the view showing the items list count, and letting the user navigate to the button next.
ViewCompat.setAccessibilityLiveRegion(itemCountTextView, ACCESSIBILITY_LIVE_REGION_POLITE)
Explanation of what I am trying to do
I'm making a custom in-app keyboard that works on the same principle of this example. However, in my keyboard I'm using popup windows to display extra letter forms. In traditional Mongolian letters have different forms depending on if they are located at the beginning, middle, or end of a word. Usually these can be determined from the context, but sometimes a user needs to choose an alternate form explicitly from the popup key candidates.
Lets say that a user starts typing a word (where - represent letters):
---
Then they chose a from the popup (I'm only using a to represent the concept of choosing a special Mongolian glyph form). The Unicode for this letter will be rendered as follows if they continue typing:
---a--
However, the Unicode is rendered as
---A
at the end of words. (a and A have the same code in Unicode.) So the user is confused why they chose a from the popup key but it gets rendered as A in the editor. If they would just keep typing, though, it will be fine since it gets rendered as a in middle of words.
What I want to do it set some sort of temporary span on the a of ---a so that it doesn't get rendered as ---A before they type the next letter. But if they add a space or move the cursor to a different location, then it will revert back to the default ---A form for final letters. (That is, the temporary span will be cancelled.)
Real example
If the abstract a and A are too confusing, here is a real example. The user wants to type a Mongolian UE form (Unicode \u1826\u180c) in this word
But since \u1826\u180c gets rendered like this at the end of words
the user is confused until they continue typing. I want the span to make it look like this
which can be temporarily rendered with \u1826\u180c\u200d.
Documentation
The documentation says
If your IME does text prediction or requires multiple steps to compose
a glyph or word, you can show the progress in the text field until the
user commits the word, and then you can replace the partial
composition with the completed text.
And it gives this example and image:
InputConnection ic = getCurrentInputConnection();
ic.setComposingText("Composi", 1);
ic.setComposingText("Composin", 1);
ic.commitText("Composing ", 1);
Problem
I was going to describe why it wasn't working in this section, but in the process of setting up my question here, I discovered that it actually works. So I will add my answer below as an example for other people are who doing something similar.
The following code sets a temporary composing span when the string in question is returned by the popup window
if (selectedItem.equals("a")) {
inputConnection.setComposingText("a", 1);
}
where selectedItem is the string chosen by the user from the key popup window candidates.
Note that the a has an underline indicating that it is a composing span. (This is a contrived example from the question where a would be rendered as A if the text were committed immediately.)
This also works for the real example in the question
if (selectedItem.equals("\u1826\u180c")) {
inputConnection.setComposingText("\u1826\u180c\u200d", 1);
}
Committing the composing span
When it is confirmed that the user wants to keep the composing span (ie, they keep typing more letters in the word), it can be committed with
inputConnection.commitText("\u1826\u180c", 1);
Abandoning the composing span
If the user clicks somewhere else, the composing span is not cancelled. But this is a different question.
Your keyboard can override onUpdateSelection to listen for cursor changes there. Then call
inputConnection.finishComposingText();
to keep whatever text was in the composing region. Or
ic.commitText("", 1);
to get rid of it. See this answer for more.
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.
In my android application, I am displaying a long string into multiple pages. I achieve this by breaking the long string into a string array where every array element holds the number of characters which can fit on one screen (without scrolling). Also by using a previous/next button at the bottom of my activity I change the content of my textview to switch between pages(array elements).
Where I am stuck is in finding out how many characters will show on one page/screen. Remember I don’t want user to scroll. I use the paint.breaktext with screenwidth as the parameter and find out how many characters go in one line and then multiply it by number of lines on one screen to get the number of characters in a page. Android’s text wrapping at the end of each line is what gets my calculation of finding characters in a page, wrong. I am trying to put my own logic to accommodate for text wrapping but that is not working.
So my question is:
Is there any way I can find out that how many characters will show in one screen?
Or what can also help me is if I find out what logic is followed by android for wrapping the text for newline. Because if I know that, then I can readjust my number of characters on a page accordingly.
Or other option could be to disable text wrapping (not sure if possible). Because then I can use my own logic to wrap the text rather than trying to figure out Android’s text wrapping logic and adjusting my character-on-a-page accordingly.
Any help is much apreciated.