Mobile accessibility: testing mobile sites and native apps for accessibility

Hi.

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 pz.tt/WebDirections22, 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 bit.ly/3AdDjjP.

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

Here we go.

Excellent.

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?

Okay.

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 m.site, 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.

Yay.

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 pz.tt/WebDirections22.

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.