Native mobile accessibility testing: compliance, tools and tips (Funka Accessibility Days, November 2020)

Editor's Notes

• #2: Hello! My name is Jon. I’m an accessibility consultant. And I’ve been working on accessibility in native mobile apps for the past 8 years.
• #3: Today I’m going to take you through: What does it mean to be accessible on mobile? What does compliance look like? How do we test for compliance of mobile apps? There are lots of links to references and resources in the presentation notes, which will be made available online later. So don’t worry too much if you miss something I say.
• #4: What does it mean to be accessible on mobile? On the Web we have technologies like ARIA, which allows us to create web applications that are experienced by disabled people in the same way that they would expect a desktop application to work. On mobile devices, we have smaller screens. We are often talking about touch screen devices. We are working in changing environments, rather than being sat still at a computer. One of the main issues we have with native platforms is that there are platform-specific contexts and therefore different user expectations to the Web. For example: There are differences in keyboard behaviour, and with what we might call focus order. For example, back buttons receive focus on iOS, but they do not on Android because there is expected to be a software back button provided by the Android operating system, or a physical back button on the device or on an attached keyboard. Form fields carry different expectations on different platforms, as their associated interface guidelines suggest different implementations. Today, we’re going to focus on the most mature of the mobile platforms, Android and iOS. And we are going to focus on native code and not hybrid apps.
• #5: Basics are the same as for web Names – as you might expect: text labels, text alternatives for image, form labels, heading text Roles – handled automatically provided you use the standard user interface components for the platform States and Values – also typically handled for you While developers have some control over accessibility information – which you need when building custom controls – a lot of it is handled automatically. On iOS, developers are able to set their own roles and states. While this allows greater flexibility, it can result in unexpected or less consistent accessibility experiences when we test our apps. The most important thing to check is the accessible name. It’s also important to note that some things we experience all the time on the Web have taken some time to gain support on mobile. For example, headings: = September 2012 with iOS 6.0 = August 2018 with Android 9.0
• #6: What does legal compliance look like with mobile apps?
• #7: Particularly of interest in Europe at the moment is EN 301 549, an EU digital accessibility standard. It requires that all mobile apps in the public sector comply by June 2021. A lot of legislation currently either quotes WCAG 2.0 conformance to Level AA or it is implied. New versions of this EU standard have been updated to reflect the new requirements introduced by the Web Content Accessibility Guidelines version 2.1.
• #8: Now, I want to talk about WCAG 2.1. It’s been around for a couple of years now. The general principles and the guidelines that it outlines equally apply to native mobile apps. But we have a problem when we try to use the success criteria to test native apps.
• #9: When we try to apply Web guidelines to native software, there are going to be issues. Version 2 of the Web Content Accessibility Guidelines may have been designed to be applicable to all technologies, but it still uses terminology and measurements that are specific to web technology. And it is missing platform-specific context and user expectations. Ever since the first smart phones, WCAG and its documentation didn't map well to mobile. So, companies like Funka and the BBC ended up creating their own mobile guidelines. Today, despite being relatively new, WCAG 2.1 still uses terminology that doesn’t match the context of native mobile, even though there are new success criteria for touch screen and mobile devices.
• #10: Some examples: Talk of “Web content” and "Web technologies” Talk of "Web pages" Talk of “CSS pixels” in success criteria thresholds. Talk of ”content implemented using markup languages" This should change with the next version of WCAG (Silver / AG / W(3)CAG). The W3C's Accessibility Guidelines Working Group is working to produce a set of guidelines applicable to wider technology. In the meantime, some success criteria can be applied to native mobile apps… [NEXT…] “in the spirit of” their intended purpose.
• #11: …in the spirit of their intended purpose. When I’m writing accessibility audit reports for mobile, I use this phrase borrowed from Patrick H Lauke. The tricky thing to decide here is whether or not you feel that an issue you find “in the spirit of” a WCAG success criterion is actually a failure of the guidelines, or a best practice. This is important when it comes to the European Standard, though, because it requires conformance to WCAG as interprets the guidelines for non-web software, which includes mobile applications. For example, page titles… Following WCAG to the letter, 2.4.2 requires that “Web pages have titles that describe topic or purpose.” A screen in a native mobile app is not a web page, and therefore this success criterion is not applicable. In fact, Page Titled is not required for conformance to EN 301 549, as noted in section 11.2.4.2. But it is possible to implement something similar as a screen title. I flag some issues as best practices “in the spirit of” WCAG, but it is up to you to decide if it’s a best practice or a failure against the standard you are testing to.
• #12: I don’t expect you to be able to read these. We’re going to play WCAG Bingo! and cross some of these off. This is a list of all 78 success criteria in WCAG 2.1. I won’t be able to cover all of these today, but I can talk about the major stumbling blocks based on my experience. I’m going to translate some of these success criteria for use in native mobile apps and relate them to my test process. I’m going to assume that everybody here is familiar with using WCAG 2.1 as it relates to Web content.
• #13: If we remove all AAA issues that are not required for legal compliance, we are left with 50 success criteria at Level AA. In terms of compliance, when I’m testing against AA, I will often report AAA issues that I find as best practices. One AAA requirement in particular comes up with native mobile apps – Target Size – which I’ll talk about more in a moment.
• #14: Some success criteria are essentially the same on mobile as on the Web. For example, I’m not going to talk much about colour or multimedia today. Some things to note here, however: Non-text Content iOS 11 introduced a feature that uses artificial intelligence to try to make sense of unlabelled user interface elements. VoiceOver will announce to users “Possible text:” and then try to describe the element. However, this is often not enough to clearly label the element. Info and Relationships I mentioned form fields earlier and that there are differences in the expected behaviours on native mobile apps. It’s worth taking note of the expected behaviours in native apps bundled with the platforms – such as the settings apps – but this requirement is essentially the same as on the Web. Consistent Navigation / Consistent Identification Consistent Navigation and Consistent Identification are not required for conformance to EN 301 549, as noted in sections 11.3.2.3 and 11.3.2.4. Status Messages When a dynamic message appears, it must be announced by screen reader software. Features exist on both platforms that allow this to happen, yet it is often missed by developers, so it is worth testing for.
• #15: Okay, let’s quickly cover a few more success criteria that are essentially not applicable to native mobile apps. Text Spacing While it’s possible for developers to control text spacing, this is not a user preference setting on native mobile platforms. The situation may change in the future, however. We can implement our own accessibility settings for this within our apps, of course. It's up to you to decide if this is a failure or best practice. [NEXT…] More information: Android: android:letterSpacing (Android 5.0 Lollipop, API 21) – https://developer.android.com/reference/android/widget/TextView#attr_android:letterspacing iOS: NSKernAttributeName (iOS 6.0+) – https://developer.apple.com/documentation/uikit/nskernattributename
• #16: Content on Hover or Focus This tends to not happen on native mobile since people are often using a touch screen device and generally not using mouse or keyboard. Again, this situation may change. More on keyboard accessibility later on.
• #17: Bypass Blocks Screen content on mobile tends to not require a way to bypass blocks because of small screens. Navigation menus are often revealed using a button and so don't need to be bypassed. Where navigation menus are visible – such as on larger tablet screens – the expectation is that people using a screen reader can jump to a heading at the top of the next panel of content. People using a mobile screen reader are provided with navigation features that can help jump to different types of elements. However, such useful navigation features simply do not exist for people who rely on keyboard to navigate apps. While screen elements can now be identified as headings on both Android and iOS, Android does not yet provide a way to navigate by heading. More information: Bypass Blocks is not required for conformance to EN 301 549, as noted in section 11.2.4.1.
• #18: Multiple Ways The number of screens in mobile apps is typically small, and so I find this success criterion is difficult to apply in a useful way. One useful example can be found in native settings apps, where a search field can be an extremely helpful alternative to navigating through menus.
• #19: Focus Visible Android and iOS handle focus indication in native apps for you – a rectangle is shown around elements as they come into focus. However, a common issue is experiencing elements that are not visible on screen and yet receive focus. This causes focus indication to disappear, and it can even make focus reset back to the top of the screen. These are the observed effects of a different problem rather than a problem of visible focus.
• #20: Language There is currently no way to specify the language of an app in Android or iOS for accessibility purposes. You can localise an app to different languages, but this is not the same thing as identifying the primary language for accessibility. Screen reader software on mobile platforms use the language set in the user’s operating system settings. Changes in language Both VoiceOver on iOS and TalkBack on Android (since Android 8 Oreo) can detect languages and adjust their speech output as needed. On iOS, you can control the language of individual views within an app if you need to. On Android, you currently have no control over this. More information: Language of Parts is not required for conformance to EN 301 549, as noted in section 11.3.1.2.
• #21: Parsing Since this success criterion relates to markup languages, this is not applicable at all to native apps. More information: While user interfaces on some platforms may be defined using XML, the creation of these files is either a transparent part of the development process, or require robust code to work with the target platforms at all, let alone any assistive technology working with those platforms.
• #22: What’s left? I’ve found some of these require interpretation when working on native mobile platforms. Let’s take a look through these.
• #23: Some of the remaining criteria are part of the 17 new success criteria in WCAG 2.1. Some people are still getting used to these, so let’s quickly talk through the ones that apply to mobile.
• #24: These 8 new success criteria are very relevant to mobile: 1.3.4 Orientation (AA) Allow screens to be used in either orientation (landscape or portrait), as some people cannot rotate their device. I find that it is very common for native mobile apps to lock users to either landscape or portrait. Be sure to test with orientation lock settings turned off – Auto-rotate (Android) or Orientation Lock (iOS) 2.1.4 Character Key Shortcuts (A) Allow users to turn custom keyboard shortcuts off or change them. Practically, this is rarely found in the wild on native mobile – mostly in games. 2.5.1 Pointer Gestures (A) Anything you do using a gesture – essentially, anything that isn't a tap – should be possible in some other way. This may be a button, for example. 2.5.3 Pointer Cancellation (A) Avoid touch-based functionality that users have no way to cancel. Essentially, actions are performed on releasing your finger and not on the down press. 2.5.3 Label in Name (A) Ensure that visible text labels are part of the accessible name used by assistive technology software. Voice control software is used a lot more on mobile devices. Voice software needs to be able to use the app code to identify controls that a user may trigger with their spoken commands. So, an accessible name should not only exist, it should match any visible text labels. 2.5.4 Motion Actuation (A) Movement of a device – such as shaking the device – must not be used as the only way of performing an action, and users should be able to turn off any such feature. 2.5.5 Target Size (AAA) Interactive elements should measure at least 44 CSS pixels in either dimension. This helps users to avoid accidentally pressing something they didn’t mean to. Note the use of Web terminology here, and that it’s a Level AAA success criterion. More on this in a moment. Incidentally, it looks like the next version of WCAG will bring a new success criterion related to this requiring suitable spacing between target areas (Pointer Target Spacing). 2.5.6 Concurrent Input Mechanisms (AAA) Allow people to use the input devices that suits them best. Don’t assume what that may be and disable something that someone may rely on. This is most easily tested by experience – using accessibility features to check that nothing has been disabled.
• #25: The others also important for mobile are: 1.3.5 Identify Input Purpose (AA) People with mobility issues have difficulty entering data into the fields. People with cognitive disabilities may have difficulty remembering details. Support for tools that can help with this is still in its early days on mobile. But some of the code features required to make this a reality are already available in Android and iOS. This success criterion is often ignored in mobile accessibility audits because it does not match up with the standard HTML5 autocomplete values. 1.4.10 Reflow (AA) When we change device orientation, we expect content on screens of our mobile apps to visually reflow without loss of content. Most of the time I find apps reflow with no issues. However, problems do arise when we test for resizing text. More about that later.
• #26: Now that we’ve reviewed the new WCAG 2.1 success criteria, we have a small number left to discuss. These can be covered off by telling you a bit more about my test process, so let’s do that…
• #27: Analysing code requires access to code, of course. This is something your development team can do to test as they build. For iOS apps: Xcode doesn’t really have an accessibility linting tool as such, but does have different tools that we will talk about in a moment. For Android apps… [NEXT…]
• #28: Android Studio has a linting tool that gives warnings about accessibility issues. This slide shows the Lint tool displaying some accessibility issues in an app. [NEXT…] More information: Found under *Android > Lint > Accessibility* https://developer.android.com/guide/topics/ui/accessibility/testing#lint
• #29: Generally speaking, it’s estimated that around 30% of the Web Content Accessibility Guidelines can be tested using automated tools. We may be talking about native apps here, but the situation is much the same. And as with any automated testing tools, they can falsely report issues. Several automated testing tools exist for checking your Android and iOS apps. Google provides Accessibility Scanner for Android. Apple provides Accessibility Inspector for iOS. Both of these detect accessibility issues on your screens then suggests how to fix them. [NEXT…] More information: Android Download Accessibility Scanner – https://g.co/accessibilityscanner Get started with Accessibility Scanner – https://support.google.com/accessibility/android/answer/6376570 Info on reading Accessibility Scanner results – https://support.google.com/accessibility/android/answer/6376559 iOS Accessibility Inspector is built into Xcode Xcode > Open Developer Tool > Accessibility Inspector (or stand alone)
• #30: Accessibility Scanner runs on your Android device. It must first be downloaded to your device, then enabled in Android’s accessibility settings. This adds a floating button on your screen that is used to start the scanner. You then open your app for testing, and activate the scanner. It detects issues on a screen or a series of screens in your app, and suggests how to fix those issues. Full list of checks in Accessibility Scanner: Item label missing (accessible element names) Item labelled with type or state Duplicate item descriptions Editable item label Touch target size Resizable text Text and image contrast Clickable links Duplicate clickable views More information: Note: If you distribute your app on Google Play, you have access to a pre-launch report for your app, which includes the results of accessibility tests using the same engine used for Accessibility Scanner.
• #31: Accessibility Inspector comes with the iOS development environment, Xcode, and it runs on your Mac. As its name suggests, it allows you to inspect your iOS app’s interface elements for accessibility information. This works with the Simulator on your Mac or with an attached iOS device to test any app on that device (requires an Apple Developer Program license). It has an audit feature, that will scan for common accessibility issues and suggest how to fix them. It also allows you to manually check support for the iOS accessibility preference settings, such as Increase Contrast, Reduce Motion, etc. Full list of checks in Accessibility Inspector: Accessibility labels (accessible element names, “Element has no description”) Missing accessibility information (usually custom interfaces, “Potentially inaccessible element”) Something to note here: Inspector unhelpfully describes missing accessibility information in custom interfaces as “Potentially inaccessible element” Image has no label Image name used in description Colour contrast Touch target sizes Dynamic Text support (resizable text)
• #32: It’s when I run these automated tools that I find most issues with touch target sizes: As I said earlier, this is a best practice as a Level AAA success criterion and is not required for conformance. Research shows that the minimum touch target size for any element is 7mm x 7mm. Anything smaller than this size makes it difficult for users to hit the element using a fingertip, but especially difficult for those with less touch dexterity. WCAG 2.1 requires a minimum of “44 CSS pixels”. On Android, this can be interpreted as a minimum of 44 density-independent pixels. On iOS, this can be interpreted as a minimum of 44 points. However, Google recommend meeting a minimum touch target of 48 density-independent pixels in Android apps, which is approximately 9mm on many screens, but this does ensure that targets are never smaller than 7mm regardless of screen size. Accessibility Scanner flags any touch dimension that is less than the recommended 48dp. More information: Target Size is not required for conformance to EN 301 549, as it is a WCAG 2.1 Level AAA success criterion.
• #33: It’s worth noting that there are other automated tools that are best used as part of your continuous integration toolkit. These help to stop changes to your apps from breaking basic accessibility over time. And it helps keep your teams on the lookout for accessibility as they work. The tools listed here are worth taking a look at. [NEXT…] More information: GTXiLib is Google’s open source toolbox for Accessibility for iOS, test logic for detecting common accessibility issues that works with unit testing frameworks. Google's Accessibility Scanner for iOS (GSCXScanner), uses GTXiLib. Deque’s axe™ DevTools (formerly WorldSpace Attest), available for both Android and iOS, is a framework you incorporate into your app code that helps detect and inspect for some common accessibility issues. https://www.deque.com/android-accessibility/ https://www.deque.com/ios-accessibility/
• #34: It’s important to test the actual user experience for people using screen reader software. This will often uncover many of the technical issues that automated tools do not. On Android we have TalkBack, also known as Android Accessibility Suite. On iOS, we have VoiceOver. Both are powerful, yet fairly easy to learn to use. [NEXT…] More information – common issues we may find while using a screen reader: Controls with no accessible name Custom interfaces missing accessibility information or behaving in unexpected ways Missing roles, where people using screen readers will not know how to interact with a control or how it will behave Incorrect roles – I’ve seen text fields used to display body text Hidden elements experienced Visible elements not experienced Changes of state not experienced Poor support for text resizing
• #35: There are 2 main interaction methods used by both Android and iOS.
• #36: The first method is “explore by touch”: You place your finger on the screen and move it around Items under your finger are described by the screen reader You double tap to activate items, or you can tap with a second finger as well This interaction is spatial – it requires users to become aware of the layout of a screen This is the best way to interact with on-screen keyboards – it’s a bit like touch typing
• #37: Gesture navigation: It’s sequential, typically following the reading order of a screen Users interact with one element of a screen at a time Users swipe right to move a virtual focus cursor forwards through content, and swipe left to move backwards You double tap to activate items
• #38: An important thing to note on native mobile, is that you can detect the presence of an assistive technology, something we can't do on websites. We can argue, in fact, that we should not detect a person's assistive technology. Something that detection can be helpful for, though, is for stopping auto-playing any audio or video content. On iOS, app developers also have the option of checking isVideoAutoplayEnabled.
• #39: Page Titled This is often missed by mobile accessibility audits. I test for this, but you may decide it is not needed. Let me explain… It's not well documented for Android or iOS, but it is possible to add titles to screens of native mobile apps. On iOS, it's of less practical use, but you can add what's called a Summary Element trait. However, it doesn't give the same behaviour as the page title on a web page. Summary Element is only announced by VoiceOver on application load. It is meant to explain the current state of an application. For a weather app, for example, this may be a summary of the current weather conditions. On Android, we have activity titles, which can be updated dynamically as different screens load. You can mimic the experience of a web page title being announced by screen readers, but the question then becomes, should you do that when it’s not expected behaviour? [NEXT…] More information: Page Titled is not required for conformance to EN 301 549, as noted in section 11.2.4.2.
• #40: I want to talk about keyboard control and how this differs from controlling a screen reader on mobile devices. Keyboard accessibility is where we typically look at focus order and visible focus styles on the Web, as well as focusable state and focus management. While focus on mobile devices is similar to that on the Web, there are differences. There are two concepts of focus to understand on mobile devices: input focus and the virtual cursor. Input focus is like keyboard focus on the Web – interactive elements receiving focus in a sequence. The virtual cursor – or as I sometimes call it, accessibility focus – is where all accessible elements are experienced and read in a sequence by mobile accessibility features. But let’s talk about true keyboard accessibility on mobile… While users do not typically interact with mobile devices using a mouse or keyboard, people may be using a directional controller or connected Bluetooth keyboard. On Android, links, fields, buttons and other controls in the content can be accessed using a keyboard in a sequence. Android also provides support for directional controllers – such as a D-pad – which can be described as input focus. However, the directional focus orders (up, down, left right) can be set independently of the linear focus order of keyboard navigation using the Tab key. It is possible to support hardware keyboard control in iOS apps. However, true native keyboard accessibility in the way we think of it on the Web hasn’t existed in iOS without using VoiceOver. Earlier this year, iPadOS brought support for keyboard. Users can navigate using arrow keys and activate items with the space bar. Typically, focus order in native mobile applications is automatically determined based on the layout of controls and views. Focus order runs from the top-left to the bottom-right of each view, unless a custom order is defined in the code. Manually check keyboard accessibility using a Bluetooth keyboard attached to a device and navigating through screen content using the Tab key or arrow keys. [NEXT…] More information: Developers can hook into key pressed on hardware keyboards from iPadOS 14. While there are a small set of keyboard only commands, accessible keyboard navigation and control is tied to using VoiceOver and therefore there is only accessibility focus and no true keyboard focus. Focus management Generally, moving focus on behalf of the user should be avoided. However, it may be necessary to manage focus on behalf of the user in specific situations. When moving from one screen to another, initial focus is usually set automatically by the operating system. If this is not the case, an expected initial focus should be set. There are other situations when focus may need to be managed. Just as on the Web, when moving to a modal view, focus is expected to remain within that view. When a modal closes, focus typically returns to the location that triggered the modal. https://developer.apple.com/videos/play/wwdc2020/10109/ https://developer.apple.com/documentation/uikit/keyboards_and_input/adding_hardware_keyboard_support_to_your_app https://developer.apple.com/documentation/uikit/mac_catalyst/handling_key_presses_made_on_a_physical_keyboard
• #41: Testing with voice commands On Android, we have Voice Access. On iOS, Voice Control.
• #42: On Android, speech input is provided through Google's "Voice Access" application, which is enabled in *Settings > Accessibility > Voice Access*. Voice Access is then activated by saying "Hey Google". You need to check that all controls on the screen respond to voice commands. Voice Access visibly labels all interactive elements with a number. Each numbered item should activate when you give the command "Tap ITEM NUMBER".
• #43: On iOS, Voice Control can be enabled in *Settings > Accessibility > Voice Control*. You can also enable it by saying "Hey Siri, turn on Voice Control". Voice Control can display item names (labels) by saying "Show names". All interactive elements should then be visibly labelled with a name. Each named item should activate when you give the command "Tap ITEM NAME". Voice Control can also display a grid navigation tool by saying "Show grid". You then select the item you want to activate by saying the grid numbers until the required item is selected. Again, check that all controls on the screen respond to these voice commands.
• #44: Most modern websites have responsive designs that adapt and reflow well to fit small screens. While it is common to find that content in native apps reflows well with different screen sizes or device orientation, adaptability to text size is often forgotten.
• #45: WCAG requires us to test at a text size of 200%. There is currently no way to set text to 200% on Android or iOS, but I test using the closest setting. On Android this means “Largest setting” = approx. 132% (the largest possible)
• #46: On iOS, this means stop 10 with Accessibility Sizes enabled = approx. 235% Note on iOS: Stop 9 / 2nd accessibility size = 46.5px = 193.75% Stop 10 / 3rd accessibility size = 56.5px = 235.4% So I say that Stop 9 at 193.75% is good, but Stop 10 is needed for WCAG 2.1 compliance.
• #47: But be careful! Not all items resize on Android and iOS. For example, on iOS text labels in the bottom Tab Bar do not resize with increasing text size settings. This is because of restricted space in the interface. It is deliberate behaviour, meaning it is expected behaviour for experienced users. Instead, users are shown a large preview of the tab item when they hold their finger over them. [NEXT…] More information: When "Larger Accessibility Sizes" is enabled in the Larger Text settings and an accessibility size is then selected, a large preview of the tab label appears in the middle of the screen when users press and hold their finger over (long press) the Tab Bar items. A similar thing happens for Segmented Controls on iOS – a drop down appears.
• #48: On Android, however, text labels in a bottom navigation bar do resize with increasing font size settings. The two screenshots here show what can happen to text labels as space on the screen gets reduced – the text starts to get cut off.
• #49: In contrast, title text in top app bars on Android do not resize with increasing font size settings. Again, this is deliberate because of restricted space in the interface.
• #50: Lastly, it’s helpful to take screenshots as you test a native mobile app. I take screenshots all the time as I audit. This is usually done with some combination of the hardware volume buttons and the power button or Home button. Automated scans may find some colour contrast issues, but not all. Having screenshots lets me manually check for colour contrast issues with text and images.
• #51: What does it mean to be accessible on mobile? Mobile accessibility is different to the Web, and it’s important to understand the differences. What does compliance look like? Compliance is currently quite fragile, because the guidelines and standards don’t match the context of native mobile platforms. How do we test for compliance of mobile apps? Testing has some subtle issues to look out for. I hope that this talk will help you with navigating these issues.
• #52: Thanks for listening to me, Funka Accessibility Days. It’s time to take some questions.
• #53: END