A straight forward task really, its a wonder that developers make these rookie mistakes. In all honesty the iOS SDK makes this post rather redundant ( as long as you are working with the standard components! ) but as you will see there are a number of ways you can mess this up and create serious difficulties for VoiceOver users.
So basics first I would hope that if you are developing applications for the iPhone you are aware of the
Accessibility Programming Guide within the Apple dev centre ( if not, go there now. ) The purpose of this guide is to ensure that as developers we provide the necessary meta data with in our applications to allow VoiceOver to do its job. VoiceOver is the text-to-speech tool built into the iOS devices (appears to be 3GS and up, or 3rd Generation iPod Touches. I might be wrong, but its not on my old iPhone 3G.) For the most part this will just work right out the box, that is until you start to build your own UI controls. Custom UI controls are great if your getting fed up with the standard look and feel, however you need to make sure you provide a little extra data for the user.
taken right out of the guide, this method is a must have for any custom views you plan to make accessible for VoiceOver. Why would I not want my custom view to be accessible through VoiceOver? Well as great as VoiceOver is at text-to-speech is does still have some draw backs. The biggest of which being the difficulties it creates for gestural input within views. If isAccessibilityElemnt returns YES then users will be unable to use any gesture input to that view, this means no swipe or pinch. So its important that you think carefully about the indented interactions of a view before making it accessible by VoiceOver. Does the content require gesture input? Once you have decided that a view is going to be accessible you then need to start providing that meta data that VoiceOver uses. For all you web programmers out there this will feel natural to you, just think of adding alternative text to your media elements and bingo you’ve got it. We need to add meaningful Labels and Hints then assign the appropriate Traits
As you will see from the screen shot above, each of these attributes can be assigned from the Interface Builder. The Label is generally the purpose of the UI Control e.g. ‘Skip Song’ or ‘Username’. Hint is used to provide the user instruction on how to interact with the UI Control for example ‘Press and Hold to skip song’. Finally the Traits help to identify the type of UI Control the user is interacting with; Image, Button, Static Text etc. Important! you do not need to at the type of UI Control into your Label, e.g. ‘Skip Song Button’ the word button is not required, this is established from the Traits, that Label would give the following text-to-speech ‘Skip Song Button Button’. Which not only sounds ridiculous but could also confuse the user. All of these attributes can be accessed directly within your code files, and details can be found in the Accessibility Programming Guides mentioned above. Once you have added your accessibility meta data test your application out with the ‘Accessibility Inspector’ tool in the iPhone Simulator or try it out in VoiceOver on your iOS device. Make your applications accessible to everyone :)