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.)
I want to know the event in blocks section using which the entered text value can be obtained without a form submission through button.
Let's say user inputs text in mobile phone through keyboard and presses enter. In this case I want some event to trigger and get the value that user entered.
There are 2 events available like lostfocus and gotfocus.
Will these work? Or is there any other good approach for getting text value on pressing enter?
Unfortunately there is no such event like OnEnterPressed available in MIT App Inventor and the events LostFocus and GotFocus will not work in this case.
What you currently can do is
use a button and use the Button.Click event, or
create your own custom keyboard, see also this example
Currently there is a limitation for App Inventor extensions, which only can be used for non-visible components. Later as soon as also visible components are doable, then you could write your own textbox extension and add an event yourself.
Edit concerning the new question in the comments about different screens:
Use different screens wisely
Before starting to create another screen, first you should think about is it really necessary? See also Building apps with many screens and SteveJG's post about advantages/disadvantages, because in only one screen you also can use vertical arrangements to simulate different screens, just set the arrangements to visible = true/false as needed...
You can insert a Clock component that monitors the TextBox1.Text. When it triggers, it checks if the TextBox1.Text has changed and saves it to a variable. When it triggers again, it compares the variable with TextBox1.Text. After the user finishes typing, the variable and TextBox1.Text will be equal and then you can trigger the event like you eanted when the user pressed Enter.
Hope this helps!
I am building a chat app that uses JSQMessagesViewController. The default functionality includes the ability for a user to long press a chat bubble which then presents a copy menu option (see screenshot). I would like to add an additional custom menu for reporting a comment. Ideally when the user long presses a chat bubble the menu now has two options, copy and report. Can someone please point me in the right direction for adding this custom menu button? Thank you!
See the demo file
https://github.com/jessesquires/JSQMessagesViewController/blob/develop/JSQMessagesDemo/DemoMessagesViewController.m
See the use of customAction
I have been trying in vain to try to find how to add listeners to text area.
What I am basically trying to do is create a rich text editor where I can let the user comment on a particular item.
For this purpose I am using a text area. If you have any other suggestion please let me know.
On another note, I have not seen that there is text did change or related functionality for the textarea. Is there a way we can build it ourself?
What you are looking for are the UITextViewDelegate's. Have a look at http://developer.apple.com/library/ios/#DOCUMENTATION/UIKit/Reference/UITextViewDelegate_Protocol/Reference/UITextViewDelegate.html
EDIT
Per our chat the tutorial you are looking for to also ad a done button above your keyboard can be found at http://gabriel-tips.blogspot.com/2011/05/input-accessory-view-how-to-add-extra.html
I have a select that I'd like to use the custom menu display (rather than native) in jQuery Mobile. However, I'm just getting strange behavior out of the non-native menu (jsfiddle link). In this case, the non-native menu is only showing one of my three options.
Found the issue right after I posted it. Every option needs a value attribute set (corrected jsFiddle).
Depending on how many options you have, radio buttons groups might be a better option. The problem with any select is that it requires the user to act before ever seeing what their options are. From a user experience perspective, if you don't have a vast amount of options, use radio buttons. This section of a blog post I wrote might help.