Accessibility Technology

iOS vs. Android, a Web and Native Application Accessibility Comparison

This is my first session from the second day at the CSUN conference.  This session covers “a comparison of accessibility and WAI-ARIA support in Android and iOS.  Which ARIA features work in one, both, or neither of these mobile platforms.”  I met Paul at CSUN in 2013, and he’s both an enthusiastic and opinionated developer.  This makes his Twitter feed fun to watch at times 😉


  • Paul Adam, Accessibility Evangelist at Deque (@pauljadam)




Google has done a great job improving Android’s accessibility API, but is still a few years behind Apple.  Paul showed Apple’s UIKitFramework and some of the properties available when using XCode, including:

  • accessibilityViewIsModal()
  • accessibilityPerformMagicTap()
  • UIAccessibilityPostNotification()

Sending focus to items is much easier in native apps versus mobile web apps (web is not a nice controlled environment and still has a way to go).

Adding descriptions to images in Android:  androidcontentDescription

XCode allows you to add content descriptions via GUI or programatically.


WAI-ARIA Live Demos

There’s a WAI-ARIA attribute support matrix available from Paul’s presentation (see resources link above).  The matrix is not exhaustive, but let’s give Paul a break, eh?

ARIA is generally well-supported in current browsers.

Paul then opened up a web page made by Andrew Kirkpatrick that had some pictures with ARIA tags for people to test how different browsers handle the tags.

With Live Regions you can make the screen reader read entries on-the-fly.  However, you need to have a container painted on the page to receive updatable content.


Paul then demonstrated a couple simple forms with VoiceOver showing how aria-describedby, aria-required, aria-invalid and jQuery.focus().  Paul has an iOS WAI-ARIA “fail list” on his web site which is worth checking out:


Apple does not support HTML5 form validation, but Google does.   Using HTML5 form types are recognized, so context-appropriate keyboards are presented, i.e. numeric keypads in telephone fields, datepickers in date fields, etc.

All mobile browser default placeholders / control outlines fail contrast tests.


Paul then gave a demonstration of how captions work on both Android and iOS.  Interesting fact: in iOS, you can’t make an HTML5 button say whatever you want.


As a user, you probably want to use iOS.  As a developer, you probably want to play with Google.  I captured a few of the platform pros/cons Paul listed:

  • A big con for iOS developers:  Apple doesn’t do a very good job of documenting fixes to VoiceOver.
  • A con for Android users:  zoom level isn’t maintained between apps.
  • Facebook and Twitter are much more accessible on iOS


Q & A

Question:  what are the user stats for each platform…which gets used more?  Answer: iOS is far and away the most used, according to WebAIM’s screen reader survey.

By Paul Schantz

CSUN Director of Web & Technology Services, Student Affairs. husband, father, gamer, part time aviator, fitness enthusiast, Apple fan, and iguana wrangler.

3 replies on “iOS vs. Android, a Web and Native Application Accessibility Comparison”

Thanks for the great write up!!! FYI the missing accessible name is a bug in HTML5 and elements where I can’t assign an aria-label or something else to make the play button unique, also it’s in the bottom of the DOM so would be focused on last. 🙂

Leave a Reply

Your email address will not be published.

%d bloggers like this: