보조 접근을 위해 앱 사용자 정의하기

Hi everyone. My name is Anne, and I’m a member of the Accessibility team at Apple. Today, I’m excited to talk all about Assitive Access, Apple’s streamlined iOS and iPadOS experience designed for people with cognitive disabilities. Assistive Access reimagines how people interact with their devices by distilling apps and controls to their essence. This clarified experience ensures everyone can navigate their devices with ease and independence. In iOS and iPadOS 26, your app has the opportunity to seamlessly integrate with this experience through the Assistive Access scene type.

Today you’ll learn how to build a great experience for your app in Assistive Access.

I’ll share how to create an Assistive Access scene with SwiftUI as well as the principles to keep in mind as you tailor your app further.

First, I’ll get started with a refresher on Assistive Access.

Apple introduced Assistive Access in iOS and iPadOS 17.

This streamlined system experience is designed specifically for people with cognitive disabilities. It seeks to reduce cognitive load by providing apps and interfaces with streamlined interactions, clear pathways to success, and consistent design practices.

If you’re new to Assistive Access, check out the session Meet Assistive Access to learn more.

Assistive Access supports several distilled built-in apps, Camera and Messages, shown here.

These apps share a common style: they have large controls, streamlined interfaces, and visual alternatives to text.

In establishing a clear and focused design language in Assistive Access, these apps reduce the cognitive strain that is required when interacting with new and varied UI. The design is consistent, so the expectations are consistent.

By default, apps not optimized for Assistive Access are displayed in a reduced frame. This is to make room for the back button, which is always shown along the bottom of the device. The back button navigates from the app to the Home Screen.

For those of you with apps already designed for people with cognitive disabilities, you may want to bring your app as is to Assistive Access. A great example of this is if you support an Augmentative and Alternative Communication app, also known as an AAC app. If, like an AAC app, your app is designed for cognitive disabilities and you want to bring the same layout and the same experience to Assistive Access, then your app is ready to take advantage of full screen. To display your app in full screen, set the UISupportsFullScreenInAssistiveAccess key to true in your app’s Info.plist. Your app’s appearance will be the same as when Assistive Access is turned off, with the exception that it will fill the full dimensions of the screen rather than displaying in a reduced frame. If you need to make runtime variations, use the SwiftUI and UIKit support to detect if an Assistive Access session is active.

Apps that adopt full screen in Assistive Access are displayed under the Optimized Apps list in Accessibility Settings.

If your app isn’t designed for cognitive disabilities, get started with support in iOS and iPadOS 26 to create an Assistive Access scene With this scene type, you’ll provide a tailored experience, where controls are automatically displayed in the familiar and prominent style of built-in apps like Camera and Messages. This differs from full screen support, where your app is unchanged aside from the screen dimensions.

If you’re unsure which path to take, opt for the scene to take advantage of all that iOS and iPadOS 26 have to offer for Assistive Access. I’ll demonstrate how this scene type elevates your app in Assistive Access. Assistive Access apps share a design that focuses on clarity. And this clarity starts with the unique way native controls are displayed when Assistive Access is turned on.

With the scene type, your app is shown in the larger, clearer control style that matches the existing experience. This familiar design helps people with cognitive disabilities get the most out of your app. To set up your app for Assistive Access, First set the UISupportsAssistiveAccess Info.plist key to true in your app bundle.

This ensures your app is listed under Optimized Apps in Assistive Access Settings.

Your app will also launch in full screen, instead of the default reduced frame.

Next, adopt the Assistive Access scene and create your streamlined app experience. I’ll put this into practice.

I’ll update an app that I’ve been working on. This drawing app lets me sketch on a canvas, sort my drawings into folders and favorites, and use a range of editing tools to create fun and engaging illustrations.

My app is using the SwiftUI lifecycle. I have 1 scene, which is a window group that declares my main content view.

After setting UISupportsAssistiveAccess to true in my app’s Info.plist, I’ll add the AssistiveAccess scene to my app. Within the Assistive Access scene, I create a new content view with the custom hierarchy I’m designing for Assistive Access. This new content view will host my streamlined, lighterweight app experience.

When the app is launched in Assistive Access, this scene is created and attached.

When a scene is active, an app’s native SwiftUI controls are displayed in the distinctive Assistive Access design Buttons, lists, and navigation titles are all shown in a more prominent style with no additional work Controls also automatically adhere to the grid or row screen layout, which is configured in Assistive Access settings.

To test how your app is laid out when the scene is active, pass the assitive access trait to the SwiftUI preview macro.

For UIKit apps, you can achieve something similar with support in iOS and iPadOS 26 to define and activate SwiftUI scenes in UIKit-lifecycle apps. Declare the AssistiveAccess SwiftUI scene from UIKit in the static rootScene property of your scene delegate class. To activate the scene, scene delegate class configured to host the Assistive Access scene from your app delegate.

For more information on scene bridging, check out this year’s session on What’s New in SwiftUI Assistive Access is built around simplified and easy to use interactions. Now that your app is set up for Assistive Access, bring this focus to your app content.

I’ll go over a few guiding principles to help focus your app’s content for Assistive Access. When thinking about this experience, distill your app to the essentials. Consider how to build understandable, supportive pathways that are safe from disruptive changes and convey information in multiple ways.

Start with identifying the core functionality of your app. Ask yourself what one or two features are most important to support in your app, and bring these to Assistive Access. It may seem counterintuitive to remove functionality, but fewer options reduce distractions and lighten the overall cognitive load.

When in doubt, keep the Assistive Access experience streamlined and focused. For my app, I’ll bring two features to Assistive Access: the ability to sketch on a canvas, and the ability to view those drawings. These will be the ONLY UI elements in my app’s root view.

I’ll save the other functionality that my app provides, like marking favorites or editing sketches, For outside of Assistive Access to keep the experience focused.

Here is the redesigned root view of my app. I’ve implemented the two features I identified: Draw And Gallery These two features are represented as a list of navigation links. Since the Assistive Access scene is active, the links automatically conform to the preferred grid or row layout style.

When I navigate into a view, the Assistive Access back button traverses back up the app’s navigation stack with no additional work.

Already, my app is more focused. The only UI elements onscreen are the app’s essential features, and the UI is displayed in a familiar Assistive Access style. I also present two clear pathways: draw, or gallery. Fewer options correspond to streamlined choices, and streamlined choices increase the likelihood of success when someone is exploring the app. After deciding how best to distill your app experience, you may still want to add some level of customization. I’ll go through how to add to your features in Assistive Access. When approaching Assistive Access, remember the aim is to reduce cognitive strain.

While rich features and customization add to your app’s level of completeness, a large amount of content on the screen may prove challenging for people with cognitive disabilities. Reduce the number of options shown at any given time to focus decisions. This applies both to the number of onscreen elements, as well as the purpose of the view.

Reducing options removes distractions when navigating in your app. Too many options may prove overwhelming and add to cognitive load. Next, make sure presented controls are clearly visible. Avoid hidden gestures or nested UI. These types of interactions may be less discoverable to a person with cognitive disabilities.

Instead, use prominent controls that are clearly visible.

People will navigate your app at different speeds. To make sure everyone can complete tasks at their own pace, avoid timed interactions.

Redesign experiences where UI or views disappear or change state automatically after a timeout. Give people the time they need to be successful in your app.

In Assistive Access, design experiences that guide a person through a selection process. Build an incremental, step by step flow, rather than presenting multiple options at once. Lead your audience in a reasonable number of steps, avoiding lengthy setup processes that detract from the experience.

Note to add customization that builds slowly and deliberately, you may need to reorder where certain decisions are made. The aim to is ensure decisions are processed separately, which in turn reduces cognitive strain and leads to a more pleasant app experience. There are some important actions that may be difficult to recover from, like deleting a photo. Consider removing this functionality entirely, or if you do plan to implement more permanent actions like deletion, ask twice for confirmation where appropriate. The goal is to make sure that people don’t end up in a situation that they didn’t intend.

You’ve learned best practices to build great interactions in Assistive Access, such as reducing the presented options, supporting prominent UI, and avoiding timed interactions. You’ve also learned to build incremental, guided flows and to reconsider how and where destructive actions are implemented. I’ll apply these same design guidelines to my app.

I’m adding support to draw with color in my app’s Assistive Access experience. Outside of Assistive Access, a stroke color is selected with the color picker.

Some Assistive Access apps may benefit from color picker options like opacity, but for my app, I only need color. this is one experience I’ll tailor.

In the spirit of reducing options, I’ve designed a dedicated color selection view for my app in Assistive Access. It distills the color picker to a single decision: the stroke color. It also reduces the number of colors presented to a select few. To draw with a color, simply tap it.

I’ve added this view in between the option to Draw and entering the Canvas.

This provides a step by step approach that guarantees everyone using the app arrives at the Canvas with a color selected. Note this ordering differs from the color picker implementation, where color selection happens as an option within the canvas. Instead, I isolate the decision to pick a color to a single view that is always presented on the way to the canvas. in my own app, I’ve also removed functionality that could be confusing or difficult to undo. In the canvas view, my app doesn’t support the option to undo a stroke.

In the gallery, there is no option to delete a drawing.

These decisions were made to create a safe and supportive environment that removes the risk of someone performing an action that they didn’t intend to do in the app. A key aspect of Assistive Access is intuitive and understandable design. For some people with cognitive disabilities, mages and icons are more understandable than text alone. This means information should be presented in multiple ways. Rather than relying on text alone, provide visual alternatives to convey meaning when your app is running in Assistive Access.

when implementing controls like buttons and navigation links, include both an icon and a label.

In Assistive Access, visual design applies to navigation titles too as icons are supported in the navigation bar.

implement this in your own app with the assistive access navigation icon modifiers pass an image or the name of a system Image to display alongside a navigation title when an Assistive Access scene is active. Make sure all of your navigation titles have an accompanying icon.

now that you’ve learned how to design for people with cognitive disabilities, adopt the SwiftUI scene and bring your app to Assistive Access. Go through the design exercises discussed in this session with your own app, keeping in mind the goal to refine and focus the experience you support in Assistive Access. And remember, the best source of feedback is from your audience: find opportunities to test within the Assistive Access community.

Thanks for watching, and thanks for making sure your app is designed for everyone.