I started my journey in iOS accessibility about 9 years ago, when I was working at the BBC. I even dared to give a talk about it in App Dev Con in 2018. Years later, I’m pretty sure that I was just able to overcome my terror of public speaking thanks to the Dunning-Kruger effect. I was at that point where you’ve just started learning about something, become passionate about it, and vastly…
Starting something new: The Advent of iOS Accessibility. Twenty-four days of exploring some of the most common accessibility issues I’ve encountered, how to identify them, and—most importantly—how to fix them. Hope you enjoy the series!
You may know that you can configure a UI component with an accessibility label. The accessibility label is the name of the component. You can also configure an accessibility trait. The accessibility trait is the role of the component, it gives the user information on how they can interact with it. When using VoiceOver, the trait is usually vocalised after the accessibility label.
The cycle for creating great accessible apps starts and ends with testing. Sure, it is always better to get feedback from users to create an experience that holds up to their expectations. But that’s not always possible. Till you can do it, I think the way to go is to do your best. Build it as well as you can, then gather all the feedback you can get, apply the suggestions, test, repeat.
I know, iOS 13 has been with us for quite some time now, WWDC 2020 is just around the corner and we hope Apple will present again a ton of new accessibility features and improvements coming with iOS 14.
Apple introduced iOS 11 at their World Wide Developer Conference (WWDC) in June 2017. WWDC is Apple’s showcase of new tools and developer APIs covering iOS, macOS, watchOS, and tvOS. In this post we’d like to show you what’s new in accessibility in iOS 11, and how you can incorporate these features to make your app more accessible to your users.