This is, I believe, my 100th post on this blog, and I’m using it to announce that Apple’s iOS 4, released yesterday for the iPhone and iPod Touch, supports WAI-ARIA landmark in the VoiceOver screen reader. VoiceOver has had, since its inception, a feature called the rotor. The rotor allows users to set a particula rweb element by which the one-finger-flick up and down gesture moves in mobile Safari and other apps that use a web display. This feature is now highly customizable. Not only can you enable and disable certain features (for example if you never want to navigate by graphics, you can disable it completely and it won’t show up in the rotor). But the rotor settings also include a new feature called landmarks. This rotor setting is disabled by default, but can be enabled through the Web settings sub window of the VoiceOver settings. Once enabled, and the user switches to it via the rotor gesture, navigating by WAI-ARIA landmarks on a page works very nicely. The one thing that VoiceOver does not do yet is announce the type of landmark, be it banner, main, search, complementary etc. Furthermore, the landmarks also include what is called automatic web spots in the VoiceOver on Snow Leopard for the Mac. So not only do you jump to the actually marked up landmarks, but a few more spots on a page Apple deems interesting. In my experience, these usually are quite useful spots, too, so this doesn’t harm the original landmark feature at all.

It is fantastic to see that WAI-ARIA is getting more and more adoption in mainstream products. VoiceOver is available on any iPhone 3G S and iPhone 4, as well as the newest generation iPod Touch models (32 and 64 GB), and the iPad. The iPad does not include the landmarks feature yet, since its iOS hasn’t been updated to version 4 yet.

Further reading

Easy WAI-ARIA tip #4: Landmarks

Umm, yes, I know, it’s unusual to drink to a technology, esp at this early hour of the day! 🙂 But I just wanted to give a shoutout to Try Server and the team at Mozilla’s build/release engineering department who built this marvelous piece of infrastructure!

The try server has saved the accessibility team members’ butts so many times over the past two years that I’ve stopped counting. Just now, as we’re working hard to fix our performance problems on trunk, and putting in some other much needed reorganization, this try server build system has proven to be an invaluable tool for finding regressions before they even become such.

For example on this document handling reorganization bug, I tested various try-server builds before confirming that this huge code refactoring didn’t break us. Much of it is caught by Mochitests, but not all of it is, because some things are in platform-dependent wrapper classes that cannot be tested by the Mochitest unittest framework.

Likewise, we’re currently fighting a regression in the patch for a performance booster bug that would break a popular screen reader on many pages if it landed as the patch is now. I found this while testing the try server build for this patch. Tests pass and the code looks correct, but something is wrong nevertheless. The try server allows us to go through as many incarnations of the patch as needed until the problem is resolved without affecting the production of nightly builds. It avoids having to file follow-up bugs and having to go back to the same area of the code weeks later.

For my job as Mozilla’s accessibility QA engineer, the try server has become an invaluable tool as part of my day job. I encourage everyone doing testing in tandem with a developer to utilize this tool heavily!