RSS Newsfeeds

See all RSS Newsfeeds

Global Regions

Global Regions ( XML Feed )
United Kingdom ( XML Feed )

May 29, 2015 3:52 PM ET

Archived: Inclusive Toolkit: tools for iOS & OS X app accessibility : The Inclusive Toolkit is a set of tools to help iOS & OS X developers quickly and easily make their apps inclusive and accessible.

iCrowdNewswire - May 29, 2015


Inclusive Toolkit: tools for iOS & OS X app accessibility

How much time do you spend on your iPhone or on your Mac? Would you say it’s essential for you? It wakes you up in the morning, it gives you the news, it can pay for your coffee, it helps you get to work, and it enables you to do your work. It connects you with the people who matter most to you. But what if you couldn’t do any of those things?

Here’s the problem: Disability affects 1 billion people worldwide. That’s 1 in 7 people. For these people, the apps we use, the apps that enable us to do more, the apps that let us communicate, are often unusable.

My name is Sally Shepard. I’m an iOS developer and accessibility consultant based in London. Over the past six years, I’ve worked on apps that have been used by hospitals, installed in galleries, and named ‘App of the Year’ by Apple. I speak internationally about accessibility, development, and user experience, and am actively involved in the iOS and Mac development communities.

Testing every possible accessibility need is time consuming. If you work in a small team or you’re time constrained, how can you do it? What if you could quickly see what’s broken or where something could be improved? I’ve developed some solutions to speed up accessibility testing, make it part of your workflow and help you better understand the user experience. I’ve called this collection of tools the Inclusive Toolkit. I want these tools to be free for everyone to use—that’s where I need your help. By backing this project you’re enabling me to build them and provide them free of charge.

 I want to focus on making apps ‘inclusive’ rather than just making them ‘accessible’. These two words are often used interchangeably, but with ‘inclusive’ there’s more emphasis on making something for everyone versus just making something for people with a disability. There are many people who don’t identify as having a disability but use and rely on accessibility features. Too often, ‘accessibility’ is seen as a feature or user story instead of being something that all features and user stories should have. When we make accessibility a separate feature, it’s very likely to be left behind. The other reason behind using ‘inclusive’ is when you say ‘accessibility’ most developers think of VoiceOver, which is only part of the rich set of features Apple provides.

The common difficulties around implementing inclusive concepts in apps are a lack of resources, knowledge and empathy. All of Apple’s products have features that enable inclusivity, and they make a huge difference to people’s lives. Anyone developing for their platforms has access to the APIs to make their app equally accessible. 

So how can we fix this? 

From a user point of view, I want the Inclusive Toolkit to help solve two problems: unusable elements and poor experiences. And from a developer/designer/QA point of view, I want it to speed up development and testing time, as well as build empathy. It’s great if you work in a company that already has specific resources and knowledge about accessibility—but for many developers, that isn’t the case. I want to provide ways of making it part of the development process instead of something tacked on at the end.

The Inclusive Toolkit aims to cover:

Simplifying testing:

  • Recreate the UI with ‘Visual Voiceover’ to reveal each element’s accessibility values while hiding elements without accessibility information.
  • Highlight ‘invisible’ UI elements like long animations, unintuitive gestures and complicated view hierarchies.
  • Highlight areas of the app that don’t handle reduced transparency, dynamic text sizing, and other parts of the Visual Accommodations API.
  • Automate production of text ‘journeys’ through each screen and provide guidance on how to simplify it.
  • Automate output of screenshots of the above.

Building empathy by simulating impairments:

  • Provide recognisable representations of the effects of different impairments.
  • Simulate colour blindness.
  • Simulate visual impairments.

Understanding inclusive interfaces:

  • Build inclusive wireframes for the app journey. 
  • Consider parallel interfaces for specific needs. 
  • Use accessibility APIs effectively.

Improve effectiveness and timeliness of feedback:

  • Employ accessible methods to request feedback.
  • learn how users can rate an app’s inclusiveness that’s meaningful to developers and users alike.

Here are a few initial mockups of some of the tools:

Visual VoiceOver—on the left is the original; on the right is a mockup of the output of the Visual VoiceOver tool
Visual VoiceOver—on the left is the original; on the right is a mockup of the output of the Visual VoiceOver tool
Interface as text—on the left is the original; on the right is the interface displayed as only text
Interface as text—on the left is the original; on the right is the interface displayed as only text
Colour-blindness test—what the UI looks like through simulations of different types of colour blindness
Colour-blindness test—what the UI looks like through simulations of different types of colour blindness


There are many ways you can support the Inclusive Toolkit! There are stickers, t-shirts, a wall of fame, accessibility app reviews and workshops. There is even a hero option where you can donate a workshop to a school or university!


There are some very awesome stickers, badges, t-shirts, and a wall of fame.


App reviews

Find out how inclusive your app is! I’ll review your app, provide screenshots highlighting parts of your app that are inaccessible, and offer steps on how you can improve the experience. Once you fix any issues, I’ll carry out a follow-up review to let you know whether the issues are resolved. One app review covers an iPhone, iPad or Mac app. If you have a universal app, you’ll need two reviews. The review also covers WatchKit extensions, Today extensions, custom-keyboard extensions, photo-editing extensions, and Apple TV specific UI.



The workshops are a great opportunity for developers, designers, QAs and companies to get some hands-on experience with accessibility. They also help me gather data on what areas people are struggling with, and they’ll help shape future tools. There are a few workshop options:

  • Workshop hero: If you’d like to donate a workshop to a school or university, this is the option for you! You’ll also get a t-shirt and some stickers as well as a special place on the wall of fame.
  • Individual developers/contractors: If you’re a developer, you can get a ticket to attend a one day workshop in London. The workshop will cover the accessibility APIs in iOS and OS X, and we’ll talk about how to use them, how to test them and how to think more inclusively. We’ll do some hands-on exercises, and you can get help fixing an app you’re working on.
  • Companies: If you’re a company and you have a team of developers/designers/QAs, you can have me come in and do a half-day or full-day workshop, customised for your specific needs. Half-day workshops will cover the accessibility APIs in iOS and OS X, and we’ll talk about how to use them, how to test them and how to think more inclusively. Full-day workshops are customisable—each workshop will include what’s covered in the half-day workshop plus some other options like a hands-on testing of your app, advice on how you can fix accessibility issues, QA-specific approaches to testing accessibility features, and tips to help you build inclusive empathy within designers and product people. For companies in the UK, if you’re based more than 2 hours outside of London by train—contact me first to discuss travel costs. If you’re based outside the UK, I can carry out a virtual workshop for your team—or there are also some shipping options available that will cover travel for me. Get in touch if you have any questions about location or availability. 


The project will be open source, so my progress will be fully visible and contribution and comments will be welcome.

I’ll start work in mid-June, and I’ll work through July, August and September. During July and August, I’ll hold workshops and carry out accessibility app reviews. I’m aiming to have a testable pre-release by the end of September. I’ll review the feedback from the workshops and testing, and I’ll be upfront if there may be any potential course-corrections. 

The next landmark release will be by the end of October, to potentially coincide with iOS 9 / OS X 10.11. I want this to be an ongoing project with my input and community involvement providing guidance.

Stretch goal

If the funding meets this target, then there will be a stretch goal: 

  • £12,000—I’ll write a book about accessibility within apps, including the results of the workshops and app reviews, with solutions and guidance.


I want the Inclusive Toolkit to be free to use so that all iOS and Mac developers can use it. I also want to make this project happen! It takes a lot of time to develop the tools, go through feedback, and add features—and do all of this quickly. I want the Inclusive Toolkit to be maintained for years to come.

The budget will be allocated towards: 

  • Time—time for me to work on the tools, and carry out workshops and app reviews
  • Infrastructure—website and any ongoing costs
  • Production costs for rewards like stickers and t-shirts  
  • Stretch goal (if met)—writing a book

If you want more apps to be inclusive or if you’re a developer and you want it to be easier to make your app inclusive, please consider backing my project, the Inclusive Toolkit—let’s make apps everyone can use.

Thank you!


Special thanks to LILYwoot Pictures for making such a wonderful video 🙂


Possible changes and additions to iOS and OS X after this summer’s WWDC may mean I’ll have to adjust or expand goals. I’ll be upfront about it if that may be the case.

Contact Information:

Sally Shepard

View Related News >