WAI ARIA support on iOS

I’ve been concerned that there’s been a lot of talk around Mobile Safari supporting WAI ARIA  but there’s little documentation out there confirming what is and isn’t supported so I thought I’d run a few basic tests with Mobile Safari on iPhone 4 and iPad 1 to see what’s what.

Having looked at a few WAI ARIA test cases I settled on using the excellent Accessible jQuery-ui Components Demo put together by Hans Hillen of the Paciello Group. As I wanted a snapshot of what the expected output was, rather than a comparison with desktop Safari, I tested the output first using Jaws 12 in Firefox 5. I then tested it on the iPhone and iPad to see what the differences were.

The results below list ‘Expected output’, iPhone 4 and iPad 1. For each I noted if the WAI-ARIA attribute was ‘Supported’, ‘Not Supported’ or ‘Partial’. Where it’s unclear if it’s the coding, the touch screen commands or the support itself I have marked it as ‘Partial’.

These need more investigation so if you have any comments or want to test and share the results yourself in the comments that would be great.

One thing to note is that according to Steve Faulkner Voiceover on iOS only looks at information available via the accessibility API and does not look into the DOM when information is lacking there. This is unlike Windows desktop screen readers such as Jaws that do tend to compensate for lack of accessibility in the API by parsing the DOM.

A huge thank you to Kevin Chao who also tested these so we could double check the results. If you don’t know Kevin he does a lot of testing with Mac, iOS, NVDA (Non Visual Desktop Access), Jaws, Firefox and more. He’s definitely worth a follow on Twitter if you’re not already.

Update 2nd December, 2011: Added support for iOS5 on iPhone 4. There was no change in that the results mirrired exactly what was already seen with th eolder operating systems on iOS.

 

 

 

 

 

 WAI ARIA attribute Expected output iPhone 4 iPad 1 iPhone 4iOS5
Slider ‘Price’ and amount ($19) read correctly and ‘to activate use left and right arrow keys’ as expected Not supported
‘Price, $19, adjustable, swipe up or down to adjust the value’ announced however swiping with 3 fingers scrolled the page not the slide
Not SupportedSame as iPhone 

 

 

Not supported 

 

 

Progressbar Spoke %’s randomly each time tested (36%…80%…100%). Failed to read the heading ‘Progress’ in the popup and ‘Loading files’ Not supportedOnly read ‘Progress, failed to read the heading ‘Progress’, %s or ‘Loading files’

Not Supported

Same as iPhone

Not                          supported           When the progress bar dialogue appears touch to hear ‘Progress bar’ and ‘Loading files’. No auto speaking loading files or progress announced
Menubar Menu name and ‘ to navigate press left or right arrow key’ read correctly. When selected the first sub menu item is read and ‘to move through items press the up and down arrow keys SupportedIt would be useful to notify the user the menu is open i.e. ‘More options open, Sub option 1’.  SupportedSame as iPhone  SupportedSame as iPhone 
Buttons Button names and ‘to activate press space bar’ are read out and all activate their behaviours Supported SupportedSame as iPhone SupportedSame as iPhone
Dialog All text and form fields are read out after the dialog is triggered SupportedAfter the dialog is triggered the focus is set to the first form field and all text and further form fields are read correctly. SupportedSame as iPhone  SupportedSame as iPhone 
Checkbox Check boxes are correctly read as checked or unckecked together with their label Supported SupportedSame as iPhone SupportedSame as iPhone
Accordian When the focus is set on the first link in the accordion use the arrow keys to navigate other links in the accordion SupportedThe newly opened link was not announced as open which would be usefu SupportedSame as iPhone SupportedSame as iPhone
Tree  Left and right arrows open and close sub menu items and up and down arrows navigate up and down Not supported  There is no focus on the arrow part of the tree which is the element that opens and closes the tree. Menu items are read correctly.

Not Supported

Same as iPhone

SupportedSame as iPhone 
Carousel Arrow keys cycle through the carousel correctly and each image alternative is read out Partially supported  Images in the carousel are not read out when they receive focus or are double tapped and update. This may be due to the use of tabindex=”0″/”-1″. The next/previous buttons work.

Partially Supported

Same as iPhone

Partially supportedSame as iPhone 

 

 

 

Tabs  Arrow keys correctly take the focus order through the panels, enter to activate SupportedWhen a tab is opened the user is notified the tab is now ‘Selected’ SupportedSame as iPhone SupportedSame as iPhone
Tooltip All tooltips read correctly (on links, form fields) PartialTooltips are not read out on links but they are on form fields. They visually appear on both PartialSame as iPhone PartialSame as iPhone
Auto-complete Auto complete items not read out by Jaws 12 in FF5 SupportedAuto complete items read out and can be selected SupportedSame as iPhone  SupportedSame as iPhone. Autocomplete announces how many items there are in the drop down.
Panel Panels open and close on ‘enter’ and arrow keys navigate content within panels  Supported Behaves as any other link. SupportedSame as iPhone SupportedSame as iPhone
Date-picker Unable to populate fields using the datepicker using the keyboard Not supported Unable to populate fields using the datepicker using the touchscreen

Not Supported

Same as iPhone

Not SupportedSame as iPhone
Land-marks * Landmark name is read out PartialLandmark start and landmark end is read out but not the name of the landmark

Partial

Same as iPhone

PartialSame as iPhone
tabindex o/-1**  Supported but see Jason Kiss’s analysis for detail Not supportedTabindex is completely ignored.

Not Supported

Same as iPhone

Not SupportedSame as iPhone

* Landmarks were tested on the Paciello Group Blog (which also happens to be a great reference for WAI ARIA and HTML5)

** Tabindex was tested using Jason Kiss’s detailed test case for tabindex, Keyboard Focus and Some ARIA in Screen Readers.

8 thoughts on “WAI ARIA support on iOS

  1. Pingback: Mobile Accessibility Guidelines | » Henny Swan's blog

  2. Pingback: Resources for Mobile Accessibility Guidelines | Jason Haag

  3. For a number of these, like carousel, have no direct ARIA role. Were these design patterns?

    Note: for RIAs and ARIA to work well on mobile touch phones we will need device independent events. Apple has been waiting for that to happen and we have a new working group charter to address this for which Apple is chairing. UI widgets like tree will need need device independent events to be properly implemented.

    Note: ARIA landmarks are available in the rotor.

  4. Pingback: 모바일 접근성 관련 주요 가이드라인 등 – Henny Swan 블로깅 의역을 중심으로 « 삐돌이의 웹 접근성 & IT Transformation

  5. Pingback: WAI-ARIA: Information & examples | WAI ARIA support on iOS

  6. Thanks for testing these. I had not had the bandwidth to do this myself yet and had pretty low expectations. Low expectations means this turned out better than I thought 🙂 A bit of background. When we kicked off this project I wanted to remediate widgets that we found often in the wild or on AOL’s sites that had bad accessibility. This way when a developer writes yet another wonky menu bar I can just point them to this good implementation and ask them to stop reinventing the wheel in an inaccessible way. Reusing this widget is far easier than writing and maintaining a custom one so it’s a persuasive argument.
    Generally all the widgets are part of the jQueryUI 1.9 branch except Tree and Carousel. There were no immediate plans in jQueryUI for these two types of widgets yet we often saw them implemented inaccessibly in the wild. So we added these two to the scope of work, basing them off jsTree and jcarousel, two popular plugin implementations.
    I should point out that we’re just finishing up work with the last widget, DatePicker, so accessibility there is not fully implemented.
    Hans and I presented about this work at CSUN and the NFB’s Web Accessibility Day. Requiring high levels of ARIA and implementation detail understanding/awareness has been a big stumbling block to accessibility. We hope that baking accessibility into this mainstream widget library will mean more developers get accessible interaction on their pages by default.
    Bugs and feedback always welcome.

  7. Hi Chris, thanks for your comments as well as the demo. It’s a handy reference and one I use a lot. I’d love to do more testing across devices but don’t have the resource just yet. I suspect that iOS may be ahead anyway. Like you say, having this baked into libraries is pretty key. There’s a real disconnect between what devs do technically to implement ARIA and how usable people find it so having a tried and tested example is the way forward.

    Will you be at CSUN in 2012? If so hopefully meet you there.

    Chris Blouch Reply:

    It’s an understandable conundrum. Most web developers test their own work against their own expectations for behavior. Since the majority of developers do not have a disability they interact using the most common method, which is looking at the screen and clicking around with the mouse. So the fact that the UI doesn’t work well with a keyboard or screen reader isn’t due to malice, just ignorance. For the subset of developers who do know about accessibility there is yet another hurdle or correctly implementing ARIA and keyboard controls. In many cases, especially with widgets, this is a non-trivial bit of work as it is only recently that the OS/browser/AT/ARIA stuff has been solid enough to really implement anything. As Hans and I found out, and debated, there isn’e always agreement on the ‘best’ way to navigate. You can find long winded discussions on autocomplete and datepicker controls if you search around the web. So we think our implementation is the best but the proof will be when it’s implemented in real products used by real people and not just our clean room demo page. We hope it will hold up under that best of testing – the crowd.
    I’ll be at CSUN again this year but, for once, won’t be presenting. This time I get to just enjoy learning about what others were doing. We do have more irons in the fire but we couldn’t be sure they would be in a presentable state by CSUN this year, which means we’ll probably have a small boatload to show the year after. Hope I can find you there.

Comments are closed.