Create accessible Single App Mode experiences

♪ ♪ Drew Haas: Hi there. My name is Drew Haas, and I'm an engineer on the Accessibility team. I'm here to talk about how to create accessible Single App Mode experiences. Single App Modes let you as a developer serve your users in really unique ways by restricting certain behaviors on iOS and iPadOS devices. Namely, these modes let you lock the device to a single app. Depending on the mode, the restrictions are either initiated by the system or by your app. This is great because you get to control the timing between a restricted state and an unrestricted state. You're also able to apply additional restrictions on top of single app mode, like whether auto-lock is enabled or not.

Let's remember to consider accessibility use cases. You should make sure people who rely using on accessibility features have the ability to turn them on so they can use them, even if the device is restricted. This ensures your app is inclusive to people using assistive technologies. I want to talk about some examples of when to use Single App Mode. Let's say you're developing an app where customers order food or drinks at a restaurant or event. Or an app that will be used in a medical office, where patients are handling a device shared by the medical staff to fill out their information. Or even an app that helps facilitate a test for students in a classroom. These are all scenarios where Single App Mode restrictions help create a focused environment for the user. And did you know your app might be used in Single App Mode even if you didn't write code for it? That's right, Guided Access is an accessibility feature that lets users put any app in Single App Mode. First, I'll talk about Guided Access and go over some considerations you should have for when people use your app during this mode. Next, I'll talk about single app modes that you initiate programmatically from within your app, by adopting certain APIs and frameworks. And finally, we provide accessibility API designed for use specifically during Single App Mode. Use this API to turn on or off certain accessibility features to create a seamless and accessible experience. Let's dive in first with Guided Access. To start Guided Access, first make sure it's turned on in accessibility settings, then open the app you want to lock on to. Triple click the side button to perform the accessibility shortcut. This shows the guided access workspace, where you configure system restrictions. Then tap Start to begin.

Now the device is in a restricted state. It's locked to the frontmost app, and the restrictions I configured in the options menu are applied. This helps creates a guided experience for people with cognitive disabilities. To exit Guided Access, all you need to do is perform the accessibility shortcut again. The options menu lets you restrict touch interaction, display motion, and the software keyboard, as well as hardware button events, like the volume buttons, and the sleep/wake button. Having a controlled environment in this way is especially helpful for people with cognitive disabilities, but this feature is also enjoyed by a range of users, from accessibility users to parents of young kids who could all benefit from having easy access to these device restrictions. This is where you come in! UIAccessibility API lets you create custom restrictions to tailor the experience of your app during Guided Access. Use this an opportunity to restrict or adjust areas of your app where someone with a cognitive disability might feel lost or overwhelmed with options. I want to share some design considerations for cognitive accessibility. These are principles you should follow all the time if possible, but you should especially follow them in your app during Guided Access. First is to be forgiving of errors. Try to mitigate errors before they happen, by warning users before they perform significant or irreversible actions, like deleting or modifying account information or payment information. You should aim to reduce dependence on timing to act on certain things in your app, because not everybody processes information at the same speed. Using timed alerts or automatically performing actions after a short time-out makes your app harder to use. And you should always, always, give the user a chance to confirm before making a payment, this includes apps that have one-tap purchases. Designing your app with these considerations promotes independence for accessibility users. I want to show you an example. I'm working on an app called Reading Observatory which helps people keep track of how much they've read during the week. The home page of my app shows reading progress and has two buttons: account settings, and a continue reading button. I've added a custom restriction for my app that will lock the Account Settings button while Guided Access is active. This gives my app a unique experience under this restriction, to help prevent users from getting lost somewhere else, like buried in account settings, where they may make unintended changes. This will also reduce the amount of times someone may get stuck and need help getting back on track with the primary purpose of my app, which is reading. To do this, first conform your AppDelegate to the UIGuidedAccessRestrictionDelegate protocol. You need to let Guided Access know about each restriction by providing an array of identifiers. I've got just one. You're also required to give a user-facing title for each, as well as an optional description if you need to provide additional detail. These strings will show up in the options menu. Finally, implement the guidedAccessRestriction (withIdentifier:didChange:) method to receive a callback when a restriction is toggled. This is where your app could post a notification to perform logic which would accommodate the restriction, like turning off user interaction for certain buttons or introducing some of those design principles from earlier.

Check if a custom restriction is enabled at any time by calling guidedAccessRestrictionState (forIdentifier:) on UIAccessibility. All of the system provided restrictions and your custom app-based restrictions make Guided Access extremely configurable, which is why it is a fantastic accessibility feature. Guided Access can be found in Accessibility Settings. Other Single App Modes are available for you to programmatically enter a restricted session on device. They share similarities with Guided Access, but the key difference is just that: you're programmatically entering this mode. This means there's plenty to talk about for setting up, starting, and customizing your Single App Mode session. Remember each of those scenarios from earlier? An iPad being used as a restaurant kiosk, at a medical office, in a testing environment– single App Modes are the right solution for all of these situations. Even though each may have slightly different needs, they all benefit from locking the device to a single app. This prevents people from swiping to go home, modifying things in Settings, or even looking something up in Safari. Let's go through each of these and I'll recommend a Single App Mode based on the restrictions we'll need.

The first mode is the most basic, and it's the easiest to deploy. It's simply called Single App Mode. This is the right solution for when you have a device that you intend to stay in a single app pretty much in perpetuity. It remains locked in-app after reboot, and there is no manual intervention needed for upkeep. Great for a low-involvement approach. A few considerations, though! The device must be supervised. Supervision tools let you lock a high volume of devices into Single App Mode at once, so this is a very scalable solution if you're working with a lot of devices. Apple Configurator lets you manage supervised devices in many ways, including putting them in Single App Mode. Select a supervised device, then under Advanced, select Start Single App Mode.

The last thing you need to do is select an app. Once you do, it will launch automatically, and lock into the foreground.

There is no other way to exit this mode. As I mentioned, it will stay locked to this app even upon reboot unless you end Single App Mode through your management software.

Autonomous Single App Mode is better suited for situations where a restricted state is entered and exited often. For example, at a medical office where a new patient fills in their information on an iPad, and then hands it back to the staff. This means there is manual intervention between restrictions. Your app gets to do this by itself, by using a single API method call to get in and out. Again, considerations– the device must be supervised, and the app that wants to use this API must be allow listed on the device's configuration profile, or the request to lock will fail because it's not privileged. The all-powerful method is requestGuidedAccessSession(enabled:complet ionHandler:) on UIAccessibility. Hey, that looks familiar! Right? This API taps right into the roots of Guided Access. You're essentially programmatically entering and exiting this feature with this code. Isn't that cool? That's because Guided Access serves as the foundation for other single app modes to exist. Bet you didn't know that! Let's see how this code might work in action. I have a method each for entering and exiting this mode that I'll call when I'm ready. They're performing different actions like starting a new patient sign-up sheet when we enter a restricted state and then bookkeep their information upon exiting. Of course, you'll want to properly address the result of the completion handler to know if something goes wrong. If so, you may want to give an alert to the user and hold off on continuing the experience forward, so they can try again. Check if Autonomous Single App Mode is enabled at any time by calling isGuidedAccessEnabled on UIAccessibility. Also observe the guidedAccessStatusDidChangeNotification to trigger any additional code when entering or exiting this mode. And remember that the app which wants to use this API must have the proper supervision and management, including allowlisting the app's bundle ID as an allowed application for Autonomous Single App Mode. And finally, assessment mode. This is the right mode when your app aims to prevent unfair advantages, by restricting certain features during testing. Turn off autocorrect, spellcheck, and single app mode locks to the app so the test taker can't access outside notes or resources. Recently these frameworks have been unified for iOS and macOS, when we introduced the Automatic Assessment Configuration framework! To use this, the device does not need to be supervised like the previous modes, but you do need to apply to Apple for an assessment entitlement for your app. More information about applying for the entitlement can be found in the developer documentation. My colleague Josh has a fantastic WWDC session that explains how to use the Automatic Assessment Configuration framework, including tons of code examples and documentation resources. Please go check it out. Once you know which single app mode solution is right for you, or if you already have a solution working, remember to keep in mind that people using assistive technologies do use your apps. There may be extra steps you need to take to make this experience accessible.

In our classic example of an iPad being used as a restaurant kiosk, Let's consider that a blind customer comes by to order. If the device is plainly locked into Single App Mode, then we have a problem. You wouldn't be able to open Settings, head to Accessibility, and turn on VoiceOver for this customer. So what can you do? Apple Configurator and other device management software help you configure options for Single App Mode. A handful of accessibility features are available for you to have always enabled, and the Accessibility Shortcut, also known as "triple-click" menu, is configurable to let users quickly toggle accessibility features like VoiceOver, Zoom, Invert Colors, AssistiveTouch, and Voice Control. When these features are always on, or when they're assigned to the accessibility shortcut, you enable people who rely on these technologies to use them while they navigate your app. It's pretty easy to set this up, so don't miss your chance to do so.

But those options have to be configured before entering Single App Mode. So what about during Single App Mode? Use API on UIAccessibility to toggle certain accessibility features directly with code. It's a great alternative to toggling a feature with the accessibility shortcut, which is helpful when device is encased in a kiosk enclosure that blocks off hardware buttons. We made this API so it's easy for you to turn off accessibility features, so you can do some housekeeping and reset state between users. To do this, call configureForGuidedAccess on UIAccessibility. You must pass in a compatible accessibility feature, and whether you want it enabled or not. This works for Zoom, VoiceOver, Invert Colors, AssistiveTouch, and Grayscale. So whether your app has custom restrictions for Guided Access or you build your entire experience around Single App Modes, it's important to know how to make sure it's accessible. The wrong kind of restrictions make something less accessible to use, so always consider the experience of someone with a disability using your app. I've shown you the APIs you need to create an accessible Single App Mode experience. Now go make something great, and accessible!