I'm looking for any specific guidelines (from Apple or elsewhere - not opinions) on how much text I should make VoiceOver read when I tap on some text in the app I'm developing.
When I tap on a header, should it read only the header, or should it also read the section below that header? When I tap on a paragraph, should it read the header and then the entire section that contains this paragraph? In what situations should the spoken text provide more or different information than is actually displayed by the app?
(I'm not asking what it does, I'm asking what it should do, because as a developer I can set an item's accessibilityLabel to as much or as little text as I want.)
I don't see anything relevant in https://developer.apple.com/library/archive/documentation/UserExperience/Conceptual/iPhoneAccessibility/Making_Application_Accessible/Making_Application_Accessible.html#//apple_ref/doc/uid/TP40008785-CH102-SW5.
Your link seems clear enough, especially the section on Supply Accurate and Helpful Attribute Information which includes, among other details, the following:
A good way to determine what a label should convey is to think about what a sighted user infers about your application just by looking at it. If you’ve designed a good user interface, sighted users should know what a control or view does in the current application context by reading its title or understanding its icon. This is the information you need to make available to VoiceOver users in the label attribute.
If you provide a custom control or view, or if you display a custom icon in a standard control or view, you need to provide a label that:
Very briefly describes the element. Ideally, the label consists of a single word, such as Add, Play, Delete, Search, Favorites, or Volume.
Strive to design your application so that a single word identifies an element and makes its usage obvious in the current context. Sometimes, however, it might be necessary to use a brief phrase to properly identify an element. When this is the case, create a very short phrase, such as “Play music,” “Add name,” or “Add to event.”
Does not include the type of the control or view. The type information is contained in the traits attribute of the element and should never be repeated in the label.
For example, if you include the control type in the label of an Add button, VoiceOver users hear “Add button button” every time they access that control. This experience would quickly become annoying and might motivate users to stop using your application.
Begins with a capitalized word. This helps VoiceOver read the label with the appropriate inflection.
Does not end with a period. The label is not a sentence and therefore should not end with a period.
Is localized. Be sure to make your application available to as wide an audience as possible by localizing all strings, including accessibility attribute strings. In general, VoiceOver speaks in the language that the user specifies in International settings.
Each tappable view should provide its own accessibilityLabel. If a user can tap on the header and the user can tap on the section below the header, then tapping on the header should just read the header and tapping on the section below the header should just read the section below the header.
When you think about accessibility, you should be approaching it from the perspective of your end user. For example, if you have a heading entitled Hospital Name: with a subheading reading Massachusetts General Hospital, it would be a good idea to read the two together because they provide context for one another. If, on the other hand, you have a header entitled Hospitals: and then you have a long list of hospitals below, it would likely be better to allow the user to scroll through all of the hospitals at his/her own pace.
With larger blocks of text such as a paragraph on a UILabel or UITextView, the amount you read again depends on the context. If it is a description of something that should be read as a solid block without interruptions so the user can understand the content, then it is completely fine to set it as a single Voice Over block. If, however, there should be strategic pauses to allow the user to decide if he or she wants to hear more (e.g. End User License Agreement, paragraphs in an essay), then you should separate it into sections to allow the user to control the pace and select the location.
With larger blocks of text, I would recommend that you do not set the accessibilityLabel to the contents but rather the accessibilityValue. This will allow the user to hear a short description in the label of the object in the accessibility focus prior to deciding if he/she wants to hear more. Again, this gives the user context prior to continuing.
You're developing a native app and not an html webapp? In the latter case, the user can swipe left/right to navigate to the next element in the DOM and only the text that is associated with that DOM element is read. However, the text associated with the DOM element can be "enhanced" by associating additional text with the DOM element (aria-label, aria-labelledby, aria-describedby, class="sr-only", etc), if it's deemed necessary to help a VoiceOver user understand the context. For example, a "register now" button or "read more" link might need additional information so that the purpose of the button/link is clear. (Register for what now? Read more about what?)
The same principle can be applied to native apps too, which sounds like what you're asking about. If your app has a heading (ala <h1>, <h2>, etc, but however it's defined in objectivec), then those shouldn't need additional text associated with them. The heading should be worded so that it's context should be sufficient. The paragraph following the heading can be navigated to by the user swiping right. They'll know the paragraph is "under" the heading because it's the next element they swiped to.
Same if the user taps on the paragraph. The heading associated with the paragraph does not need to be read. The user can swipe left to get to it, or they can use the rotor set on "headings" to swipe up/down to get to the prev/next heading.
So the general guideline is to try to provide all the context that is needed in the text of the object itself, if possible. But you also have to balance that with succinctness. If the text needs additional context, then it sounds like you should use accessibilityLabel. Is there another attribute that provides additional information such as accessibilityDescription? (I just made that attribute name up. Not sure if it exists.)
Background/Context:
I am developing touch screen based kiosk application with JavaFX. The app integrates browser – WebView. The problem is that all user inputs have to be made through on screen keyboard (SW keyboard)
It would be nice to have an option to register an event-handler on WebView/WebEngine for any HTML text input element got/lost focus, so that I could show/hide on-screen-keyboard.
Even though I searched the Internet, I did not find this kind of feature.
My questions:
Does JavaFX / WebView provides any support for these cases?
If you were to tackle this problem, what would be your approach to that?
My solution so far:
I have a small button (at one corner of the screen) that allows user to show/hide on-screen-keyboard. Since they have to do that manually, it is quite annoying. Especially on sites where browsing (consuming information) and text inputs changes frequently.
It would be nice to have an option to register an event-handler on WebView/WebEngine for any HTML text input element got/lost focus, so that I could show/hide on-screen-keyboard.
A potential strategy for doing this:
Start with a jdk8 preview.
Run the application with -Dcom.sun.javafx.isEmbedded=true to enable the virtual keyboard.
Use a webengine.executeScript technique to embed jQuery into the target page.
Bind a jQuery focus handler to the relevant html elements.
In the jQuery focus handler make an Upcall from JavaScript to Java.
Upon receiving the upcall make use of JavaFX's Virtual Keyboard.
As the user enters values into the keyboard, make executeScript calls to set the value of the corresponding html field.
Some parts will likely be a bit (or totally) flaky, but perhaps other parts may prove useful to you.
In the future, if WebView is supported on touchscreen platforms on embedded devices, I'm guessing that out of the box it will work well with a virtual keyboard.
For single form UI's the form assistant in the mobile safari virtual keyboard doesn't provide much value and reduces the useable space in the viewport. Is it possible to remove this section of the keyboard for forms that do not benefit from this?
In essence, you must wait till the keyboard responds and then forcibly grab and remove that top bar. It's not pretty and definitely not perfect but it is a starting place. I'll post the refinement of this process as I work on it myself.
Here is the question. I implemented this using Trigger.IO and native plugins but, naturally, you can ignore that and just run it on your UIWebView: How can I hide Form Assistant with iOS native plugins using Trigger.IO?
Does any one know how to Create custom keyboard in iphone? Pls give me any samples for custom keyboard
Hi you need to try following link. They have explained very well and step by step that how to create Custom Keyboard. http://www.appdesignvault.com/ios-8-custom-keyboard-extension/
But while creating Custom Keyboard there are some limitations you must know:
A Custom Keyboard cannot be used to type into certain text input objects. These include the secure text input objects (any object that has its secureText property set to YES) and phone pad objects (any object that has a keyboard type trait of UIKeyboardTypePhonePad or UIKeyboardTypeNamePhonePad). When the user types in any of these text input objects, the system temporarily replaces your custom keyboard with the system keyboard, and on typing in a non-secure or non-phone pad object, your keyboard resumes.
Input dictation isn’t possible for a custom keyboard since, like all extensions in iOS 8, it has no access to the device microphone.
Selecting text is also not possible. Text selection is under the control of the app that is using the keyboard.
Closely related to the above point, editing menu options i.e. Cut, Copy, Paste are inaccessible. If an app provides an editing menu interface, the keyboard has no access to it.
App developers can reject the use of custom keyboards in their app. This can especially be done in apps that are sensitive to security such as banking apps.
You cannot display key artwork above the top edge of a custom keyboard’s primary view the same way Apple does when you tap and hold a key in the top view.
and very Important you must follow the Apple Extensions guide
https://developer.apple.com/library/ios/documentation/General/Conceptual/ExtensibilityPG/Keyboard.html#//apple_ref/doc/uid/TP40014214-CH16-SW1
Enjoy. Happy coding.!!!
I am developing a blackberry application using j2me and LWUIT (blackberry port). Everything works great except for the TextField in numeric mode. Basically when you have focus on the TextField you have to first go into "NUMERIC" mode (by pressing alt + aA) in order to input, which is not user friendly and a problem.
The proposed solution is to use a TextArea instead that allows you to open a NATIVE type input box. The problem there is that the user needs to focus the field and then press the fire button which again is unfriendly.
Does anyone know of any simple solutions?
The few solutions i have in mind (but not sure how to do them):
1) Capture any keypress on the TextArea and go into NATIVE mode, instead of just the fire key.
2) Put the blackberry input mode into numeric using code for the whole form.
Any advice will be appreciated.
Many Thanks,
Paul
I'm not sure whether this solution is one that would appeal to your needs or not, but you could add j2me onKeyPress handling that "translates" the letter keypresses into the numbers that correspond to the same key and adds the "correct" number to the textfield instead of what the user actually pressed. Do keep in mind that such a solution would require you to worry portability issues as far as not all blackberry models using the same keyboard layout (qwerty vs. reduced qwerty for example) and handling the variation in layouts sufficiently.
Okay well to answer my own question.
I overrided the keyRelease method on a TextArea. And in this method if the keypress is not an arrow key i the call editString method (this causes the native textfield to open). The only downside to this is that it will always miss the first keypress in the text box.