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'm trying to disable symbols(+, *, #) on phone pad either programmatically or from storyboard. I have been searching for useful resources online but wasn't successful.
Is there any better way to get this done?
EDIT
I'm using a UITextField for which I have set the keyboard type to Phone pad.
You are using the "Phone Pad" keyboard but you don't want the phone pad symbols. The solution is simple - don't use the "Phone Pad" keyboard. Use the "Number Pad" keyboard instead.
Keep in mind though that users can use external keyboards or they can paste text into the text field. So you can't rely on the keyboard to ensure that only certain characters are entered into the field.
You must also do proper validation by implementing the appropriate UITextFieldDelegate method textField:shouldChangeCharactersInRange:replacementString:.
I'm currently developing an iOS app that at a very high level allows a user to enter text into a text box that will get sent to a server for incorporation into a dynamically generated PDF. The server uses Node.js & PDFKit.
We are localising the app for pretty much every language supported by iOS. The text the user enters is UTF-8 encoded when sent to the server. The problem I face is knowing which font (or fonts) to use server side to ensure the characters show up correctly in the server side generated PDF.
In the iOS client app there is a single UILabel showing a preview of the text a user has entered into a UITextField. The UILabel showing the preview has a single custom font applied that only has support for Greek & Latin characters. Interestingly when a mixture of characters are entered from different alphabets (possible if the user has multiple keyboards) latin, cyrillic, etc. they display correctly in the UILabel despite the fact the custom font does not support them:
I guess there is some kind of "font fallback" going on, however as the client app is being localised to support many languages this behaviour is desirable.
My question is how can I know server side which fonts are being used, and the range of characters they cover in the preview UILabel? Somehow I need to replicate this behaviour server side so that the text in the generated PDF approximately matches the client preview.
Alternatively is it possible to determine server side what fonts I should use for a given character?
I have a UITextView with dataDetectorTypes set to UIDataDetectorTypeAll (which should include UIDataDetectorTypeAddress), but no matter how I write an address in the text view it's never detected as a link.
Should the address be written in some kind of special format for it to work? Phone numbers, urls, emails and calendar events work perfectly.
I need to recreate custom keyboard with four levels: lowercase, uppercase, special characters and special characters when shift is pressed. I do not want to create plist file where will be placed all characters for each level. I am looking for the solution to get it using native framework.
What is the way to get characters set for each level?
Characters set should depend on language. Lets say German layout is different to UK layout.
Answer to the “Why?” question: For security reason as written in iOS Security guid at p.20 it is better to present custom keyboard to the users. As my text field have functionality hide/show password my UITextView can be in the mode not secure.
Once enabled, the extension will be used for any text field except the
passcode input and any secure text view.