Hello world, my name is Cole and I'm a core technologies evangelist here at Apple and I am delighted to welcome you to the Accessibility Technologies Group Lab at WWDC. Today I'm joined by a panel of experts. These are just a few of the folks that work on accessibility at Apple and we're here to chat about your questions to help you include everyone in your apps experiences. And in addition to those on screen, there's a team of folks behind the scenes helping with the triage of all of your inbound questions. So let's kick this off with a round of introductions. Maybe I'll just ask each of you to introduce yourself and talk a little bit about what you're focused on at Apple. Let's start with Julia. Hi, I'm Julia Sonnen. I'm the product marketing manager for accessibility. So I'm in the worldwide product marketing group. And I cover basically all of our accessibility features across all of our products. Great. Hey, everyone. My name is Drew. I'm a software engineer on the accessibility team. I work on iOS, VisionOS, iPadOS, and yeah, across different disciplines in accessibility with a focus in cognitive. I'm Greg. I am a manager for a software engineering team that works on a lot of the different accessibility products. I'm also a user of many of our low vision products. Hi, everybody. I'm Sil, and I am part of the software engineering accessibility quality team. I'm a voiceover user myself and spend a lot of time testing voiceover and braille. Great. Well, thank you so much for joining me, everyone. So just to kind of kick things off, I think for folks that might be listening and maybe are not familiar with everything in the 27 releases for accessibility, maybe we can just start by talking about what's new. Julia, I know you are just on the tail of GAD and all of the announcements that folks might have seen on the Newsroom site, but do you want to just maybe chat about some of the folks that people can find in the new releases? Absolutely, yeah, and for anybody who hasn't checked it out, I would definitely recommend going to Newsroom, and there's a post from Global Accessibility Awareness Day, or GAD, May 21st. It's the day of GAD, but I think Newsroom came out on the 19th, but anyway, it's a really good summary of all of the amazing accessibility stuff that is now, or is mostly in iOS and are 27 releases. So it's a really good year for accessibility. I mean, I've got to say that, right? I'm the marketing person. But we had a huge push around Apple intelligence and bringing Apple intelligence thoughtfully and purposefully into accessibility features in ways that make sense for our users. So we have voiceover image descriptions and live recognition enhancements. We have more personalized accessibility reader. We have an intuitive voice control. And then we also have some other cool intelligent features like automatic subtitles in personal videos. Awesome. What's your favorite? I got to say, like, the subtitles for the features or for videos. I take a lot of pictures or a lot of videos of my kid. And so sending those videos to my parents and having the subtitles on there because they're always like, what is she saying? So now they can kind of see that. And it's just really special. Totally. That's great. Maybe I'll pitch it to the rest of the team. Is there anything, even if it's not brand new in the 27 releases, but anything that's relatively recent that you're really excited about? I'm super hyped about vehicle motion cues. I have them turned on on my phone, and then it being brought over to Vision OS this year is just super cool. Having them be spatialized is great, especially while you're wearing Vision Pro. Totally. Greg, Syl, anything that comes to mind? Yeah, I think voice control, the improvements using AI now, where you can describe anything on screen with much more natural language, will be a game changer for users. I am so thrilled about the built-in image descriptions with VoiceOver that came this year. I had somebody send me a photo recently of myself riding an anteater on a carousel. And so just being able to swipe up on that image with the VoiceOver custom action and double tap, get an image description without having to activate the photo, go to the share sheet, send it off to some other AI model. It's just such a seamless experience now and really helps with me being able to enjoy my photos. That is awesome, and that's great to hear. Okay. Well, I think maybe let's take a look at some of the questions that are coming in from developers. I see a whole bunch, so please keep sending them in. Let's start with there is a question about testing usability. The question is, what is your best advice for testing usability? Accessibility Inspector to audit elements and Device Hub for testing across different screen sizes. Any other advice that comes to mind? When I think about testing your UI with different screen sizes, something that comes to mind first is dynamic type or large text. I think these two things go hand in hand. You want your UI to be laying out dynamically so that depending on the font size the user has turned on, whether it's an accessibility font size or not, sometimes it makes sense to relay out the UI elements in your app. And that also is something that you should be aware of too if you're working with devices with multiple or different screen sizes. So I always think about those two things together. Gotcha. And actually, just on that note, I'll kind of pull this one up because it's really similar. The question is, this is an honest one. On most teams, accessibility testing means voiceover, and then they call it a day. And switch control and voice control and full keyboard access rarely get a pass. How does your team prioritize across assistive techs when you can't test everything? And which one do we most underestimate? So I know you do a lot of testing. What do you think? Yeah, first of all, I appreciate the honesty. I think that is the place where a lot of folks are in. You know, most people don't have teams of experts for every single accessibility feature. And that is still OK. You can still deliver a great accessible experience even if you don't have folks from every single accessibility need on your team. But one really great thing about testing voiceover first is, A, it's approachable. It's a little bit more convenient for most folks generally than obtaining a switch and going through that process. So just being able to turn on voiceover and give that a go. And it's okay if that is all you have the time for, if that's all that resources allow for. Because in many cases, things for switch control and voice control accessibility are also coming from a great voiceover accessible experience. So some of that comes for free. Of course, it's great to test it as well if you can. but if you can only test voiceover, focusing on giving a great voiceover experience will also hit a lot of the other things too. And I think the actual APIs for voice control, for example, they do exist, but it's a fairly small API surface compared to what all of the other assistive technologies have in common. Is that right? Yeah. If voice control works well, most of the other technologies are going to work pretty well in addition to that. the additional API for a lot of our technologies is kind of really nice polish around the edges, really refining that experience, really making it just an outstanding voice control experience or a switch control experience. And I think that matches very similar to what Syl was saying here in that you get a lot of bang for your buck with voiceover testing. And then there's more that you can get adding on to each product. But the first step is voiceover testing. And I think in addition to that, getting real users can really help. It's not required. You can get pretty far testing yourself. But getting input from real users can really help to polish an accessibility experience. Yeah. I feel like I kind of liken it to getting just design feedback from the visual appearance of your app, right? Like you want to listen to your customers and get their feedback. And people using a different interface of your app also have feedback. and you want to include them in your design process. Drew, did you have anything to add to the idea of testing and approaches for that? Just the plus one. I mean, yeah, some of these technologies share literally the same backend API, like is accessibility element or accessibility label. Switch control can read or speak accessibility labels. So, yeah, we try and design the accessibility features to work this way so that, yeah, like Greg said, I love that quote, the most bang for your buck. If you have a great voiceover experience, it tends to mean that the experience for other technologies is pretty good as well. That's great. Taking a look, there's another question. This kind of goes back to the image descriptions we were talking about earlier. The question is, is there any way to override or turn off the system provided description of an image? I have an app that displays artwork. And when navigating, my app voiceover will read my provided description immediately followed by the system's description. I'm using accessibility label modifier on a SwiftUI image. Yeah, I think if you take off the image trait, VoiceOver will stop trying to append its own description to it, and it should just kind of represent your accessibility label that you provide. Gotcha. Great. But if you, yeah, we'll go ahead. I was going to say, it's a really good question, right? It's a question about artists, and there are, and should it be described? And I could go either way, right? For somebody who's blind, somebody that can't see it, the description that the author created is probably a really great description, but still having it described literally with AI could also be really helpful for someone who's blind. I think it's a tough question to what is the right decision there for in that case, or probably in many artistic cases where we don't want to infringe or hinder the artist's creativity. But some of these features, what we want to do is let somebody who has a disability experience that art as well. And for somebody who's blind, the way they can experience it might be through these image descriptions. It might be through some of these AI tools. Might be some of those additional things for them to experience the art. So do you have any thoughts on that? Yeah, because, I mean, keep in mind that after your own alt text reads, there is a teeny tiny little sound. It's pretty subtle, but it is on by default and it happens before the auto generated description pops in. So the user will know that that's not the one that you provided. And sorry, Drew, I don't mean this in a bad way. But if you do take the image tray off of it, that would deny the user to be able to access the new image description stuff because we do rely on that. And there is some functionality in there that lets the user ask further questions about the image and things like that. So they might want to be able to get a little more out of it. Fair. Very fair. Sorry. No, that's awesome. Thank you. Seeing a question here that kind of goes back a little bit to some of the stuff that you were talking about, Julia. The question reads, I'm a third-year medical student building an EHR for underserved areas. Part of it is a patient portal. I was wondering what new accessibility technologies and features announced at WWDC would be helpful for patients that I can now fold into the development from now? I can try to attempt to answer that one, and then you guys back me up with technical details. So I think Accessibility Reader is potentially a really great tool here because it's a system-wide tool. You can launch it from any app and customize a reading experience. It's really meant for any long-form content. What I personally like about Accessibility Reader is that you can kind of have a setup, a style that you like, And then just any given text, like from mail or from Safari or from pages even, like you can just view that how you like it. And it's also integrated with spoken content, which is super cool. The other one that comes to mind is image descriptions and image explorer. because if there's charts and data that are in this portal, then those tools are really great at not just describing photographs and pictures, but also data-rich images and charts. Gotcha. Yeah, and just more generally, even if it's not the new technologies, I think I kind of read, and I hope I'm not misinterpreting this question, But I kind of also read this as like, where do you start? Like, you know, if you're working on a very data rich, complex app, it can sometimes feel a little daunting to figure out how we're going to make sure that that provides a great experience with voiceover. So do you have any thoughts on kind of like what are the first things that come to mind as steps when you're like embarking on that project? And you want to make sure that it works well with the wide breadth of assistive technologies that are available. That's a hard question. You're right. There are a lot of different technologies. I would probably suggest starting at dynamic text. I think there's just so many people that use dynamic text and so many people that can benefit from being able to increase the font size in many different applications. And then from there, as we were talking about earlier, voiceover support gets you some big wins. And so dynamic text kind of gets your feet wet, and then you continue on to adding accessibility labels and continuing to refine your application with voiceover support. Any other thoughts? No, that's great. That makes total sense. And I think I'm just kind of looking at the other questions here. Let's move on to the next question because I will come back to that. I have another question from a developer that is also a voiceover question, and it reads, in many places in my app, the user taps a button which triggers a network request. For sighted users, I show a progress view in place of the button, then replace the content of the button. How do I make that accessible to users of iOS voiceover? I'd like voiceover to announce the action completed. Any thoughts? You can use the notifications that we have a few different accessibility notifications. Two of them are similar. One is going to be layout changed. The other is screen change notification. And this tells voiceover that something in the app layout has essentially changed. And maybe it's like a visual only change. And you can use that to, I think like layout change is usually for smaller UI changes, whereas changes, something like the whole screen is changing. So I think if a button layout is being updated while the voiceover cursor is focused on it, layout change is probably the best way to do it. You can even pass in an accessibility element to bring voiceover focus to that element, but you have to be careful that you don't do that too often. You can imagine that someone using voiceover doesn't want their focus to be pulled in a bunch of different directions. But you could also do the accessibility announce notification, which you just put in a string, and VoiceOver speaks the string. So that could be another approach as well. That's a good idea. Great. I think this will be a pretty easy question. The question reads, are there any updates to the text-to-speech APIs this year? I'm not aware of any. Are you folks available-- aware of anything? I know there's a lot of improvements on the back end, but I don't think there's new API. Gotcha. So for folks listening that are looking for some improvements, those are some great feedback requests to file. That's great. Okay, I know I want to kind of circle back because we were talking about dynamic type a little earlier. And I know one of the big features this year is that dynamic type is now available on tvOS. So I'm really interested in your thoughts of, like, what does this look like for maybe our tvOS developers listening? What should they be thinking about, and what does that work look like to get ready for dynamic type? I think a good thing would be to start being familiar with what the best current practices are for large text, like what a good layout would be, kind of like we mentioned earlier. Sometimes the flow of the UI in your app should change if an accessibility font size is enabled. And we have a new WWDC session this year by ECS talking about large text and TVO specifically. So that's a huge recommendation to check that out for sure. We also have other previous talks about large text too. So you can start with iOS. You can graduate to tvOS or get your feet wet with tvOS right away. Gotcha. And I think that means we get a nutrition label, the ability to do a large text nutrition label for tvOS. So that's super exciting. Totally. So actually, since you raised that, I do see a question about accessibility and nutrition labels. The question reads, we are very excited about the accessibility nutrition labels. Please talk about how valuable they are and any details you would like to expand on. Oh, my goodness. Well, it's near and dear to my heart. So accessibility nutrition labels are a way for users to find out about the accessibility of an app before they download it. And it's also a way for developers to connect with their users in a new way. And we have, you know, if you go back in previous dub dub sessions last year, we had a really good one. And just on how to kind of prepare your apps and evaluate them for nutrition labels. I just, you know, I get to go out in the world and talk to, you know, community members and users. And I was at a conference this year and a guy was so excited to come up to tell me. He pulled up his phone and he pulled the app store up. And he's like, we did it. I got my nutrition label. And it was actually for like a large, I'm not going to say who it is, bank. And so what was cool is because of the nutrition label and this concept, he was able to use that as a way to advocate for getting, you know, kind of that support within his company to make this happen. And that just, like, gave me warm fuzzies. So that's, I think, my favorite nutrition label story so far. Yeah. Oh, go ahead. I think it's a really big game changer, both for developers and end users. If you can imagine, for me, for someone that uses a lot of large text and Zoom, but also for a voiceover user, downloading an app without that information would be like downloading it without knowing if it's in English. They're just gambling at that point. And so it's a really big win for customers for them to be able to know if their app's going to work with the assistive technologies that they use. In addition to that, I think it's a really nice way for developers to distinguish themselves, to say, like, hey, I actually put in the effort here. I care about all these different features. I put in the effort, and now they get those nice little badges for their applications. So I think it's so many wins all around. I totally agree with that. And as a user myself, I cannot even tell you how many hours of my life I've spent downloading apps that aren't actually accessible, trying them, deleting them. Then sometimes I even need to try to get a refund if it's something that costs me money. And just being able to know right away if an app is going to work for me is, as Greg said, it's a huge time saver. And it just really reduces the cognitive load that exists as trying to navigate a world that might not always be designed for me. Totally. And I think one of the things that I really like as a developer about the fact that they exist is that they come with guidelines. They come with kind of like this is the criteria that I should be testing against. And that's that's a I think that's a great benchmark. Like you said, like, you know, having that like documentation, that guideline to go champion this work before you add those labels to the store. I've heard from developers tell me as well that just having that documentation is a great motivator to kind of get the testing done and kind of reevaluate the app and then make it even better. So that's great. Okay, I'm going to take a little bit of a detour. I see a question about Device Hub. So I'm going to bring this up. The question is, I was very excited to see that there's a voiceover option in the Xcode 27 beta device hub and was disappointed that when I tried to use it, it didn't do anything. There's a feedback number here. Is it intended to work on simulators or only on physical devices? Is this the year that we can test iOS voiceover on a Mac? Do we know? This could be a bug, but I'm curious if you know if this is expected. So I do have a little bit of information here. Probably not the whole story. I think it's a really good question maybe to bring to the forums coming up. There is a new XCTest API so that from a Mac you can test VoiceOver on your iOS device. And to the best of my knowledge, it should be working in the simulator. And so that you can check out in Seed1. That's the 10,000-foot view that I know. The forums are probably the best spot to get some more information and some specifics. - Gotcha, well we have an accessibility forum Q&A tomorrow so it can be brought there, but we will also take note of the feedback report, so thank you for sending that in. Okay, continuing on, there's some questions about voiceover, so I'll try and bring those back up. This one is about macOS. So the question is, we're adding voiceover support to our macOS app. With this year's accessibility updates, is there anything we should revisit? And what's the recommended way to test accessibility across different assistive technologies? I know we talked about the latter a little bit, but maybe specific to the Mac. Any thoughts? I think the Mac, one of the biggest differences from iOS is user expectations. A lot of times on the Mac, users are multitasking. They're doing more things when they're using VoiceOver. And their expectations are a little bit different. And so the best thing you can do is get some real user feedback. Get some feedback on how users are using it. get feedback from the field on how your app is used, what would really accelerate somebody in using your app. And those accelerators, I think, are really important. A lot of the things that we do that we hear from users for voiceover functionality of the Mac are more hotkeys, being able to jump to different sections of the app, being able to jump to the inspector quickly, being able to jump to the sidebar really quickly. And so there are things that aren't really voiceover or assistive technology API that you have to implement, but general app features that just really enhance server experience because of those higher-- the higher expectations of accelerators, I think is probably maybe the nerdiest term to put it. But we expect there's a lot of hotkeys. There's a lot of really intricate shortcuts on the Mac. So I think that's probably the biggest difference to think about. SIL VARIAN: Gotcha. SIL VARIAN: So I saw you nodding there. Do you have anything to add? SIL VARIAN: He made me really excited when you mentioned the extra keyboard shortcuts, because those don't just benefit voiceover users. they also benefit all of the Mac power keyboard users that exist out there, and there are many. Gotcha. But in terms of the question around is there anything different with regards to the new voiceover updates, I mean, you just get them all for free, right? There's nothing. You just now get image descriptions, which is very exciting. I'll also quickly add, part of the question was, what's a recommended way to test different accessibility features? I'll say the accessibility shortcut is a really powerful way to be able to turn on and off accessibility features without having to go in or out of settings. So don't be afraid of, like, if it's your first time turning on VoiceOver and you don't know how to get out of settings back to your app, if you add VoiceOver to your accessibility shortcut, you can triple-click to turn it on and off, and it should be pretty easy. It's my favorite development tool, and I love to share it with everybody. And on macOS, you can even just turn it on with Command F5. Easy peasy. Excellent. And the accessibility shortcut on macOS, if you have Touch ID, it's triple press on Touch ID. And you don't need to, it's a little bit different than iOS. On macOS, you don't need to configure it. So out of the box, you can triple press Touch ID. And it'll bring up the accessibility shortcut with all the accessibility options in it. That's cool. If you don't have Touch ID, it's Command Option F5. Command Option F5. Okay. All right. Just on the theme of macOS, I have another, I have an AppKit question. Everyone's favorite topic. For custom AppKit controls with context menus, hover actions, and custom buttons, what's the right way to expose these so that voiceover users can actually discover and perform the same actions as mouse users? There's quite a few ways that you could do it. Probably the default answer that I'd give is custom actions. Custom actions have a few drawbacks, though, especially on the Mac, because they're not as common. And so users tend to skip them. So they're really, really great for-- again, we were just talking about kind of accelerators or pro features. I think that you might want to think about some different solutions if they're really important hover actions or really important things. Some of those might be making additional buttons. One of my favorite APIs in SwiftUI is accessibility representation. And with accessibility representation, you can take a SwiftUI view and say, ignore everything I did in that view. Here's how to expose it to accessibility. So you can have one button in SwiftUI, and then in accessibility representation, expose that as four different buttons. So perhaps that's a bit off topic, since the question was about AppKit specifically. You can do the same thing in AppKit. It's just a little bit trickier. What you would do is implement accessibility children, then create your own accessibility elements. A few other ones would probably be thinking back to our previous conversation, too, is what are some hot keys? What are some other actions? Because thinking about users that aren't voiceover users, too, how is somebody that is a pro user that's not always using their mouse around going to get to these as well? And also, we try to think about really carefully what's on hover actions because it can be really hard, too, to find for somebody with a cognitive impairment. You have to really search around the UI. It's not something you can just sit and look at and know how to use. So we try to use them sparingly as well, and only in cases where it might provide a secondary action or secondary enhancement to the app. Do you have anything to add, Drew or Sil? Just a plus one to the cognitive aspect. I know it's not maybe like the root of the question, but yeah, considering any UI that's hidden or requires a gesture to reveal, yeah, that tends to be difficult for cognitive accessibility. So yeah, just plus one. Gotcha. Just to switch gears a little bit, I think this question is really interesting, so I'm going to jump ahead to this one. The question is, how does Apple design accessibility features for people with limited or no use of their hands or arms, including people with limb differences, paralysis, tremors, or temporary injuries? I can start with the product marketing answer. Well, first of all, we have a ton. And I think it might be a different solution for every user. That's one of the benefits of our vast array of AT solutions is that we have things like changing reachability, which I like a big phone and have small hands, so I love that feature, which is you can swipe and pull the top of the screen down for easy reachability. We also have a whole bunch of different ways to interact with your device that do not require your hands. So we have voice control, head tracking, eye tracking, sound action, switch control, to name a few. And then if you do touch your device but you maybe want to do it in a different way than what's default, we've got touch accommodations as well as assistive touch. And on the touch accommodations note, we actually have a new setup flow for iOS 27 that streamlines it. So currently in the touch accommodations experience, you go into these different toggles and you kind of set how you want it to react to your touch. And now there's a calibration activity. So you tap kind of like actually like training eye tracking. So you tap a target, and then the output of that is a recommended flow. And so that one I'm super excited about because I have a family member with Parkinson's disease, and so I'm really excited about getting her set up with touch accommodations. Anything to add? I really love the on-device eye tracking on iOS, being able to use the built-in camera. We work with quite a few users. And some of those users use external eye trackers, which are incredibly good. They're incredibly accurate. But they're not always easy to set up. And one of the best pieces of feedback that I heard from one of our users was that finally with the on-device eye tracking, they can entertain themselves on an airplane. And it's something we all kind of take for granted, right, that we don't need a complicated setup or a boom-mounted eye tracker. And so now with some of these built-in features for people's mobility impairments, they didn't need help changing the movie or changing the TV show when they were on an airplane because they could use built-in eye tracking. So I thought that was really, really cool. I think the other thing with all of the features, one thing I've certainly learned over my career is everyone is different. And it sounds obvious when you say it, but I think it's easy to say, like, oh, two people with the same disability will have the same solution. And it's very much the exact opposite. You can have two people with the exact same disability, and they will use vastly different solutions. And I think that's why you see such a large swath of different technologies, because we really want to help people to accommodate the device to work for them. So they're not fighting it all the time so that whatever needs they have or how they want to interact with the device or however is most comfortable or however they prefer to do it or might need to do it in a temporary situation like on an airplane, they can set up the device that way. And so we're trying not to make sure we don't box them in to any individual technology. Just as we're talking about kind of different areas of accessibility, there's another question that I think is related. The question is, can you mention some features made with neurodivergent people in mind? Definitely. And I think Drew might have some thoughts on that. Yeah. We have two big features that are specifically for cognitive accessibility. First one is going to be guided access. This is designed to help keep people in a singular experience on the device. So you open up an app, you start guided access. This is great if you want to make sure someone has access to something like their favorite book or TV show or on a FaceTime call with a relative, but without worrying about them kind of leaving that context, getting to other places of the app or other places of the operating system. We also have assistive access, which is, you know, it's like a whole different visual language compared to traditional iOS where things like we have big icons, we have larger default text size, larger touch targets. And the idea is that we really simplify the user experience in an app to be kind of like the core controls. You know, recently we just brought a TV app to assistive access. So you can imagine that it's like a library. You tap on a TV show or movie that you have downloaded and you get a play pause button and a back button. And it's like, you know, we're still providing all of the great value that Apple TV app will bring, but makes it accessible to people with neurodivergent accessibility needs. And so, you know, this is something that we try to do for multiple first-party apps, and we also have APIs for developers to create their own, like, fully optimized version of their app for assistive access. I think we have a session on that from last year, right? We do, yeah. We have a few assistive access ones that will be good to check out. But on top of those two features, there are also other features across iOS that we've found to be helpful and that people in these spaces use, like screen time. Speak screen is one of my favorites because speak screen and speak selection and accessibility reader because you can have text-to-speech read certain snippets of text and it does different word highlighting. Yeah, I think we've got a lot here, but if you have other ideas, I think we're always looking to expand this as well. That's awesome. Great. I'm going to kind of go back. We kind of like went away from the APIs. I'm going to bring it back to the APIs a little bit. There's a question about actually some of the new API surface available in SwiftUI this year in the 27 releases. The question is, SwiftUI has a new reorderable modifier. How do I make that accessible to voiceover? Dragging and dropping is not an idiom in voiceover. Any thoughts? I'm not actually sure if this works yet in the beta with voiceover, but any thoughts in with drag and drop interactions? - What platform, I wonder? - The platform is not specified, so we can guess. - Sounds like it might be a great question for the forums. - Great, excellent. - The experience does vary a lot between iOS and macOS. I kind of suspect they might mean macOS 'cause iOS drag and drop definitely works really well. On macOS, I think there might be some other things for it not to be squarely sometimes. Okay, very good. And another question about some of the new releases. The question is, I'm not sure if this is actually yet available, but I'm going to pitch the question. The question reads, would love to learn more about the new FaceTime video interpreting feature announced at WWDC. I'm curious how third-party apps can integrate, specifically how the interpreting session is initiated and whether there are any entitlements or API restrictions to be aware of. I think, correct me if I'm wrong, but I think that feature is not quite available in the iOS 27 beta. Is that correct? Correct. Right. So stay tuned. More information coming when those APIs are available. Okay. Let me take a look at some of the questions that I am seeing. Here's one from another SwiftUI question. The question is, for custom SwiftUI reusable views like labels, icons, composite wrappers, what is the recommended way to expose stable accessibility identifiers for UI tests and the accessibility inspector without misusing the accessibility label? I think two things that I tend to do in a lot of the projects I work on are for those reusable things like label or button is I make a wrapper around it that requires whoever uses it later after I make it to provide an accessibility identifier and an accessibility label. And then I add checks as well, like don't allow a nil accessibility label. And then that way it kind of enforces anyone that comes after me that's reusing the shared view to add the accessibility information. And in that case, what that means here is every time you use it, someone would have to provide a concrete accessibility label for it, which can really help for testing. And now you have something that's really stable throughout your code, throughout testing. And I'd also encourage you to, especially when you're using symbols and buttons, require somebody making one of those buttons to provide an accessibility label as well, in addition to the identifier. Great. I'm going to, I think I'm not seeing any other big Swift UI ones, so I'm going to bring us back a little bit. There's, I think, a really interesting question, and so I think you might have some thoughts on this. At the beginning of an app design project, what process do you recommend for making sure that accessibility is built in from the start instead of bolted on later? I'm curious how that moves from UX research and wireframing into Swift development, testing, and support for different assistive technologies. That is a really great and nuanced question. Yes. I'm sure other folks here are going to have some things to chime in about as well. But I can just say the fact that you're even asking that question is putting you just miles ahead already because a lot of folks don't even know or think about accessibility until the app is already pretty much done and dusted. And by that point, it is tough because then you're just trying to kind of tape on some accessibility over the top. and that experience is never going to be the same as if you had designed from the ground up with accessibility in mind. So just thinking about it from day one and it doesn't need to be the main focus but just everything you build, checking it out a little bit with voiceover and kind of learning about how a user of maybe a couple of the different assistive technologies might use a similar app if you can think of anything that's already been done success. That can be a great starting point too. And if you have the resources for usability research, as you mentioned, do it because people are always, they're going to have things to say and they're going to have great suggestions for you that you might not even thought of. How do you, how do you do that in a big team though? Cause I can imagine the larger your team grows, the harder it is to kind of like propagate the importance of being focused on accessibility throughout the design process. How do you, and maybe, I know this is intentionally a tough question, so there might not be an answer here, but how do you kind of re-inspire everyone to kind of be focused on that throughout the entire process? You know, something that has really worked well for me has been just showing developers what's going on for me as a user. So, you know, if I'm working on a really big project And I need to convey, hey, I think we might really need to give this app some accessibility love here pretty soon before we go much farther. Sometimes, you know, just saying that, it's possible that that might not be enough. But showing them, going over and showing, hey, I'm a voiceover user. I'm touching this thing. But my phone is just saying literally nothing. I can't touch this at all. Just bringing the human connection. it really shows folks, oh my gosh, I don't want this person to be blocked out of being able to use my app, I want them to use it. I mean, we're not, folks are developing things because they want people to use them and enjoy them and that applies to everybody. - Totally, and I think one of the things I'm hearing you explain there is like the importance of iteration, right? Like all software goes through iterations and like that should be part of the iteration process is making sure the like, you don't want two weeks of accessibility we'll figure out at the end of the project, right, but in building that into every iteration. I think a few other things that you can think about in a planning process in any company is often you have different categories that you're thinking about. You're thinking about your main app. You're thinking about, well, what about the security implications? What about the privacy implications? And if you can add accessibility into that list, it can really help as well. And that can elevate it up to everyone involved in the project that, yeah, accessibility is one of the things that we care about in this project, amongst lots of other important things. And it's a key thing that's going to be part of the project. It's part of the conversation as we go through the design process. Then when you get to engineering, I think going back to how-- we talked a little bit earlier about making wrappers. Like, how do you force the design process then once it goes into prototyping? How can we force some of those prototypes to have some accessibility in them as well? And then lastly, I think still highlighting, absolutely, you have to think about it through the whole process. But also, you always need to make room at the end as well to really refine it. Because we all know prototyping moves really quick, and design process moves really quick. And you can end up wasting a lot of time if in the beginning you say, oh, I want to now make the voiceover experience perfect and really streamlined. And then the UI changes, and then you go back to voiceover. And so you absolutely need to think about it and have some basic things working. But then I think making sure that you have time at the end to say, all right, now we're going to sit down and before, well before our ship date, we're going to really refine that voiceover experience. We're really going to fine tune the dynamic text experience now that all of our views landed. Now that everything is solidified a little bit more, we can really make a really great experience for customers. And I think one thing that comes to mind is our colleague Ryan did a tech talk recently about preparing your app for accessibility nutrition labels. And one of the examples he gives is the design of Control Center and how when you have larger text enabled, the size of the controls actually grows to accommodate the larger text. And I think that's such a great example because that is like it's kind of a two way street, right? like in implementing dynamic type, making sure that works, it also kind of changes the behavior of the UI itself. And so like you have to kind of do that early. That's not something you want to like discover at the end of the project. Just one other thing. I think from like a higher level planning conversation, it's important to like as a feature development is ongoing and you're weighing different priorities against each other, a lot of times I think people tend to use like metrics in a certain way, like utilization, like what number of people would benefit from this. But I think it's also important to think about criticality to users. And so just making sure that the way that you're evaluating and trading different features in this kind of larger conversation isn't just about like the bell curve, right? And so understanding like what is the – not necessarily the number of people but like how big of a deal is this for users that just kind of making that part of the open conversation. Totally. Yeah, and I'm going to pivot a little bit back to the technical side a bit. But I have a developer here asking a question about kind of building a product that spans all of our platforms. And so the question is, there are a lot of resources on accessibility for iOS with less resources tailored to some of the other targets. Are there any platform-specific pitfalls that you can recommend to look out for when developing a universal app? So for macOS, iPadOS, watchOS, tvOS, et cetera, that might not be obvious if you're just coming from iOS. I think one of the things, accessibility aside first, is acknowledging to really deliver a great customer experience, you're going to need to test it on each platform. If you just make an amazing SwiftUI app, it works on iOS, there's probably going to need to be some things that you're going to tweak to work on iPad. There's probably going to need to be some things that you tweak to really make it a great Mac experience. And so along those lines, accessibility would be very, very similar. that when you're testing VoiceOver on iOS, you're probably also going to need to quickly fire up VoiceOver on macOS and test out your application. Because there's little nuances. And as we talked about a little bit earlier, there's also different user expectations, where the Mac users might expect more keyboard shortcuts and the iOS users don't have that much of an expectation. On iOS, hit testing is far, far more important for a VoiceOver user than it is on macOS, where accessibility children order is much more important. So they're just like SwiftUI in general and cross-platform deployment in general, where it's a huge time saver. It's great to be able to do that. But there are some nuances where you will need to test each platform individually. Yeah, and there's like the small nuances of like how people navigate the different interfaces. There's also screen size, right? I mean, like for dynamic type, that makes a big difference. But I'm also thinking about, like, are there specific interactions maybe for them? Like, one of the things I think about is on the watch, you have, like, the digital crown, and that's a whole interaction that you need to consider. Are there other kind of, like, top level, like, this interaction is very different, so pays special attention to it on other platforms that come to mind? A lot. Both an easy question and a hard question somehow. I think the answer is yes, right? On the Mac, you always have a keyboard. And that's one of the things that I think about a lot. You always have the keyboard, and users expect the keyboard to be super, super functional in your application. If you're on tvOS, you have no keyboard, and you have no touchscreen, and you just have the remote and linear navigation. If you're on the phone, then you don't have a keyboard, and you have touch-based navigation for many of our apps. And so a lot of the same principles will hold true. But again, it's coming back to how do you create that great experience for customers. If it works on iOS, it'll probably work on Mac. If it works on Mac, it'll probably work on iOS. But it's not going to be really fine-tuned and provide that really great experience. Again, coming back to just like Swift UI development, you're going to need to do a little bit of tweaking on each platform. So keyboard, touch input, Vision Pro input. I can't think of the name of I guess that's still touch input maybe and the mouse and trackpad input as well for different modalities and different users and then as we talked about earlier as well different mobility impairments so if you have somebody who doesn't have arms or only has one arm or can't use their arms the keyboard is not quite as important to them and they're going to use something like eye tracking and so their experience is also going to be different and so then depending on the disability you also now have more limitations or different hardware that may or may not be available. Yeah. And so I'm kind of interested in your perspective on this because I know you do a lot of testing in your day to day. Like, are there certain, we've said the word expectations a lot, but are there certain expectations that are specific to the platforms that you specifically look out for that might be worth calling out? I think Greg landed on most of them. I guess the only other thing that comes to for me is all of the grouping that is possible on Mac OS that can really, really make keyboard navigation much more efficient. Just determining on kind of which elements are grouping together. Even kind of going back to our conversation earlier about the, when we were talking about what one should do with a bunch of buttons, for example, like actions or something like that on Mac, you might even consider doing like grouping them together so that when a voiceover user moves through, they land on each main item, like each card, so to speak, maybe, and then they can then interact in and find what's in there. So it makes it a lot faster for them to navigate. And that is not something that's used on iOS as much, but that's the big thing that comes to mind. Yeah, that's a really great point that I omitted, that navigation with voiceover on the Mac is very hierarchical, whereas on iOS, it's very linear. And so grouping is really important on the Mac. For simple apps, not quite as important. But if you can imagine a complex app like Final Cut Pro that might have hundreds of controls on screen at once, to have to navigate linearly through every single control one at a time can take a really long time. And so grouping them can be a make or break thing for a voiceover user. And again, that kind of like, is it usable if there's no groups and everything's just linear? Yeah, it's usable, but it's a really poor experience. And the groups then also will benefit iOS. iOS has commands to jump to the next group as well through the rotor. And so all of these things, again, will help all platforms, especially when you're developing cross-platform with SwiftUI. Yeah. And I think we had a great session, not this year, but either last year or the previous year, on improving Mac accessibility. And there's an example of kind of an inspector pain. And you can kind of see, by default, without any grouping, just how long it takes to navigate through that inspector through all the different selectable items there. So it's a great session if you're interested in improving your Mac apps accessibility. Yeah, it's a challenging problem, too, because you can have too many groups. If you're thinking about a hierarchy, you don't want to be too deep or too wide. You need to find that right Goldilocks balance in between for users where it's not overly confusing in either direction. Yeah, totally. A little bit of a different question. Maybe this one's for Drew. The question is, with these new improved AI voices, will any of them be available for voiceover? Yeah. I mean, so I can have Sil help me out here too. But, you know, the voices that are being used on voiceover, we specifically tailor them and tune them to be used for screen readers. And so, you know, Silk can probably attest, you know, when people are using voiceover, they tend to have the speech turned up pretty fast. What would you say? Generally. Yeah. Great. And let me just jump around here a little bit. So here's an interesting one. I don't think I've gotten this question before, so I'm very interested in your thoughts on this. The question is, besides manual testing, how do you prevent accessibility regressions? What about approaches like accessibility snapshot testing or automated UI testing with accessibility assertions? I think the easiest answer to that is automated testing, because XC test and specifically XC UI test relies on the accessibility hierarchy across Apple's ecosystem on all platforms. And so if your app is not accessible, your XC tests are going to fail. I think in addition to that for your XC tests, you can also add things like checking the accessibility label. You could even add a test to say make sure there are accessibility labels of UI. So I think the core is just that automated testing gets you 90% of the way there. Outside of that. And is there new testing API for voiceover this year? I think there's something. There is. We talked briefly about this earlier, where there is a new API. I don't know it off the top of my head. In order to actually start up VoiceOver and navigate VoiceOver element to element to element. And what you can then do is validate that VoiceOver is speaking the right thing and getting to the controls. And so depending on your app, you could probably also use that as a smoke test to say, can VoiceOver get to nine elements on this screen? Does VoiceOver get to any element where it doesn't speak anything? Things like that. Gotcha. All right. I see a question here that's getting upvoted. The question is, I'm a blind iOS developer. Are there any accessibility improvements in Xcode and developer tools in general this year? Oh, I can say something. Yeah. Okay, so we actually did work on that. I'm super happy about this. We improved terminal accessibility in some really cool ways this year. So voiceover can now, it's much better. You can move to visible beginning. You can access Marks better now. You can, it now better reads tab autocomplete suggestions. And there's a handful more that I'm sure I'm neglecting. But terminal accessibility, that is something that we are working on. If you have more feedback to share about that, please do so. And then we are working on possibly some things for Xcode. More to come with that. Please keep an eye out. Do you have anything to add, Greg? Yeah, there's lots of great bug fixes in Xcode right now for voiceover that you'll be able to see in seed one. In addition, it might be seeing the obvious. I think SwiftUI is a real game changer for voiceover users that are also developers. Because gone are the days where you had to use the WYSIWYG interface tool to build your UI. Now it's really a level playing field. Everyone is defining and editing UI in code. And so I think that's a huge kind of even overlooked benefit of doing SwiftUI now that it's not – that somebody who's blind is editing and doing the same thing as all of their peers. And in addition to that, there are a bunch of rotors. I don't think any are new, but there's a lot of rotors for Mac voiceover in Xcode that allows you to quickly jump between different methods. You can even jump between errors and warnings in the same file and jump between variable names, all kinds of things. So it's a pretty robust solution for voiceover. But I think there's still a bit of work, so we'd love to hear from customers on what we could improve and how we could make that better. AI also, I think, is going to be another game changer. I think we're all still learning a little bit about how it's going to change our industry. But you can imagine now a lot of what might make a sighted programmer more efficient is their ability to quickly scan code. And now with AI tools, its ability to scan and summarize code is really leveling the playing field for somebody who might struggle with that either because of vision or because of a cognitive impairment. And so I think we're also going to see more opportunities arise because of AI and what you can do with that. And so we're really looking at ensuring that the AI experience is really rock solid for voiceover in Xcode. In addition to not specifically this question, but to plug some of the work that we did, there's some really awesome new AI skills in Xcode to help make your application accessible for both voiceover and dynamic text. And how does that work with the coding assistant? Do you just ask, hey, help me improve my voiceover experience? Yep. In C2B1, there's two skills, one for voiceover, one for dynamic text. And so you can say things like, make this view accessible for VoiceOver. Make my app accessible for VoiceOver. What's wrong with my file with regard to VoiceOver? And it'll help edit your code. It'll provide you suggestions. It'll tell you what's wrong. So it's really a culmination of a lot of the internal knowledge from Apple engineers on how we make apps accessible boiled down into a quick skill that can really, really help developers. That's great. I'm going to go try that out. And looking at the clock, I know we don't have a ton more time, but I thought I'll pick one more question because it's about a platform that we haven't talked about so far, which is Vision OS. And so the question is, for spatial computing tools that use eye tracking or gaze, such as Vision OS and eye-based interaction, how do designers avoid assuming that all users can rely on visual gaze as their main input method? Yeah, we have different accessibility features on Vision OS, kind of specifically to not answer the question, but to be appropriate here. One of them is called pointer control. And so instead of using gaze-based interaction or hands, you can use different parts of your body to be almost like your pointer instead of your eyes. So we have one that's based on your head. We have one that's based on your finger. You can use kind of like your wrist as an anchor point as well. and not to plug my own WWDC session, but me and my teammate Dan worked on one when we shipped Vision OS and we talked. It is very, very comprehensive. If you haven't seen it, you totally should check it out and we cover some of this specifically. It'd be good to talk about. Yeah, and I think there was a question that I don't think we got to, but there was a question about how do you make reality content, reality kit content accessible and that's actually covered in that session. We have an API for that. Yeah, definitely. Awesome. There's one more that I just want to shout out here. Not so much a question, but I want to share it with the team. It reads, just would like to thank the whole team so much and point out that assistive technology is for everyone. I myself, without any disability, so to speak, use voiceover and dictation all the time and love it. So thank you so much. All right. Well, I think that's about all the time we have for today's group lab. I'm so thankful that you were able to join us today, that all of the folks listening today were able to join us. I hope you found today's conversation helpful. And thank you to all the folks working behind the scenes to make today happen. If we didn't get to your questions, please visit the developer forums at developer.apple.com slash forums, including the Accessibility and Inclusion Q&A taking place tomorrow. That's Wednesday at 10 a.m. Pacific. If you have a bug or an API request for us, please send those our way at feedbackassistant.apple.com. And to make a request for an enhancement or share your story using the accessibility features of Apple products or offer other accessibility feedback, you can email us at accessibility at apple.com. And try out the new AI search experience at developer.apple.com to get answers about frameworks, design, accounts, and everything related to development on Apple platforms. And speaking of feedback, you'll receive an email with a survey link to let us know about your experience at WWDC. And we would love to incorporate your feedback into future events. Thanks again for joining us, and have a great WWDC. Thank you.