Im new to slack app development and did search for a while now but the most customizable ui elements that i found so far were those listed in surfaces.
What i would like to do is add a new ui element to the account details you see when clicking on a users name, but im not sure if that is even possible.
I would either want to add a button at the top or some text further down.
You can use the [users.profile.set][1] method to set additional information for a user profile. This might be the closest approach to what you want but it will only allow you to add text fields, it's not possible to modify or add other UI elements like buttons.
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 first thought of having some achievements in first version of my game app. So I created one in iTunes Connect for test. Now I don't want to have any achievements for user. I want to delete it, but there is no delete option surprisingly. Box under status column is empty.
In apple doc:
So the Question is when can I delete achievement? What's the restriction? Please can someone tell me how can I remove achievements from itunes connect game center? Thanks.
I had the same problem. The problem is all about the iTunes web site. Actually, there are delete buttons on the status column but they cannot be seen. And the only reason is that the "padding" property of the column's style class.
The solution steps:
On achievement list; right click any of the rows and select "Inspect Element".
There are many of the html list item elements ("li"). Expand one of them and the div under of that.
Select on of the div elements that have "ajaxListColumn" class.
On the right panel, deselect the padding property (it should be the third style).
I added a screenshot for the steps above.
I am creating an iphone application, where i am getting confuse. I need to show a control (displaying Online option) as i have mention in below screenshot. I have seen such type of controls in Android.
When user will press, it should display Offline and Online two options in one small pop up view. Selected option text will come on to the control field. How to implement or give me suggestion to show such type of field in iphone.
Thanks in Advance.
Check the answer here: Any pull down or drop down menu for iOS?
Personally I would make a text box with an image view to make it look like a drop down box. then on tap load a UIActionSheet for the user to select from.
I want to create a Alphabet (Character) tracing and learning app.Which will be multilingual app.The font for different language will be attached in app resource folder. First user select language and fond. According to language selection the keyboard will be shown.Then user enter a character and trace. Is it possible to show keyboard according to language selection.Or I have to create custom keyboard.Please suggest me.
You have no control over which keyboard gets shown, unless you create a custom one, unfortunately. If you had control, you might request to show a keyboard that the user has not enabled in their settings and this would cause a problem. The only keyboards you can request to open are the ones listed in UIKeyboardType