The new Mobile Site and Native App Accessibility Testing Guidelines

Gian: Today, I am going to talk about mobile site and native app accessibility. I want to start off with some mobile accessibility — oh! — files.

Back in 2014, I had this presentation that I ran everywhere about the mobile-accessibility files that we were seeing, and how they could not necessarily fall into WCAG. I will talk about those that fall into WCAG.

This is a file of WCAG Success Criterion 2.2.2 Pause, Stop, Hide. As soon as you open the mobile app, a video plays. It was, back then, difficult to pause the video.

Here, we have WCAG2 Success Criterion 1.4.3 Contrast (Minimum) for Amazon. This is difficult to see. I spoke to someone who worked in one of these organizations, Amazon, eBay, Alibaba, one of those, and they said that they changed the placeholding characters, and their profit margins increased by 13 percent.

Excuse me is a second.

Sorry about that.

This here is WCAG2 Success Criterion 3.3.1 Error Identification, and WCAG2 Success Criterion 3.3.3 Error Suggestion. Before COVID, I did a lot of traveling, and I wouldn't have been able to do it as easily without Netflix. Occasionally, I would get this error, that said "Error" with a "Cancel" button. What is the error? That I don't have Internet access? Is my username and password incorrect? Etc.

This is WCAG2 Success Criterion 1.4.4 Resize Text. On the left, you have the smallest text that you could do, and, on the right, you have the largest text that you could do. The smallest text is small but the large text is not very large.

The biggest problem is, if you scroll to the top of the article, if you asked for small or large text, you get the same visible representation. The title, the information, the date, the time, the caption, the author, etc. are the same.

This fails 3.2.2 Consistent Navigation. I would operate always off my tasks. If something wasn't on my tasks, I wouldn't do it. I found the mobile app useless, so we moved to something else.

Sorry about the coughing.

Why did we develop this methodology? We found there are a whole bunch of accessibility issues that didn't fall under WCAG2. I went around and spoke about what some of these things were. We had a conversation at the ICT Accessibility Testing Symposium, and it was decided it would be a good idea if accessibility specialists got together to write an app for testing.

I'm sorry, just a moment. I think I might have a bit of asthma, so just one moment.

Sorry. Hopefully, that has sorted it.

Basically, what happened is, I was co-chair of a committee in 2018, and we developed one set of guidelines that covered both mobile sites and native sites. The following year, we had two subcommittees, one for mobile sites and one for native apps.

While doing the mobile guidelines, WCAG2.1 was released. We hoped it would address the issues and would make our work obsolete, but that was not the case. For example, insuring the size of an actionable item is large enough to tap on is a AAA requirement.

WCAG2, just in case you weren't aware, definitely had some problems when it came to mobile. For example, WCAG2 required that everything be accessible by the keyboard not by touch or by mouse. That's one of the reasons for 2.1. 2.1 definitely added mobile accessibility requirements around point gesture, geolocation, and things like that, but it wasn't enough.

Why is mobile different? Because, firstly, there are native screen readers built into the system, talk back in Android, Narrator in a Windows phone (if anyone has one of those anymore), and voiceover on iOS. Then, there are levels of volume control, haptic keyboard, visual, auditory, and vibrational things . . . There are things like increasing font size, touch and hold delay, screen rotation, high contrast, assistive touch, and mono audio.

Most of the time, with desktop, you have a whole array of different applications that you can use, like zoom text or something like that. With mobile, you are restricted to what is input to the device.

With 2.1 there were lasso page variations. Low-vision users are often restricted to a mobile view of the site on their desktop. If you zoom at 200 percent, often, that triggers the mobile version of the site. As part of WCAG2, 200 percent should already be included in regular testing. But, you need to make sure that you aren't removing functionality. It's important that the functionality is available on all variations of the page.

An example of this is YouTube, and this has been fixed. The upload and notifications buttons were visible at 100 percent but not at 200 percent, so people viewing at 200 percent could not view these buttons.

This is the example I am talking about. These are visible at 100 percent. At 200 percent, they're gone. If you're using the zoom function on desktop, you have triggered the mobile site, and the upload and notifications are not available because they assume you will use the mobile app.

There is also accessibility supported. You need to test assistive technology. This is made much clearer in 2.1.

Let's talk about methodology. It is important to note that this methodology does not include the errors in WCAG2. For example, this methodology doesn't include that your images must have all touch views, because that is covered in WCAG2. We are looking to expand the methodology to include that information, but at the moment, we're talking about things you have to do in addition to 2.1.

The kind of testing you need to do is test your desktop site against WCAG2, test your mobile site against WCAG2, and test the methodology.

If you take one thing from this presentation, take that you should always test with real devices. As I said, I did a lot of travel. I'm not sure what my life will look like in this current COVID world. Back when I first started traveling a lot to the United States, there was no WiFi on planes. And so, if you've ever flown to Australia, it's a 14-hour flight, a long time without Internet. Often, because flying that long you can't be guaranteed to know how long it will take to land, etc., we often sit on the tarmac in LA for an hour or two before a gate was available. We would get in LA, and I could access the airport WiFi. This is the screen I got. I logged in. It says, "This page will redirect." Content doesn't sense to have here. I don't feel safe giving my credit-card details.

If they are geolocked, you must test in real locations, where your users are going to use your systems.

There are four main testing methods. The first is, of course, to test on devices. The next is to test with devices with assistive technology or system features. The next is to test in a responsive window. It's easier to access the code when you test like that. You need to test also on a fully functioning desktop site, because you need to compare desktop and mobile sites.

For the native app, there are testing on devices, and testing on devices with assistive technology.

I will talk about site types, which is mobile sites only.

Excuse me a moment.

There are three types of mobile sites. There's a desktop website, which has only one display, whether viewed on a desktop or mobile or tablet device. Then there are m.dot sites, which have a particular display for mobile or desktop sites. You need to test m.dot on the desktop, and against WCAG2, as well as a www site against WCAG2.

This is an example of a desktop site, the Australia National Botanical Gardens. You have the left menu, header, and content. If you view that smellier on a mobile device, you see a cut-down version of the page. Nothing changes. You can do this by dragging the browser window narrow, or by viewing it on your mobile device.

The second is the m.dot site. There are three things you should do to identify an m.dot site. Ask the client, but often they don't know. Change the URL to have it start with an m. instead of a www. Do that on the desktop and the mobile. Then, compare the site on the desktop to the same site on the mobile device.

I run a mobile testing workshop, where we go into the guidelines in more detail. At Stanford, we ran it and found an m.dot site that many people didn't know about this. You need to take these three steps, because the client doesn't always know.

This is a sample website, www.sephora. I replaced the www. with m.dot, and I got something very different. I'll compare the two again. That's the www . . . and that's the m. If you make the screen smaller on both, on the left, the www doesn't make it smaller and the m.dot does. This is a site where you need to test against the two. Don't assume that a www site cannot be used on a mobile. One requirement is that you move between the www and m.dot site and vice-versa, and there will be people who access the desktop on the mobile.

Then, there are responsive websites. If it's responsive, it's not a desktop site. However, it's possible there is still an m.dot site.

To identify a responsive site, the site will change, the layout changes as you change the browser window. Test this by opening the page in the browser, make sure the window is not minimized, and select the lefthand edge and drag it to the center of the screen.

Here, you have the top navigation along the top, and you have one row of six items of services. If we make that smaller, the navigation turns into a hamburger menu, and the services are 2x2 instead of 6x1.

I will talk briefly about variations of a page, also mobile site only. You must test each variation of the page against MCAG2 and the godliness. All functionality is available on all variations of the page. You can hide the functionality, behind an expendable menu or a different page, but you must have all functionality in all variations.

Why do people provide variations of a page? Maybe to hide or show image details. There is also, of course, a hiding functionality that doesn't work on mobiles, such as a drag-and-drop, where you must provide alternative but equivalent functionality.

There are four main triggers for variation of a page. The device is one. You will get different content on a desktop versus a mobile. You can also determine the operating system or the browser. The most common way to trigger a variation in a page is screen size. That accounts for probably 95 percent of variation in responsive sites.

I talked a bit about this before, where you have the navigation on AccessibilityOz horizontally, then placed on a hamburger menu. These are two separate pieces of code, and, therefore, must be tested on mobile and native app against WCAG. You must test both.

If you have something like this, you have a variation in just the presentation, the way you have the ICT Accessibility Testing Symposium, Home, Committee, Register, and Program across the page, and, when you resize it, they become vertical. You need to test only one of these, and one keyboard focus indicator and things like that.

As I mentioned, each variation of a page needs to be tested.

Talking about native apps, we discussed a lot about them and how we should really look at testing. We decided that we needed to look at specific elements in native testing.

The first thing to do is to define application functionality. You need to know the purpose of the native app and what functionality is critical to its purpose and use. Look at it from a workflow perspective, because on a website you can get to any of the thousands pages through a myriad of ways, but often, in a native app, you can only get to a screen or a page in one way. That changes how you do testing.

For example, if you're looking at a banking mobile app, it's really important that the login process works, that you can transfer money, that you can do the two-factorial authentication, etc; whereas, if you're looking at a bank mobile site, then you're looking at a range of things, like whether the map and store locator works.

Basically, the things that you should really focus on are things like navigation, menus, headers, footers, landing pages, emergency alert pages, login pages, settings, account and profile, Contact Us, real-time updates, privacy policies, terms and conditions, interactional/transactional, widgets, calendars, and date, and high-traffic areas.

Then ask, how would the experience be impacted if this functionality failed, or this content couldn't be reached? If that happens, will that mean the user can't use the native app? And then, of course, everything in your not app must be accessible. However, it's important to define critical functionality and make sure that is prioritized in your testing.

Let's talk about the methodology. There's one major difference between the mobile-site methodology and the native-app, and that is step 2. There are five steps. Step one for the mobile site is to identify mobile devices; step two is to identify site type and variations; step three is test critical issues . . .

For the native-app methodology, step one is to identify devices, step two is to define application functionality, step three is to test critical issues . . .

Let's talk about identify devices. For the mobile site, you're looking at iPhone and safari, iPad and safari, and Android and Chrome. You should use Chrome if you're using Samsung, because it's a better representation of how things will appear across all phones.

Other devices include Android tablet and Kindle.

We recommend that you test on the latest version of iOS and on the latest two versions of Android. If a site is directly aimed at people with a particular kind of disability, consider assistive devices and technology. If the site is aimed at switch users, test switches.

You need to meet WCAG2 and this mobile methodology.

For the mobile site, you need to identify site variations of the page. First, identify if the site is desktop-responsive or m.dot. You will have a list of various pages and things you need tested.

For the native app, you need these common elements. Then ask the question.

Then, testing critical errors . . . Now, we identified a series of traps in mobile sites and native apps. We called them traps because we thought they were the equivalent of the keyboard trap in WCAG2, where a user enters into an element they can't escape by using the keyboard. This is most often seen in video players. There are more traps in native apps than on desktops. We categorize these traps.

An 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 . . .

This is an example of an exit trap. You are on a website that you accessed through feedback, so you're on a native app. This ad for HP overlays the entire page and there's no way to close it. This often happens when an app.

Here, you've got a pop-up that talks about a fall sale, and a close button that doesn't meet color-contrast requirements.

Then we have a swipe/scroll trap. Ensure you do not override standard mobile touch functions on the majority of the page. This applies to touch users only, and the methodology is both native app and mobile.

You scroll to the button but you can't scroll back up. To go back up the page, you activate the arrow on the bottom righthand corner.

This is an example I've been using for six or seven years, now. I'm sure it doesn't exist anymore. I call it the zoom of doom. If you swipe anywhere in the map, which takes up most of the screen, you move the map. To move the page, you hit that small area of white that surrounds the map.

Then we have a text-to-speech trap. If the app has an ability to provide contact via text-to-speech, the screen reader user must be able to pause or stop the app speaking in a simple manner. This applies to screen-reader users.

This is an example. Once you press play, the screen reader can't stop the text-to-speech, so they have to wait, or close the native app and start again.

The headset trap. The headset users must always be able to pause media content by using the pause/play control on the headset.

This is an example here, where you're on a website and a video pops up in the bottom-righthand corner, and you have a little mute button in the righthand corner of the video that is not accessible, and you can't pause the audio of that video using headset hardware. The pause on the headset pauses the screen reader.

Then we have a layer trap. This is applicable to all users, and the methodology is mobile and native app. Here is an example. If you open the menu for this website, you attract the page underline in the menu. The page opens on the current screen. You can interact via touch. If you're a screen-reader user, you're still reading the content underneath.

Then we've got testing mobile-specific issues. I'm going through a few of these, but the documents which detail all these things will be available on our website. They are also on the ICT mobile site. You're welcome. These documents are available under creative commons, so you're welcome to use them and read them and use them to your heart's content.

First, there are alternatives. We require alternatives provided for non-Web mobile functionality that is mandatory.

For example, this is a dating app called Bumble, and it's to prove that you're a person and not a bot — you copy the gesture in the photo to prove who you are. It says at the very bottom, "Need another way." If you're vision-impaired, you don't know what you're supposed to do. However, when you activate that, you must type your message. It doesn't tell you what you need to do, and it's not — it definitely is close to being accessible, but it's not perfect.

Alternatives are provided for geolocation functionality that is mandatory, unless the geolocation is essential for legal reasons . . .

For example, in this, with IKEA, in Australia, if you access the app and you've blocked your location, you get a pop-up that says you must turn on the location feature.

I indicated my pickup location in this app. You can bypass the location.

Another alternative is changes of state. We're talking about hamburger menus most of the time. Hangs of state of non-standard controls are clearly indicated. When you close the hamburger menu, you get just a hamburger menu. When the menu is open, the hamburger menu item changes to an arrow. The state of the actionable item has changed visually as well as in terms of what is read allowed by the screen reader.

Then we have display. There are a number of other requirements. I'm just going through some examples.

Size of touch targets is at least 44 by 44 CSS pixels, approximately 7 to 10 millimeters, which, of cause, with WCAG2.1 target size, which is AAA . . . This is an example where it fails. You go to the Airbnb site on your mobile, and it pops up that you install the app. To close it, you must hit a small "x" in the lefthand corner on close the app.

This is an example of pass-to-touch target size. You have these sections, "To," "Cc/Bcc." These are good target sizes in terms of this requirement.

Another is that actionable items have sufficient inactive space between them, of at least 10 pixels, around active elements.

Here is an example. In the top-right corner, you have an "Edit" button and a "Marked Complete" button, and there are only five spaces between them. You can easily hit the wrong button.

Then we have the actionable items. Native UI controls, objects, alerts, and elements have been used. This is an example where you have some weird widget drop down. They have made it a text box, rather than a select box, of "14," "15," "16," and "17," but it also pulls up the keyboard. You can't actually use the keyboard, and you can select only four of the numbers.

When direct input via the keyboard is not required, provide options for the user to achieve the same result. This is an example here, where you have to type in absolutely everything. If there are only 50 states in the United States, there should be a dropdown. It's not something you should always have to type in.

This is an example. You have written 2001m, and you see the options that accord with what you've written.

Functionality that can be operated by device motion or user motion can also be operated by user interface components, and responding to the motion can be sable to prevent accidental . . .

Here is an example using an iOS device and you shake it, where you get an "Undo Typing" alert. This fails. The same thing happens with Facebook, where you shake it and it asks if you want to report a problem. You can do it through other means, but you cannot turn it off.

Another example is infinite scrolling.

Navigational aids — visual indicators have been used to indicate swipe or scroll areas or additional areas for functionality. Here, if you swipe from right to left, you go to the next section. However, there is no indicator that swiping horizontally will do that.

Navigational aids are provided. Here, the way you actually close this is by swiping from the top down to the bottom. However, there's no indicator that that's what you need to do to actually escape from this page.

Audio and video — we require that all audio and video have accessible transcript. Here, the text is below the video.

Forms — field labels are positioned adjacent to their input field and appear closest to their respective input field . . .

This is an example where you've got the "Yes" radio button, slightly closer to the "No" field label than the "Yes" field label.

Then we talk about this testing. Item labeling between . . .

This is what I mentioned before, how my tasks were missing.

Then, you need to test mobile assistive technology and features. You need to make sure all actionable items can be accessed and activated by the following assistive technologies and all important content can be accessed by the same.

Here is a list of mobile assistive technologies and features, in both iOS and Android.