Testing application accessibility

Ok so it’s been a while since I have posted anything, guess I broke my plans for posting once a week. Anyways testing you apps accessibility, currently I’m talking about iOS, however the same concepts apply to Android, WP7, Rim etc. When is comes to web design there is no shortage of tools and applications to help designers and developers validate and evaluate their sites code and accessibility e.g. W3C, Wave and aDesigner. However the same cannot be said for developing native applications for the mobile platforms. Whilst the OS giants provide accessibility API’s and guidelines (some more detailed than others) they fail to supply us developers with methods of assessing how we did. Sifting through your applications page by page using the Accessibility Inspector (iOS only) can be grueling process. *ASSUMPTION ALERT* As a result developers don’t do it. They just validate, check for memory leaks and submit to the stores. Why should they care? Apple don’t! Google don’t!, Windows don’t!, Rim don’t! The applications just get approved. Misuse a icon, or cut into someones profit margins and your app will be kicked back in your face in a heartbeat. Make your print magazine or news papers available in digital format and provide no screen reader (e.g. Voice Over, Talkback) support whatsoever. APPROVED!

As you might have guessed this is a sore subject for me, however I come to you with more than just a rant. I have a possible solution (well an incremental improvement at least). An automated tool for trolling through your application and checking the common accessibility issues. It still in the early stages but can already evaluate contrast levels, font sizes, alternative texts, object hints, traits and even assess your pages readability score. Currently working on evaluating page flow for screen readers and colourblind simulations. As it stands at the moment the framework is less than 1mb and requires just one line of code inserted into the app. From there it will parse through the views one by one, checking subviews and their subviews and so on, until it gets them all. The output is a little messy at present, as I’m just dumping the pass/fail + score values into the log file of the debugger. Planning on structuring this output into the EARL format, a lot cleaner to look through plus its machine readable (prefect for further add-ons and extensions). I know its not going be ensure that applications are 100% accessible and usable but its a step in the right direction.

I hope to have a beta version available for interested developers soon. So please comment or get in touch if you are interested or have suggestions and ideas on how to make it better.


Leave a Comment