Mobile accessibility: testing mobile sites and native apps for accessibility


Thank you for having me.

Now this is actually a one hour presentation that I have pulled into various different things, so I may skip over some slides, but I didn't wanna delete them because they will be relevant if you wanna look back at them later.

I just wanted to say that you can access this presentation and all links at, and that URL is at the bottom of the slides.

So if you're like, oh my God, she's going too quick then you know you can access that and I'll put it at the end as well.

So first off, I wanna say thank you for having me.

I haven't spoke well other than the last two months, in which I did a world tour, sounds very exotic, it's not trust me.

And I this is my first time back, speaking in front of an audience, and I remember how much I loved, but I'd just like to say thank you for having me and meet our team.

It's about two thirds of us.

I started accessibility oz 12 years in April, and I wanted to actively support people with disabilities by providing them with employment opportunities.

So 80% of us have some kind of significant disability that affects their daily life, and yet you wouldn't know that to look at us.

We all look quote unquote normal.

So that's something to remember.

If you're new to accessibility, it's not just about people with canes or guide dogs.

It's not just about screen reader accessibility.

We've had staff with dyslexia.

Moderate vision impairment, epilepsy, migraines, severe vision impairment, physical impairment, P T S D, Crohn's Disease, multiple Sclerosis and Cerebral palsy.

I will be reading the content on these slides because there may be some people in the audience that can't see the slides.

So as I said, it's not just about vision impairments.

I don't really feel like I need to go through this Because it's been covered, but basically I started in 1998, so you can guess how old I am.

And I created Australia's first automated accessibility testing tool.

I spent six years with the W3C contributing to WCAG2.

AccessibilityOZ is a W3C member, but I personally am not on the guidelines working group, one of my staff members is.

I spent a few years on the Commonwealth Games, and then I spent five years managing usability and accessibility services.

Then I founded Accessibility Oz, we released Oz Player.

Our free accessibility, a free accessible player.

OzART automated accessibility testing tool.

I spoke at the United Nations on the importance of Web accessibility, and the important part is I chaired the ICT mobile site and native app testing committee, which is where these guidelines that I'm about to talk to you come from.

So the first thing is to access these guidelines.

They're on the Accessibility Oz website, so they're at

Or if you want to just go to the website that is not showing up.

Here we go.


If you go to resources and go to mobile testing, all the information you need is here.

So there's five documents for mobile site and there's five for Native App.

They're all available under Creative Commons, so download them, do with them what you will and let me know what you think.

So let's get started.

A little background.

So why did we develop this methodology?

So what happened is in 2017, I'm on the chair of the ICT Accessibility Testing Symposium.

So if you're an accessibility tester, it's a great conference that occurs.

well it did occur in DC in October every year, and at the end of the conference each year, and it's aimed specifically at accessibility specialists, we'd have a town hall where we'd say, okay, what is it that the industry.

What is lacking?

What is it that we should really be talking about?

It's very common for the accessibility industry to go off on their own tangent and do things.

So you might not know, but WCAG1 that was released in 1999, wasn't actually a W3C document.

It was developed by a group of accessibility specialists who came together and said ' hey, this new Web thing needs to be accessible'.

They wrote the guidelines in 1995.

They updated them and updated them.

W3C took them over in 1998 and released them in 1999.

We got together in 2017 and all the big name accessibility companies are there.

And we basically were like, the big problem is mobile, accessibility is just not being addressed Every single accessibility company knows that WCAG doesn't go far enough.

And so they have their own mobile guidelines, but they're all different.

So it depends which accessibility company you go to as to what kind of results you'll get.

And some aim specifically at assistive technologies.

And some are more based on code and we need some kind of standard.

So firstly, why is mobile different?


Mobile has native screen readers.

When you're talking about desktop, and I use the term desktop to mean a PC or a Mac or a laptop or a whatever, or a Chromebook even.

You have to often purchase a screen reader unless you're a Mac user.

So there's always a whole bunch of different screen readers you could use.

So the screen reader expert we have is an expert on N V D A and JAWS, and voiceover on iOS and voiceover on Mac.

So the native screen readers though, are built into the mobile devices and so people don't have a choice, but it also means you have to test less.

And there's also less wiggle room.

So often when something doesn't work with JAWS on desktop, it will work with N V D A on desktop.

And people who use screen readers know that and they can move between the two.

You can't do that on mobile.

There's things like volume control, haptic keyboard, visual, auditory and vibrational notifications, screen rotation, mono audio, voice control, increased text and display size, reduction of motion, zoom and reader view and simplified view.

All these things are really easy to access in the settings.

So what you end up happening is that people who don't identify as having a disability, turn these settings on.

So for example, my stepmother, who doesn't identify as having a disability, doesn't read books anymore because her eyesight is failing.

She has increased the text size significantly, and she reads all her books on her mobile phone because her text size is this big, and so you have a hu a much larger number of people accessing what are called assistive technologies on mobile devices that you don't have on desktop.

So that's another reason why it's really important that this testing is done.

Okay, let's talk about WCAG 2.1.

So WCAG 2.1 was supposed to address all the requirements, the complaints that people had about WCAG2 . WCAG 2 was released in 2008.

The first iPhone was released in 2007, and actually WCAG 2 we stopped working on that in 2006.

It took two years to go to actual candidate recommendation.

There's no changes made in those two years.

So we didn't, when we wrote WCAG2 we had no concept of what the world would be like.

We had no concept that we could access things on our watch like Dick Tracy, for those who remember that te, that movie.

Like we had no idea and we wanted it to be technology neutral, but we failed.

So WCAGs success criteria- yes.

They are applicable to mobile, but aspects of mobile accessibility have been missed.

And the biggest example, the best example is keyboard accessibility.

WCAG2 requires that everything be accessible to the keyboard and it's, that accessible to the keyboard, but it doesn't say accessible to touch.

It doesn't say accessible to mouse.

And there are people who are restricted to touch and they're restricted to mouse accessibility.

So that's where WCAG2 fellover.

So that's why WCAG 2.1.

WCAG 2.1 does build on this, right?

And it does address more criteria specifically related to touchscreen and sensors, pointer gestures, and small screen devices.

However, it still doesn't cover all the user needs related to mobile accessibility.

So when we got together, as in this mobile committee sorry, in this town hall, we got together and we said, okay, we need to have some kind of standardized mobile guidelines.

So what we did is we got everyone's mobile guidelines and we amalgamated them.

We didn't think about anything new.

We didn't assess whether it was accurate or not.

We just put them all together and made them readable.

And the one thing that every single one set of those mobile guidelines had in common was touch size, touch target size.

So that's the amount of actionable item that you have.

If something's too small to touch, you can you miss it and you have to zoom in and things like that.

The one requirement that we all agreed on was that you had to have adequate touch target size.

And touch target size was in WCAG 2.1.

However, it was in level AAA, as I say.

Level Triple A is where success criteria go to die.

So you know, that was, we got together at the end of 2018.

We went, Hey, WCAG 2.1 is out and as an industry really unimpressed.

So we need to actually do something about this.

So we said, okay, we're gonna convene this committee and we're gonna write a set of mobile guidelines.

And so that's what we did and we released them.

In early 2020, just before covid.

And so huge amount of information, a huge amount of work went into it.

A lot of different accessibility companies and org specialists were involved to write basically the mobile accessibility testing methodology.

I just wanna say that the methodology doesn't include things that are already in WCAG 2, WCAG 2 requires that you add alt attributes to images.

We don't put that in our methodology.

However, the new things in WCAG 2.1, we do include because we do think that they're important for mobile and the W3C has got some backup information that is useful.

But wherever we have a test case that references or is similar to WCAG 2.1, we reference it that's the case . So basically what we did is we found that there are four.

There are different sets of testing methods that you can use when you are testing mobile sites or native apps.

There are four main testing methods in mobile site testing.

Testing on mobile and tablet devices.

Testing with assistive technologies.

So that's the testing on the mobile or tablet device with assistive technology or mobile feature.

Responsive window.

So testing on a responsively sized window and testing on desktop.

On native app, there are only two main testing methods because you can't access the code or you can't reliably access the code like you can with a website.

And that's testing with devices and testing with devices with assistive technologies.

You cannot test with simulators.

Why can you not test with simulators?

So back in 2014 or BC -before covid- like I like to say, I did a lot of travel and back in 2014 I did my first speech overseas.

It's future of Web Design in New York on mobile accessibility.

And I had all these examples of crazy mobile things that were well crazy and there was no internet on those long haul flights.

15 hours.

It's not a great amount of time to spend in a steel can.

And so what would happen though is you'd land in the tarmac of LAX and you could access the LAX wifi.

So, and we'd often land, and then we'd sit there for two hours while they waited for a gate.

So, much 15 hours without internet at all.

And so you could access the wifi.

However, when you did access the wifi, you get this.

This page will redirect.

So content doesn't really make sense to have here, and all of a sudden I don't feel really safe about giving you my email address or my credit card details, things like that.

This is why you can't test with simulators.

You have to test with devices.

If they're location lock, if they're locked down, you have to test in specific locations.

You cannot test with simulators and the committee decided that there are some testing tools that you can, apps and things that you can download, but we didn't feel that any of them were sufficiently accurate or robust enough to include in the guidelines.

That may change.

It was released beginning of 2020.

But that's how we felt at the.

So basically the methodologies, they, there are five steps in both methodologies.

And the, things that you have to do under each step is different, but the steps are the same with the exception of step two.

So for the mobile site.

Step one, identify devices.

Step two, identify site type and variations.

Step three, test critical issues.

Step four, test mobile specific issues.

Step five, test mobile assistive technology and feature support.

And native app is exactly the same except for step two, which is 'define application functionality'.

So step one, identify devices So the first thing you need to do is determine what devices you need to test on.

If you have mostly your audience in Western countries, then iOS device is the most popular.

But if you have Eastern countries as your audience, then Android is most popular.

Best thing is to look at your analytics system.

Be aware that due to the popularity of Android, there are tens of thousands of an of Android operating system and browser combinations.

You can't test on them all.

So if you're testing on a Samsung device, do not test on the internet browser that comes pre-packaged with Samsung.

Download Chrome and test on Chrome on Samsung.

Chrome is a much better representation.

And be aware that even if you have a site that is a desktop site and you say, have a separate, people will still access that site on mobile devices.

People will access a desktop site on mobile devices.

People will access mobile sites on desktop.

It's just the way that the world works now.

So you have to make sure that everything works on desktop and everything works on mobile And be aware that even if an assistive technology is named the same, they won't operate the same.

So voiceover on Mac is gonna operate very differently to voiceover on iOS.

So you have to test both.

If you're interested in screen reader usage, there's the Web Aim Screen Reader survey, which is on that link that I gave you before.

Samsung, God knows why, has come up with an additional screen reader called Voice Assistant.

But anyone who really is reliant on a screen reader isn't going to use that.

They're going to use TalkBack.

And Amazon View also has a different screen reader called Voice View.

Most cases you can ignore them.

So what we recommend is you test on iPhone Safari, iPad Safari, and Android phone Chrome.

It's not enough just to test on an iPhone.

You have to test on the iPad as well cause it's a different operating system.

You can also consider an Android tablet with Chrome and alternative devices such as a Kindle.

If you have content aimed at that.

We recommend the latest version of iOS and iPad OS and the latest two versions of Android, however, saying that in the testing that I've done, I haven't really found much difference in the latest two versions of Android, so I think the next iteration of the methodology will require just testing on the latest version of Android.

If you have a site that's aimed at someone with a particular disability, make sure that the assistive technologies used by that person are tested with.

And you need to meet WCAG 2 along with this methodology.

So the next step for mobile sites is identify site type and variations of a page.

So you need to determine whether the site is desktop, m dot, or responsive, and if the site is responsive, are there variations of a page?

I'm not gonna go through the differences between these, but if you're like, I have no idea what she's talking about, it's in the documentation.

Be aware though, that there is a requirement around variations that says that you have to provide all content on all variations of a page.

So what do so an example is with WCAG 2, you have to zoom.

You have to zoom to 200% and still be able to access all the content.

That's just something that you have to do in WCAG 2.

And low vision users, of course, may actually access that zoom to because they can't see at a normal size.

Therefore, it's essential that functionality is not removed due to a variation in the page.

What do I mean by that?

This is what on YouTube five years ago, not now.

At 100%.

YouTube website, top right hand corner, upload and notifications button, are visible at a hundred percent.

Now, you, if you increase text size and this is on the desktop to 200%, they disappear.

Now, why do they disappear?

Because YouTube thinks that you're looking at this on a mobile device and they don't want you to upload your videos onto the mobile browser.

YouTube, they want you to use the native app, but if you are someone who's low vision, you're on desktop and there's no other way to upload the video.

So this is why every single variation of a page, if you are creating those variations, has to have all the same functionality.

Step two, this is for native apps, is define application functionality.

So native apps are very different to websites.

If you think about the Westpac website versus the Westpac banking app, the Westpac website has information on how to apply for a job, how to register a complaint, what the stock prices are, how to apply for a home loan et cetera, et cetera.

Whereas the Westpac banking app has very specific functionality, which is doing your banking.

So you need to understand the purpose of the native app and define which functionality is critical for use and must be tested for efficacy, operability, and workflow.

So ask the question, how would the experience be impacted if the functionality failed, the content could not be reached, or the experience caused a barrier to the user?

And then prioritize.

So all functionalities should be accessible within the native app.

However, it's important to define and include the critical functionality for each individual app to be prioritized in your testing.

And then you have to test common elements, so navigation, landing screens, emergency sections, login flows, settings, account and profile, contact us, real time updates, privacy policy, terms and conditions, interactional functionality, help section, widgets, geolocational maps, high traffic areas, etc.

And as I said, you can find these on all on the website.

So I wanna talk a little bit about critical errors.

We saw, we found in our research that there are a lot more traps on mobile than there are on desktops.

So what is a trap?

A trap is where a user is trapped within a component and can't escape without closing the browser or the app.

The app, the trap that everyone talks about, it's in WCAG 2 is the keyboard trap.

You tab into a component such as a video player- in 2011- and you can't tab out.

It was very, common.

But most things are being fixed now.

And so the only way you could escape is to close the browser.

Now, we found that there are actually five traps on mobile that don't seem to occur on desktop.

So the first one, exit Trap.

Ensure there is always an accessible, actionable item, eg.

a close button that meets color contrast requirements and has an accessible name that closes any features that overlays the current page, such as a full page ad.

And so this applies to all users, and it's both methodologies.

This is what I mean.

So this is Facebook.

You have an ad that overlays the entire page.

You'd think you could hit the back button but you can't and you can't edit the URL for some reason.

And the only way to actually move is to hit that really small area of white down the bottom.

So the only way you can really get out of it is to close the app and start again.

This is a more common example, right?

You go to a website and it comes up with a pop-up and it says, Hey, you should do X, Y, and Z, and its closed button is teeny tiny Doesn't meet touch target size requirements, doesn't meet color, contrast requirements.

Probably doesn't have an accessible name.

Now you could say, oh you can tap outside of it and close it, but not all users can do that.

So for the users that can't do that, they're trapped and they have to close the browser and start again.

Then we have a swipe scroll trap.

So ensure you do not override standard mobile touch functions, swiping, scrolling, et cetera on the majority of the page.

So this applies to touch users.

The methodology is mobile site and native app.

And this is an example, I call this the zoom of doom.

So basically they, they have actually found ways to get around this, two fingers to scroll the map, but if you scrolled on the map, it would n't move the map.

You'd have to hit these tiny areas of white to scroll the page.

This is not a problem if the entire page is the app, but if the map is on a page with other content and you you have the entire page just like this doesn't work.

And then you have text to speech traps.

So if the app has an ability to provide content via text to speech, the screen reader user must be able to pause or stop the app speaking in a simple manner, eg.

by performing a swipe on a screen.

So this applies to screen reader users and it's native App methodology.

So basically this is the pocket app where you can get it to read an article to you.

So screen reader users can activate the play button , which will then read the article to them.


However, the, there's no way for them to stop that article from being read, which means that they have to listen to their screen reader to navigate through the page to find how to pause it.

But they can't do that because the article is speaking.

So this is another trap.

And the headset trap.

So headset users must always be able to pause media, audio, or video content by using the pause, play, control on the headset.

Applies to screen reader users and headset users.

And it's both methodologies.

So this is very similar.

This is a website.

You've got a video that popped up at the bottom.

If you're a touch user, you can tap the little mute button and it will mute.

But if you're a headset user using a screen reader, if you use the button on the headset, then you will pause the screen reader, not the video.

And once again, you can't figure out how to pause the video if the video is talking over your screen reader.

And then a layer trap, the user should not be trapped on a non-visible layer.

So this applies to all users.

It's mostly encountered by screen reader users, and sometimes keyboard users.

It's both methodologies.

This is an example here where on the left you have the website.

On the right you have the menu, which overlays the website.

For the screen reader and keyboard users, though, the underlying page is what's read or what's accessed.

So for screen reader users, they can never access the menu for keyboard users, once they've activated the menu, they can't un- activate the menu and they can't see where they're going.

So that's definitely a problem.

So then step four, we have the tests and mobile specific issues and it's broken up into different categories.

So alternatives, for example have 2.1 motion interaction and gesture.

Touch, gestures, geolocation, change of state, audio cues, status messages, abbreviations, summary of content, ambiguous text.

And the actual documentation is quite in depth.

So you have the requirement like any touch gesture must have an alternative, accessible, actionable item.

It's very similar to success Criterion 2.5.1 and it gives you examples of touch gestures, gives you examples of alternative accessible gestures.

It gives a section about this requirement to explain why it's important.

It gives you a section on how to test.

It shows you some passes and fails.

So it's quite indepth.

And the fifth step is test mobile assistive technology and feature support.

And so this is one requirement that you have to make sure all mobile features and assistive technologies meet, so all actionable items and content can be accessed and activated by the following assistive technologies or when the following feature is enabled.

And so we recommend on, iOS voiceover, keyboard, keyboard and switch.

Zoom, invert colors, gray scale and reader view.

On Android.

It's TalkBack, keyboard, keyboard and switch, magnification, invert colors, gray scale, increased tech size and simplified view.

And the documentation has very detailed instructions on how you would test those things.

So I want to just go.

Just very briefly, we'll, actually we are reforming the committee, so we'll have updates from WCAG 2.2 whenever it gets released.

And we will also have additional assistive technology and mobile features included in the new methodology such as voice control, increasing text size and font color from reader view testing with the mouse . And we need to review existing test cases because some things have started to occur in both methodologies.

And we also need to remove some assistive technologies.

So there are certain things that always fail together or pass together, so you only need to test it once and then everything fails.

And we are working on an online resource at the moment, which will be more accessible than the word documents that we currently have . So I'd like to say thank you for coming today.

You can access the presentation on and all the links on

I'm doing a virtual mobile, mobile workshop.

It's a half day workshop where I go through this in more detail for the US on the 8th of December, Australia, on the 15th of December.

The information is on the blog.

And if you are interested in this, we would love for you to get involved and don't think, oh my gosh, I don't know enough about accessibility.

If you are here, you know enough about accessibility.

The reason why I know so much about mobile accessibility is because I chaired these committees I did not know much before.

This is a way to really increase your accessibility knowledge around mobile and there's a real lack of knowledge around this area.

So please do get involved if you can.

Thank you very much.

Please reach out to me if you have any questions, I'll be at the OZEWAI booth.

Otherwise I'll be in Queensland, so come visit me.

Mobile Accessibility

Access this presentation and all links at

Meet our team

Diverse group of people standing outdoors looking at the camera.

  • Dyslexia
  • Moderate vision impairment
  • Epilepsy
  • Migraines
  • Severe vision impairment
  • Physical impairment
  • PTSD
  • Crohn's Disease
  • Multiple Sclerosis
  • Cerebral Palsy

About Gian

  • Worked on first accessible website in Australia
  • Created Australia's first automated accessibility testing tool
  • Invited Expert to W3C WCAG2 Working Group
  • Worked on Melbourne 2006 Commonwealth Games
  • Managed Usability and Accessibility Services at Monash University
  • Founded AccessibilityOz
  • Released OzPlayer
  • Released OzArt
  • Spoke at the United Nations on web accessibility
  • Chaired ICT Mobile Site and Native App Testing
  • Inducted into the Centre for
  • Committee Accessibility's Hall of Fame as Accessibility Person of the Year 2019

Access the methodology

Available at:

Screenshot of AccessibilityOz website

Why did we develop this methodology?


ICT Accessibility Testing Symposium has developed a methodology for evaluating the accessibility of mobile web sites. This document is an amalgamation of accepted mobile accessibility testing standards from around the world, including additional developments from the ICT Accessibility Testing Symposium's Mobile Sub-Committee.

Mobile accessibility features

  • Native screen readers
    • TalkBack (Android)
    • VoiceOver (iOS)
  • Volume control
  • Haptic keyboard
  • Visual, auditory and
  • vibrational notifications
  • Screen rotation
  • Mono audio
  • Voice Control
  • Increase text and display size
  • Reduction of motion
  • Zoom
  • Reader view / Simplified view

What about WCAG2.1?


WCAG2 success criteria are applicable to mobile, however, not all aspects of mobile accessibility are specifically covered by WCAG2. For example, although WCAG2 requires sites to be accessible to the keyboard user, it does not specify that it should also be accessible to the touchscreen user.


WCAG2.1 builds on this and addresses more criteria related to touch screen (pointer gestures), sensors and small screen devices, however it still does not cover all user needs related to mobile accessibility.

So we wrote the Mobile Accessibility Testing Methodology

Please note that this methodology does not include those errors already included in WCAG2 but does include those errors in WCAG2.1

Testing methods

Testing methods - Mobile Sites

There are four main testing methods in mobile testing:

  • Devices: test on mobile and tablet devices
  • Devices with assistive technology: test on mobile and tablet devices with assistive technologies
  • Responsive Window: test on responsively sized window on desktop
  • Desktop: test on desktop

Testing methods - Native App

There are two main testing methods in native app:

  • Devices: test on mobile and tablet devices
  • Devices with assistive technology: test on mobile and tablet devices with assistive technologies

Test with real devices

I don't feel safe giving you my contact details..

Mobile Site & Native App Testing Methodologies

  • Step 1: Identify devices
  • Step 2: Identify site type and variations
  • Step 3: Test critical issues
  • Step 4: Test mobile-specific issues
  • Step 5: Test mobile assistive technology and feature support

Native App Testing Methodology Overview

Step 2: Define application functionality

Determining which devices to test on

In the United States, Australia, and other western countries, iOS devices are most popular. In Asia and other eastern countries, Android devices are most popular. To best find which devices to test on, review the Google Analytics or other analytics system for the requisite web site.

Choosing devices

Due to the popularity of the Android system, there are tens of thousands of Android operating systems and browser combinations available. It is not possible to test on all these systems.

The "Internet" browser that comes pre-packaged with most Samsung phones is very dependent on the operating system itself and it is a better representation to test with Chrome.

Devices with assistive technologies

Even if the site is a desktop site, people will still use the site on mobile with various assistive technologies. In some cases, as with VoiceOver, these assistive technologies are also available on desktop, however in most cases, assistive technologies are inherent to the device.

Devices with assistive technologies

It is important to remember that even assistive technologies that work across desktop and devices may behave differently on each system, and therefore they still need to be tested on mobile and tablet devices.

For the latest information on screen reader usage, please see the WebAIM Screen Reader Survey.

Additional device screen readers

Samsung includes an additional screen reader called "Voice Assistant," however TalkBack is still available as part of the Accessibility Suite. Amazon Fire also utilizes a different screen reader called "Voice View"

Identify devices

Recommended devices and browser combinations:

  • iPhone, (Safari)
  • iPad, (Safari)
  • Android phone, (Chrome)

Identify devices

Test on the latest version of iOS and iPadOS.

Test on latest two versions of Android.

When a site is directly aimed at people with a particular kind of disability, consider including assistive devices and/or other assistive technologies used by potential users.

You need to meet WCAG2 and this mobile testing methodology

2. Identify site type & variations of the page

Identify site type and variations

Is the site:

  • Desktop
  • Responsive

If the site is responsive, are there variations of the page?

Three types of mobile sites

Desktop web sites: that have only one display, whether viewed on desktop or mobile or tablet device sites: that have a particular display for mobile and tablet sites. The site must also be tested against the entirety of WCAG2, in addition to the standard www version of the site.

Responsive web sites: that change depending on the screen size or other feature as determined by the developer: that change depending on the screen size or other feature as determined by the developer

Page variations

As part of WCAG2, zooming to 200% should already be included in regular testing (and therefore is not included in this methodology).

Low vision users (who use the zoom function inherent in the browser) are often restricted to a mobile view of the site on their desktop.

Therefore it is essential that functionality is not removed due to a variation in the page.

WCAG2.1 page variations

WAG Conformance Requirement - Full Pages - Page variations

Screenshot of YouTube with upload and notification widgets showing in top right. Label reads "Upload and Notifications visible at 100%"

Same screenshot with the widgets gone. Label reads "Upload and Notifications disappear at 200%"

Define application functionality

Through your understanding of the purpose of the native app, define which functionality is critical to its purpose and use and that must be tested for efficacy, operability, and workflow from a user experience perspective.

Define application functionality

Ask the question: how would the experience be impacted if the functionality failed, the content could not be reached, and or the experience caused a barrier to the user?

Prioritise. All functionality should be accessible within the native app; however, it is important to define and include the critical functionality for each individual app to be prioritised in your testing.

Common elements to test

  • Navigation
  • Landing screen(s)
  • Emergency sections
  • Login flows
  • Settings
  • Account and profile
  • Contact Us
  • Real-time updates
  • Privacy policy, Terms and
  • Conditions
  • Interactional functionality
  • Help section
  • Widgets (calendars, etc)
  • Geo-locational maps
  • High-traffic areas

Find these methodologies on the AccessibilityOz web site under the Resources menu item

3. Test critical issues

New features means new traps

Trap: Where a user is trapped within a component and cannot escape without closing the browser or app.

There are many more traps in mobile sites and native apps than on desktop.

Traps identified

  • Exit trap
  • Swipe / Scroll trap
  • Text-to-speech trap
  • Headset trap
  • Layer trap

Exit trap

Ensure there is always an accessible actionable item (e.g. a close button that meets color contrast requirements and has an accessible name that closes any feature that overlays the current page (such as a full-page ad).

Applies to: All users

Methodology: Mobile Site and Native App

Exit trap

No way to close the feature (usually an ad)

Exit trap

Close button does not meet color contrast or touch target size requirements

Swipe / Scroll trap

Ensure you do not override standard mobile touch functions (swiping, scrolling, etc.) on the majority of the page.

Applies to: Touch users

Methodology: Mobile Site and Native App

Swipe / Scroll trap

The zoom of doom

Text-to-speech trap

If the app has an ability to provide content via text-to- speech, the screen reader user must be able to pause or stop the app speaking in a simple manner, e.g. by performing a swipe on a screen.

Applies to: Screen reader users

Methodology: Native App

Text-to-speech trap

Once activated, screen reader users cannot stop the TTS

Headset trap

Headset users must always be able to pause media (audio or video) content by using the Pause/Play control on the headset.

Applies to: Screen reader users, Headset users

Methodology: Mobile Site and Native App

Headset trap

Cannot pause the audio using headset hardware (pause on the headset pauses the screen reader)

Layer trap

The user should not be trapped on a non-visible layer.

Applies to: All users (but mostly encountered by screen reader users and sometimes keyboard users)

Methodology: Mobile Site and Native App

Layer trap

Screen reader user cannot access the menu. Focus stays on the parent layer.


  • 2.1: Motion, interaction and gesture
  • 2.2: Touch gestures
  • 2.3: Geolocation
  • 2.4: Change of state
  • 2.5: Audio cues
  • 2.6: Status messages
  • 2.7: Abbreviations
  • 2.8: Summary of content
  • 2.9: Ambiguous text

Let's see an example from the document

2.2 Touch gestures

Any touch gesture must have an alternative, accessible, actionable item (for more information see SC 2.5.1: Pointer Gestures).

Examples of touch gestures

  • Swiping up and down or left and right
  • Dragging up and down or left and right
  • Double-tapping
  • Tap and hold
  • Tap and swipe
  • Two pinch zoom
  • Press and long hold

Examples of alternative, accessible gestures:

  • A link
  • A button
  • A dropdown
  • A separate page with the same functionality

About this requirement

This requirement is particularly important for screen reader users. For example, if you require your user to swipe right to complete a purchase, when the screen reader is on, the swipe right gesture moves you to the next focusable item and doesn't complete the purchase. You must be able to perform the same action, by using a link, an up or down swipe, or some other gesture.

How to test

Identify any site controls. If they require any of the following gestures, is there an accessible actionable item provided as an alternative?

  • Swiping up and down or left and right or dragging up and down or left and right
  • Double-tapping or two-pinch zoom
  • Tap and hold or tap and swipe
  • Press and long hold

2.2 Touch gestures

Alternative is provided on another page

2.2 Touch gestures

Tap alternative is provided instead of drag gesture

Test mobile assistive technology and features

All actionable items and content can be accessed and activated by the following assistive technologies (or when the following feature is enabled)

Mobile assistive technologies and features

  • VoiceOver (iOS)
  • Keyboard (iOS)
  • Keyboard and switch (iOS)
  • Zoom (iOS)
  • Invert colors (iOS)
  • Grayscale (iOS)
  • Reader view (iOS)
  • TalkBack (Android)
  • Keyboard (Android
  • Keyboard & switch (Android)
  • Magnification (Android)
  • Invert colors (Android)
  • Grayscale (Android)
  • Increase text size (Android)
  • Simplified view (Android)

Updates from WCAG2.2

The four additional Level A success criteria are (my description):

  • 2.4.13: Page Break Navigation - providing accurate locations when page numbers change due to resizing
  • 3.2.6: Consistent help - providing consistent help mechanisms
  • 3.3.7: Accessible Authentication - providing easy methods of authentication
  • 3.3.8: Redundant Entry - Information previously entered is auto-populated
Updates from WCAG2.2 The four additional Level A success criteria are (my description):
  • 2.4.11: Focus Appearance - ensuring the keyboard focus indicator is visible to all
  • 2.5.7: Dragging Movements - dragging has an accessible alternative
  • 2.5.8: Target Size - targets have an adequate size
  • 3.2.7: Visible Controls - controls are always visible

Additional assistive technology / mobile features

Additional assistive technologies / mobile features

Some additional assistive technologies / mobile features

  • Voice Control
  • Increasing text size / font color from Reader View
  • Testing with a mouse

Review of existing test cases

Review of existing test cases

Some test cases need review, for example:

  • Text-to-Speech traps were only in the Native App methodology, however they have begun to occur on Mobile Sites

Removal of some assistive technologies and mobile features

Removal of some assistive technologies / mobile features

Certain types of tests tend to generate the same results and need to be removed:

  • Grayscale (in iOS and Android), Color Inversion (in Android), and Invert Colors (in iOS) always fail together or pass together
  • Reduce Motion (iOS) and Remove Animations (in Android) always fail together or pass together
  • Classic Invert doesn't provide any additional testing information to Smart Invert

Creation of an online resource

Creation of online resource

Currently these are Word documents, but it would be better to be a web site which is:

  • Searchable
  • Easily updated
  • More likely to be used


  • More accessible!

Thank you for coming today

Access this presentation and all links at

Virtual mobile workshop:

  • US: 8th December
  • Oz: 15th December

Check out the AccessibilityOz blog

Get involved!

[email protected]