I have a somewhat customized UIPickerView in my app. Basically I use pickerView:viewForRow:forComponent:reusingView returning a simple UILabel. As I started working on making the app more accessible, I noticed that VoiceOver reads label and adds, say, "3 of 300" (i.e. row number "of" total rows). This is not a desired behavior.
While trying to troubleshoot this, I found that if I use pickerView:titleForRow:forComponent instead of pickerView:viewForRow:forComponent:reusingView, without any other changes, then I get the desired behavior of VoiceOver simply reading the "title" of the selected row. I tested this on iOS 9.
Question is: how do I get UIPickerView back to the "normal" VoiceOver behavior, while still using pickerView:viewForRow:forComponent:reusingView? Thanks for any help!
I asked Apple support for help on this. The official reply was: "Our engineers have reviewed your request and have concluded that there is no supported way to achieve the desired functionality given the currently shipping system configurations". (For posterity - this was when the newest iOS version was 9.4). They suggested to file a request for new functionality, which I may do.
To solve this problem I went with the following workaround.
Created a base class almost identical to the class I had, but implementing only pickerView:titleForRow:forComponent and not pickerView:viewForRow:forComponent:reusingView. This class presents vanilla non-customized picker.
Created a subclass of that base class, now implementing pickerView:viewForRow:forComponent:reusingView. This class presents a fully customized picker.
In my code elsewhere used UIAccessibilityIsVoiceOverRunning() to create an object of base class when VoiceOver is on, and an object of the subclass otherwise
Thus when a user is running VoiceOver, they get a visually ugly picker, but one that is perfectly well-behaved in terms of accessibility (i.e. no row number announcements). Which is a perfectly reasonable "compromise" I think, since the user is basically guaranteed not to care about the visual appearances.
One fix will be to check if voice over is running
UIAccessibilityIsVoiceOverRunning()
If so use titleForRow otherwise use viewForRow. That way you don't degrade normal experience.
Related
I have completed making an IOS app. Now its been final and was ready to upload, but suddenly I was given a task to apply a new thing in the app and that is as Under
When user increases text size From the Settings > Accessibility > Larger Text or from Settings > Display And Brightness > TextSize now my app text appearance must change accordingly.
What I want: As I told you above that app is completed, and as I have used too many UILabels, UIButtons and UITextViews, so I am finding a way to how to change their text size accordingly to newly changed text size by the user. Is it possible to add any extension that increase the text size of app in more generic way. so that I do not have to go to every view in storyboard to make the view of dynamic type.
The process of changing and converting every view or coding in every class will be cumbersome. Is there any short way to handle it while everything is already completed.
Please help thanks.
The process of changing and converting every view or coding in every class will be cumbersome. Is there any short way to handle it while everything is already completed.
I'm sorry to tell you that implementing the Dynamic Type feature in an already existing app is never easy and quick to be done.
It's like making the design, it takes time and requires conception for adapting the ergonomic a11y to provide the best user experience.
Even if many things can be done in the Interface Builder, I prefer to handle everything in code because you can mutualize many properties and methods while it's element by element in the IB.
Among other things, you'll have to:
Use the text styles and activate the adjustsFontForContentSizeCategory properties of your elements to have an automatic update of your system font size.
Listen to the traitCollectionDidChange method that belongs to the UITraitEnvironment informal protocol to be aware of the font size settings changes.
Use dynamic values for adapting all your constraints so as to reorder appropriately every single element and make the containers fit their contents according to the different font size settings.
Adapt and customize every Large Content Viewers to enlarge UI elements when the Dynamic Type can't be applied (only since iOS 13).
There's no magic trick to make an app with the Dynamic Type support: you have to know how it works and then build every element as you do in your daily programming.
Hereunder few links that may help to reach your goal:
A detailed summary of the WWDC video 'Building Apps with Dynamic Type' where every steps are explained with a complete example in the end.
Some code snippets (ObjC + Swift) and illustrations to provide explanations for code implementation.
Few outlines to have in mind when testing a Dynamic Type implementation.
All these information could help you make your app with the Dynamic Type support.
In CareKit there are Care Card and Symptom tracker. I'm not understanding how to customize Carecardviewcontroller and symptomtrackerviewcontroller. I don't want to use these view controllers but interested in using components of these view controllers. there is no clear documentation to explore this.
(source: carekit.org)
If you are coming at this from a Swift perspective, then it has to be admitted that CareKit is about as "un-Swifty" as anything you can imagine. The GitHub site is certainly a start, but there is a horrific gap between reading the programming guides there and actually implementing a solution. It certainly has been a long slog for me!
That said, you can add customization to CareKit's story-board-free approach by using the view controller delegate functions that CareKit provides.
For example, suppose you have an app that reminds your user to perform two intervention activities, (1) take aspirin and (2) go for a brisk walk. If the user opens the Care Card and taps an event icon (one of the circles) for "take aspirin" then that will fire a method in the OCKCareCardViewControllerDelegate called:
careCardViewController(_ viewController: OCKCareCardViewController,
didSelectButtonWithInterventionEvent: OCKCarePlanEvent)
In this method you can segue to whatever view controller you'd like. E.g. if the event is for taking aspirin then display a view controller that shows a photo of an aspirin table, a reminder that it should contain just an 81 mg dose, and a recommendation about taking it with water.
Of course, nothing is ever easy with CareKit. It turns out that you will probably also want to turn off CareKit's standard practice of calling an event completed if the circle icon is tapped. That is accomplished by returning "false" from another delegate method called:
careCardViewController( _ viewController: OCKCareCardViewController,
shouldHandleEventCompletionFor
interventionActivity: OCKCarePlanActivity )
-> Bool
There is a book called Beginning CareKit Development that I can cautiously recommend. It was written for an earlier version of Swift and you have to do a lot of "translation" to get things to work with Swift 3. The last time I checked the GitHub repository for the code associated with the book was also entirely in this earlier version. APress will provide the code updated to Swift 3 if you ask. On the Kindle there are numerous little glitches with the book, including an index that has no page numbers nor hyperlinks to the associated text, very odd formatting choices that make the text sometimes hard to distinguish from code, and occasional errors in the solution code. All that said, I doubt that I'd have made any progress with CareKit without the book's help.
I've been looking for this answer myself.
As far as I researched, you can customize this screen visually with UIAppearance.
AND/OR you can create a new screen like this one from scratch using its behavior.
You can check the CareKit source code for hints on this: https://github.com/carekit-apple/CareKit/tree/master/CareKit/CareCard
There you'll notice some interesting classes/files:
OCKCareCardWeekView
OCKWeekLabelsView
OCKHeartView
OCKHeartButton
OCKWeekViewController
OCKHelpers
CareKit draws each screen via code. You can see how they do it by reading the code.
The idea is to create your own ViewController with these pieces, or one from scratch.
Surely it's not as trivial as just using CareCardViewController, but this will get you there.
I'm trying to make my app more accessible and so far the standard accessibility things like labels and hints are doing wonders. I'm hitting a problem however with dynamically updating content that's displayed in a UITableView.
Each row of the table updates every second or so, but if I try to create each cell's accessibilityLabel at this point then I find that there is a problem with the VoiceOver reading out the selected label keeps interrupting itself as the label contents changes so the system just starts reading the label content from the beginning again (actually an odd quirk shows the voice over sometimes works correctly for the first cell that was selected, but upon selecting a new cell this bug returns).
I've tried to see if there's anyway to try and understand whether VoiceOver is currently active but as far as I can see there is only a notification posted when VoiceOver finishes
UIAccessibilityAnnouncementDidFinishNotification
There's no equivalent notification for when VoiceOver begins. So there's no way for my TableViewController to know that VoiceOver is currently active and that it shouldn't update any accessibilityLabels.
I'd hoped I could at least detect that one of my TableView cells was the selected accessibilityElement using the
accessibilityElementIsFocused
method. However in all my testing I've not been able to see this reliably fire for a custom UITableViewCell.
I also tried implementing the getter for accessibilityLabel for my custom cell hoping this may work, but sadly the same behaviour occurs.
The only solution I'm left with is a user configurable frequency for dynamic content accessibility updates, say 5, 10, 20 seconds... which can block me updating my label until I know that the last changed content would have definitely been read out. Actually even this could be interrupted if the user chose to select a cell at say 8 seconds after the last update, 2 seconds in for a 10 second limit and the label would update causing the voice over to restart.
Has anyone any ideas of how best to handle this dynamic updating content? I'm presuming the tableview cells are complicating matters a little, but in general I just don't understand how apple expects you to handle dynamic content. All it needs to solve this is another notification
UIAccessibilityAnnouncementDidStartNotification
Or even better a method to enquire as to whether VoiceOver is currently active. But I don't seem to be able to find any!
Thanks for your time, would really appreciate any tips on this. Cheers!
You want to do two things. First you want to take advantage of the "Updates Frequently" trait. This should improve the behavior of the app when the content is on.
This should help a lot. Then you alse need to provide a way for user to halt the updating content. Independent of whether you do the above, this is an absolute requirement to satisfy WCag 2.0 guideline 2.2.2.
I want to design my own custom input view keyboard using a custom keyboard extension in swift. The existing Xcode 6.1 default set of keyboards do not fit my app needs. What I want is an enhanced number pad which I would modify, like in the Soulver app in the iOS app store. http://www.acqualia.com/soulver/iphone/
Ultimately I do not need a custom keyboard extension to offer to other apps but I do not mind if my app offers one. It looks to me like custom keyboards are the right place to start for for a custom input view keyboard.
I finally just about have digested constraints in the editor and would like to make use of a storyboard or xib.
I do need to be able to programmatically select the keyboard extension within the app.
The keyboard/custom view needs to be available to the app that contains it without activation in iOS settings.
Can this be done as an extension given the requirements, or can the custom keyboard extension be easily converted to a custom input view? Can you illustrate either one or point out sample Swift code I missed when searching? Thank you.
I am writing a keyboard extension in Swift right now and highly recommend not doing the same. Both Swift and the Keyboard Extension API are brand new, not well documented, creating significant learning curves, and both have significant bugs or weird implementation details to work around.
From the way you phrased your question it doesn't sound like you are very experienced in iOS development, and attempting to learn too many things at once is a recipe for disaster. If I could do my current project over, I would have done it in Objective C just to vastly simplify what I was learning.
But the good news is that you don't need the keyboard to run in other apps. This is good news because writing a custom input keyboard class within your own app is very simple and easy, and a great place to start. There is a good deal of existing documentation on how to do so, including this excellent post on stack overflow.
How do I retrieve keystrokes from a custom keyboard on an iOS app?
More detail:
The standard custom input view API in cocoa is very powerful, the one in the keyboard extension is almost entirely neutered, so you can do far more with a custom input view than you can with a keyboard Extension. To activate a keyboard extension requires getting the user to turn it on in their iPhone settings, there is no way around that and no way to pick which keyboard they choose within your app (other than to not allow custom keyboard extensions at all).
If you need to access the internet or data within your app for any reason (tracking usage information, activating an in-app purchase, accessing preferences) you must also convince your user to turn on "Full Access", which presents an incredibly scary alert that reads to users as if turning it on means you will be able to spy on them and steal their passwords
Getting back to why you don't want to use Swift in an extension. First, Objective C doesn't cause Xcode's code parser to crash many times a day, while developing in Swift does, sometimes crashing Xcode itself. In Objective C the debugger is almost always correct, in the current version of Swift often you can't see array or dictionary contents, sometimes what it shows is inaccurate, and when stepping through code often takes nonsensical routes. Developing in Objective Code means you won't have to update your code because of changes to Objective C itself, with Swift it's pretty much guaranteed they'll make significant syntax changes every major release (the last one in September did).
Developing a keyboard extension means sometimes your extension won't load for mysterious reasons, and you'll need to waste hours debugging why. My Swift keyboard extension is sometimes debugged solely with println() statements because I can't get the debugger to load. Since Apple's tools don't yet work well with Keyboard extensions, and also don't yet work well with Swift, using them together are multiplying your pain exponentially.
The end result is if you don't need to use this keyboard outside of your own application it's foolish to build it using the Keyboard extension API. If you do need to use the Keyboard extension API it's foolish to do it in Swift. This is written by a fool working full time trying to ship a Swift based keyboard extension.
If you want to use the standard cocoa custom input view API, then using Swift is probably fine. You will still have to deal with additional problems because it's such a young language, but you won't have lose so many days to mysterious, seemingly insoluble problems trying to figure out if they were caused by Swift, the Keyboard Extension API, failures in Xcode and it's debugger, or your own blunder.
I am looking to implement a custom toolbar that sits above my keyboard for a text field with some custom values. I've found a ton of tutorials online but this question is for asking what's the best way to do this.
This tutorial here http://blog.carbonfive.com/2012/03/12/customizing-the-ios-keyboard/ provides the most common way I can see across many tutorials, with creating a new subclass of UIView and using delegates to get that information across.
That's the commonality. However, I came across this tutorial which in the view controller itself just creates the toolbar, assigns it to the textField inputAccessory and it's good to go. In fact, I tried out the code and without any effort, I have now a custom keyboard.
http://easyplace.wordpress.com/2013/03/29/adding-custom-buttons-to-ios-keyboard/
This just seems a bit too easy to me though and I'd think the proper, Apple recommended way would be to create that UIView subclass and use delegates so that the view controller with the text fields acts as that delegate.
I'm specifically targeting iOS 7 in my app.
What are people's thoughts on this? If the second easier link is supported and is likely to pass Apple's guidelines, it's a good starting point but if delegates are the way to go, I'd rather look into that from the start.
Your thoughts will be appreciated.
There is no 'Apple Approved' way to do this, and its hard to believe anything you do here would get your app rejected. The custom keyboard you reference in your post has the iOS6 look and will appear outdated in an iOS6 app. I'll mention some iOS7 suggestions shortly, but the constant danger of mimicking what the System looks like today is guaranteed to look outdated later. In Mac/Cocoa development, Apple use to say at the WWDC that if you did something custom, make it look custom, don't take a standard Apple widget and try to duplicate it. But that advice is mostly ignored.
For iOS 7, you can create buttons that appear just like the system ones do (not pressed), but of course when someone presses them, they won't act like system buttons (i.e. animate up and "balloon" out.
I'm currently using a fantastic add-on keyboard, my fork of KOKeyboard (which uses the buttons above). This is such a cool addition. While the buttons look like iPad buttons, each one has 5 keys in it. By dragging to a corner you select one of the four, and tapping in the middle gives you that key. This might be overkill for your app, but it really helped me with mine. It looks like this:
(the Key / Value is in the under laying view.) The center control lets you move the cursor - its like a joy stick - and can be used to both move and select text. Amazing class, I wish I'd invented it!
Also, for any solution, you want to use a UIToolbar as the view holding the keys, for the reason that it supports blur of the view it overlays, just like the keyboard does. You can use the UIToolbar with no bar button items in it (if you want), and just add subviews. This is a "trick" I learned here, as there is no other way to get blur!
David's KOKeyboard (er…, the one he used - see David's comment below) looks nice. I suspect that he is using the official Apple mechanism:
inputAccessoryView
Typically, you'd set that value on a UITextView, but it can be any class that allows itself to become the first responder.
The provided view will be placed above the default apple keyboard.
It is correct that there is no official mechanism (and it is suggested against) to modify any system provided keyboard. You can add to it, as above. You can also entirely replace it for with your own mechanism. Apply will forgo the keyboard setting on your view and use a custom input mechanism if you set
inputView
set it to any view - Apple will still manage its appearance and dismissal as it does the custom keyboards.
Edit: Of course, iOS 8.x added significant access to keyboards. (not mentioned here)