At first, everything in iOS accessibility seemed quite simple to me. But I soon realized it can be difficult to make quick (significant) progress.

Often, there is just so much we can do with the allocated time and resources, and the scope and expectations of a project.

I have always thrived in small teams, and my typical day is composed by many competing priorities: fulfilling high ROI features for the business, fixing technical issues and/or debt, achieving my multiple personal goals, surviving to the existing workflows, creating new ones, documenting, testing, navigating the demands of users, resolving conflicts…

It is not straightforward to make the right choices to keep it all perfectly balanced. Nor one should feel like it must be.

Tomorrow is too late for accessibility

When I first introduced accessibility to my tornado of competing priorities, I started to look around me for help. It was not particularly difficult to motivate people given my enthusiasm. But we all had our tornadoes to deal with, and introducing accessibility just made them more powerful.

Now, we all shared a looming feeling of “tomorrow is too late for accessibility.” But we did not know how to fulfill it effectively.

Although it will always be true that there is an urgent need to make our apps fully accessible, the reality is that declaring a problem “looming” can be a toxic way to live and deal with it. We weren’t going to be successful with that approach.

Break it down

I had to fail multiple times to then realize something that is not rocket science: To make all the accessibility work attainable, I just needed to come to terms with not trying to tackle everything at once.

Some things are not as blocking as I though. I did not need to persuade any stakeholders to drop it all for accessibility. I did not need to have every design and ticket filled with a comprehensive list of accessibility requirements.

There were ways to champion it and make significant headway.

I just needed a roadmap to be successful, and for that, I thought I needed guidance because I wasn’t an expert on accessibility.

Self-auditing

Thankfully, building a practical roadmap was possible in simpler terms than I initially envisioned.

While there is absolutely nothing ill-judged about expediting the process by recurring to experts, for indy developers, small teams, or even big teams under pressure, there may not be enough resources to do so.

Instead of recurring to external auditing I realized I was able to self-audit my work with the knowledge I had at every given time. I only needed to grow naturally, and try to improve constantly.

External feedback

Another key point is to seek for external feedback. It may come more slowly, but it usually has solved many of my self-auditing roadblocks and opened new paths to explore.

Big or small, some breakthroughs came to me from:

• Taking any opportunity to listen to users who would like to discuss their accessibility experience.
• Talking to members of the iOS + Accessibility community.
• Paying close attention to Apple’s WWDC sessions and other online materials.
• And the accessibility labs and consultations at WWDC. Their first-hand experience is invaluable.

Putting all this together, I have built and grown successful roadmaps.

For me, my key takeaways to build the best experience I can offer have been: being more comfortable with unknowns, trust existing knowledge, and keep iterating.

Comments or questions? Comment here or hit me @fbeeper. More to come on my next article about bridging the technical gaps to accessibility.