Tools design to support accessibility testing on

mobile applications

Cristian Camilo Novoa Avellaneda

Aug, 2020

Bogotá, Colombia

Systems and Computing Engineering DepartmentFaculty of Engineering

The Software Design Lab

Tools design to support accessibility testing onmobile applications

Cristian Camilo Novoa Avellaneda

Advisor Ph.D. Mario Linares VásquezSystems and Computing Engineering DepartmentUniversidad de los Andes, Bogotá, Colombia

Aug, 2020

Cristian Camilo Novoa Avellaneda

Tools design to support accessibility testing on mobile applications

Undergraduate Thesis, Aug, 2020

Advisor: Ph.D. Mario Linares Vásquez

Universidad de los Andes

The Software Design Lab

Faculty of Engineering

Systems and Computing Engineering Department

Cra 1 # 18A - 12

111711 and Bogotá, Colombia

iv

Abstract

Mobile applications have become a must-have in everyday life and their developmentis always improving as new methods and tools do to allow a better user experience.During the development of an app, the developers must ensure different qualityattributes and one of these attributes is accessibility. However, this quality attributeis mostly ignored during development and requires a big effort to test it.

The purpose of this paper is to develop a tool implementing an Android accessibilityservice, that will supports developers during the development of an app, show tipsto make an app more accessible by developing an app, and why it is so important tomake applications more accessible.

There are two repositories for this project. The first one is the app that was developedin two different versions (one that is accessible and the other that is not) that canbe found on https://github.com/ccnovoa11/accessibility_apps. The secondis the tool prototype that supports the accessibility testing and can be found onhttps://github.com/ccnovoa11/accessibility_tool_demo.

v

Contents

1 Introduction 11.1 Thesis goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Thesis contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Thesis Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Related Work 32.1 Static analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Google’s tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2.1 Accessibility Scanner . . . . . . . . . . . . . . . . . . . . . . . 32.2.2 Espresso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.3 MATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Proposed Approach 53.1 General Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.2 Apps analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.2.1 Resize Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.2.2 Screen orientation . . . . . . . . . . . . . . . . . . . . . . . . 93.2.3 UI not depend on color . . . . . . . . . . . . . . . . . . . . . . 103.2.4 Multi-language support . . . . . . . . . . . . . . . . . . . . . 11

3.3 Developing an accessible app . . . . . . . . . . . . . . . . . . . . . . 133.3.1 Not depend on color . . . . . . . . . . . . . . . . . . . . . . . 143.3.2 Content description redundancy . . . . . . . . . . . . . . . . . 143.3.3 Localizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.4 Tool prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.4.1 Tool development . . . . . . . . . . . . . . . . . . . . . . . . . 163.4.2 Testing the tool . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4 Conclusion 234.1 Findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Bibliography 25

vi

1Introduction

During the development of an application (web or mobile), one of the qualityattributes to consider is accessibility. Accessibility in software is defined as how userswith disabilities can access a solution [1].

In the case of mobile applications, there are native supports for both operatingsystems such as screen readers (TalkBack for Android and VoiceOver for iOS). Touse these tools on the applications, the developers must use the accessibility APIsoffered for each platform.

Accessibility in mobile applications is important because mobile devices have becomethe most used device by people. In the UK, 52% of network connected devicesare smartphones [16]. To do accessibility tests, there are different ways suchas navigating the application using only the screen reader or using the Googleaccessibility scanner [11] (just for Android apps).

The problem with these solutions is that they require human intervention, and as theapplication acquires new functionalities, the effort to test grows. Test automation isused for this, due to is faster than manual testing [15]. However, there are currentlynot enough tools to perform automated accessibility for mobile applications, andsome of them have limitations.

1.1 Thesis goals

The main goal with this thesis is to build a tool that helps to perform accessibility testsin mobile applications. According to the objective above, the specific objectives forthe project are:

• Investigate tools: Conduct research on the tools currently used to performaccessibility tests in Android applications.

• Apps study: Analyze the accessibility of some apps to find accessibility issuesthey could have.

1

• Proposed tool: Evaluate the performance of the proposed tool on his capacityto detect accessibility issues.

1.2 Thesis contributions

After finishing this project, it is expected to have an accessibility analysis of differentapps in order to show that even big apps could have accessibility issues. It is alsoexpected to have an app with two different versions, one with accessibility issuesand the other one without them, in order to test it with the proposed tool andexplaining a little bit how to make an app accessible. Finally, the prototype ofthe tool that will support the accessibility testing and how it works with the apppreviously mentioned.

1.3 Thesis Structure

Chapter 2 presents related work respecting previous studies and tools that supportaccessibility testing. Chapter 3 describes the proposed approach describing carefullyevery detail of the analysis of the apps, the development of an accessible app, andhow was the prototype tool created. Chapter 4 concludes the document, revisingour contributions and defining future work.

2 Chapter 1 Introduction

2Related Work

2.1 Static analysis

The first study found by C. Vendome et al. [17] its about a solution where accessi-bility was evaluated through a software tool that performed static analysis on theapplication code. This tool searches the attributes contentDescription or hint intothe elements of a view’s XML file, because these are the attributes used by screenreaders to read the description of an element. It also searches into the code for thesetContentDescription() and setHint() methods when the descriptions are placedprogrammatically. The problem with this solution is that it cannot guarantee thatthe descriptions are useful to the user.

2.2 Google’s tools

Google provides different tools to test the accessibility of the applications. Thesetools are the Accessibility Scanner[11] and Espresso[9].

2.2.1 Accessibility Scanner

To use Google’s accessibility scanner [11], it requires to install the application on thedevice and activate it on the accessibility options from the device. After these steps,the developer can use the tool, which consists of opening an application and pressingan on-screen button to start the analysis. This tool evaluates that the elements havea description, have a size that is easily accessible to the user, and also the contrast ofthe colors. The limitation of this tool is that the analysis must be done manually foreach view and, like the previous study, it cannot verify that the description of theelements is useful.

2.2.2 Espresso

Google also offers Espresso [9], a tool for writing UI tests and that provides anaccessibility extension to verify different accessibility features with their respective

3

results. The problem is the little documentation that is found for this extensionbecause it doesn’t describe the checks it verifies, and the repository they link to isnot available. Another problem is that Espresso needs a specific script test for eachapp.

2.3 MATE

Finally, the last tool found is MATE (Mobile Accessibility Testing)[6]. This studyis based on the generation of automated tests to perform accessibility tests onapplications. The accessibility tests of this tool are focused on the visual impairmentthat some users may have. The tool is responsible for determining possible userinteractions with the application and executes them over time. During this run,MATE checks the accessibility in the elements it finds.

4 Chapter 2 Related Work

3Proposed Approach

3.1 General Approach

The defined approach is to demonstrate why it is important to make an app accessiblewith an analysis of some of the most used apps in the app store, show guidelines tomake an app more accessible, and finally by developing a prototype of a tool thatwill support the accessibility testing during the development of an app.

3.2 Apps analysis

Before the analysis, a little research was done to make a list with some accessibilityguidelines to consider during the development of an application. These guidelineswere found in the accessibility guidelines from W3C[18] and British BroadcastingCorporation(BBC)[2]. These are the following guidelines that were found:

• Content size (touch area).

• Resize text (if the text size is changed on the configurations).

• Contrast ratio.

• Screen orientation (Support for both orientations).

• UI not depend on color.

• Multi-language support.

• Speakable text.

• Duplicate speakable text.

• Duplicate clickable bounds.

5

Tab. 3.1: Comparison between the previous tools

Metric Static Analysis MATE Accessibility ScannerContent size (touch area) NO YES YES

Resize text NO NO NOContrast ratio NO YES YES

Screen orientation NO NO NOUI not depend on color NO NO NOMulti-language support NO NO NO

Speakable text YES YES YESDuplicate speakable text NO YES YES

Duplicate clickable bounds NO YES NO

Then, the tools were compared to determine which guidelines are not considered byany of them to use those guidelines for the accessibility analysis. As presented inTable 3.1, the guidelines that are not considered by the previous tools are:

• Resize text (if the text size is changed on the configurations).

• Screen orientation (Support for both orientations).

• UI not depend on color.

• Multi-language support.

For the analysis, 20 apps were selected in total. The first 10 apps were selectedbecause they are the most download apps of the decade[14]. The other 10 wereselected using the following criteria: the app can be downloaded in the Play Storeand it has at least 100M downloads.

The table 3.2 shows which were the apps with its corresponding version:

6 Chapter 3 Proposed Approach

Tab. 3.2: Apps selected for the analysis

App VersionTwitter 8.38.0Youtube 15.13.33

UC Browser 13.0.8.1291Tik Tok 15.5.5Skype 8.58.0.93

Snapchat 10.79.1.0Instagram 135.0.0.28.119Whatsapp 2.20.108

Facebook Messenger 258.0.0.18.119Facebook 264.0.0.44.111

Netflix 7.51.1Spotify 8.5.51.941

Telegram 6.0.1LinkedIn 4.1.436

Microsoft PowerPoint 16.0.12624.20224Microsoft Word 16.0.12624.20254Microsoft Excel 16.0.12624.20224

Duolingo 4.73.4Mercado Libre 10.42.6

Dropbox 200.2.8

3.2 Apps analysis 7

3.2.1 Resize Text

The resize text means the app’s capacity to change the text size when the device textsize is changed globally. To execute this analysis, the global text size was changed inthe device configuration and then navigate through each app.

In this scenario were found 8 apps with this issue. Microsoft apps in general didn’tresize the text, just like Tik Tok and Telegram (see figure 3.1 (B)(D)(E)(F)). Otherapps like Twitter and Instagram resized the text but had some UI problems (seefigure 3.1 (A)(C)).

Fig. 3.1: Findings for resize text analysis.

8 Chapter 3 Proposed Approach

3.2.2 Screen orientation

The screen orientation means the app’s capacity to change its landscape according tothe user ability and preference. To execute this analysis, the app was used with ahorizontal and vertical landscape.

In this scenario were found 7 apps with this issue. There are apps that don’t supporthorizontal landscape like Tik Tok, Instagram, Snapchat and Duolingo. Other appslike Facebook, Netflix and Spotify support horizontal landscape but just partially(see figure 3.1 (A)(B)).

Fig. 3.2: Findings for screen orientation analysis.

3.2 Apps analysis 9

3.2.3 UI not depend on color

UI not depend on color means that the app’s color palette is appropriate for all typesof users.

Before starting the analysis, a little research was done to find the color blind typesbecause this could affect color blind people. According to the National Eye Insti-tute[12], there are 4 types of red-green color blindness: Deuteranomaly, protanomaly,protanopia, and deuteranopia. And there are too 2 types of blue-yellow colorblindness: Tritanomaly and tritanopia. Because there are many types, this paperfocused only on the most common types: protanopia (1%), deuteranopia (1%),protanomaly (1%) and deuteranomaly (5%)[13]. To simulate color blindness, weused the tool color blindness simulator on https://www.color-blindness.com/coblis-color-blindness-simulator/.

Only 2 apps had problems with colors. The first one was twitter as shown in figure3.3, that has contrast problems when protanopia is simulated.The another one wasUC Browser in night mode as is shown in figure 3.4.

Fig. 3.3: Twitter has a little color contrast with protanopia on its hashtags and mentions.The user can change the color on the web app but it only applies to the web app

itself.

10 Chapter 3 Proposed Approach

Fig. 3.4: UC Browser night mode has color contrast problems.

3.2.4 Multi-language support

Multi-language support means that the app’s capacity to support multiple languagesto be accessible by people around the world. .

To do this analysis we selected 5 languages that, according to Ethnologue[7], are themost spoken languages in the world. To analyze this feature, the global languagein the device was changed and then the app was opened to verify if it was able tochange the language. This was the feature with the most issues found, with 12 intotal.

Apps like Twitter, Facebook, Spotify, LinkedIn, the three Microsoft apps, and Duolingocould not translate all the UI elements. To correct this issue the user must have resetits phone or reinstall the app (see figure 3.5(A)(D)(E)(F)(G)(H)).

On the other hand, apps like Tik Tok and Snapchat supports multi-language but theusers needs to change the language from the app, changing the device languagedidn’t work (see figure 3.5(B)(C)).

3.2 Apps analysis 11

Finally, we had two special cases. The first one is Mercado Libre that only supportsthe Spanish language. The other case is Netflix that supports all the languages butthe user has to change his account language from the web app.

Fig. 3.5: Results from the multi-language analysis.

12 Chapter 3 Proposed Approach

The table 3.3 summarizes the analysis performed.

Tab. 3.3: Apps analysis summary (x indicates that the app has errors)

App Resize Text Screen Orientation UI not depend on color Multi-language supportTwitter x - x xYoutube - - - -

UC Browser x - x -Tik Tok x x - xSkype - - - -

Snapchat - x - xInstagram x x - -Whatsapp - - - -

Facebook Messenger - - - -Facebook - x - x

Netflix - x - xSpotify - x - x

Telegram x - - -LinkedIn - - - x

Microsoft PowerPoint x - - xMicrosoft Word x - - xMicrosoft Excel x - - x

Duolingo - x - xMercado Libre - - - x

Dropbox - - - -

3.3 Developing an accessible app

An app was developed to test the prototype. This app has two different versions, onewith accessibility issues and the other one without them. These apps were developedusing the codelab course about accessibility basics[8]. The app has the following8 different sections to explain which accessibility feature the developer can use foreach situation:

• Content labeling.

• Content grouping.

• Live region .

• Expand touch area.

• Insufficient contrast.

• Not depend on color.

• Content description redundancy.

• Localizing.

3.3 Developing an accessible app 13

The first 5 sections are described in the codelab course about accessibility basics[8],for that reason this paper will be focus on the last three sections.

3.3.1 Not depend on color

This section is about the app’s color palette. During the development of an app isimportant to choose the right color palette but the flows or actions must not dependonly on the color. This is because the potential users with color blindness.

Fig. 3.6: As you can see, if the red color means bad and green means good, a color-blindperson with deuteranopia or protanopia can’t distinguish well between both

options.

In this case, adding a text for both buttons can solve the problem, but this is only todemonstrate that it is necessary to choose an accurate color palette for all types ofusers.

3.3.2 Content description redundancy

Another aspect to consider is the content description redundancy. This happenswhen the developer put in the contentDescription the name of the element (e.g.,putinto a ImageButton’s contentdescription "play Button", the TalkBack[10] will read itlike "play button button").

It is not necessary to put on the contentDescription attribute the type of the elementbecause the TalkBack[10] already knows that.

14 Chapter 3 Proposed Approach

Fig. 3.7: Content Description Redundancy Screen.

3.3.3 Localizing

Localizing is important to make an app accessible in multiple languages. In this sec-tion, the button on the screen shows a toast with a message that changes dependingon the device’s language.

Fig. 3.8: How the localizing works for English and Spanish languages.

3.3 Developing an accessible app 15

As shown in figure 3.8, it is possible to implement localizing into an application.To do this, go to values/strings.xml, right-click the string.xml file, and look for theOpen Translations Editor option. Then, add the corresponding translation for eachstring and language as shown in figure 3.9.

Fig. 3.9: This is how the Translations Editor looks.

3.4 Tool prototype

3.4.1 Tool development

To make the tool, a class extending AccessibilityService[4] was created. The follow-ing code example shows how is the structure of the class that extends Accessibility-Service:

Code example 3.1: Java code extending AccessibilityService

1 public class AccessibilityToolService extends AccessibilityService {2 @Override3 public void onAccessibilityEvent(AccessibilityEvent event) {4 //Your code here, using the event5 }6

7 @Override8 public void onInterrupt() {9

10 }11 }

The tool has another class named A11yNodeInfo, part of the open source project (fig-ure 3.10) Android Accessibility Utilities from the github user chriscm2006 (https://github.com/chriscm2006). In this class, there is a method named toViewHeirar-chy(), that analyzes 4 elements (Button. ImageButton, ImageView, and Checkbox)looking for content description and touch area issues. The content descriptionissues are related to the elements that don’t have values on the attributes text orcontentDescription; on the other hand, touch area issues apply to the elements thatits size is less than 48dp 5 48dp according to Google[5].

The method onAccessibilityEvent(AccessibilityEvent event) receives an Accessibili-tyEvent and invokes the method toViewHeirarchy() (the method returns a Stringwhile the app is being used with all the results of the report.) from the otherclass. There are many types of AccessibilityEvent[3], the tool is focused on theAccessibilityEvent.TYPE_VIEW_CLICKED.

16 Chapter 3 Proposed Approach

Fig. 3.10: In a question from Stackoverflow, the user chriscm2006 expressed that hisrepository is an open source library

(https://stackoverflow.com/questions/45423728/android-onaccessibilityevent-get-x-and-y-position-of-textview)

Finally, there is a method on the principal class named writeInFile(String append)that receives the String that was generated before, and writes an HTML file on thepath /Internal shared storage/Android/data/com.example.accessibilitytool/files.

Fig. 3.11: These are the two buttons at the top of the screen.

The tool consists of two buttons on top of the screen (see figure 3.11), one to startscanning the actions and the other one to stop the process and save the HTML file.

The HTML file has the following structure:

3.4 Tool prototype 17

Code example 3.2: HTML report structure

1 ACCESSIBILITY REPORT2 Accessibility Event Detected3 -------------------------------------------------------------------4

5 Element: //type of the element.6

7 Text: //text of the element. null if does not have.8

9 Content Description: //contentDescription of the element. null if does not have.10

11 Width: //width of the element in dp.12

13 Height: //height of the element in dp.14

15 -------------------------------------------------------------------16 Elements with contentDescription issues: //number of elements with contentDescription

issues.17

18 Elements with touchArea issues: //number of elements with touchArea issues.

3.4.2 Testing the tool

To test the prototype, the app described in Developing Accessible App was used,specifically the elements from CONTENT LABELING SCREEN (figure 3.12), andEXPAND TOUCH AREA SCREEN (figure 3.13). The report was executed twice, onewith the version of the app that doesn’t have accessibility and the other one for theversion that is accessible.

18 Chapter 3 Proposed Approach

Fig. 3.12: Screen of the CONTENT LABELING SCREEN.

Fig. 3.13: On the left with a bad size. On the right side, the size is corrected.

3.4 Tool prototype 19

These are the steps used:

1. Activate the service in the list of "Downloaded services".

2. Open the app.

3. Tap the START button of the tool.

4. Navigate to the CONTENT LABELING SCREEN and then to the EXPAND TOUCHAREA SCREEN.

5. Tap the STOP button of the tool.

6. Look for the HTML report and check the results.

Comparing both reports, the results were correct as shown in figure 3.14 and figure3.15. The prototype was able to identify the issues in the app without accessibilityfeatures, and no errors were found in the app that is accessible.

Fig. 3.14: Comparison between the results for contentDescription issues. On the left arethe results for the app without accessibility features. On the right side the app

that is accessible.

20 Chapter 3 Proposed Approach

Fig. 3.15: Comparison between the results for touch area issues. On the left are the resultsfor the app without accessibility features. On the right side the app that is

accessible.

3.4 Tool prototype 21

4Conclusion

4.1 Findings

The project has some findings that could be useful to highlight:

• Even the most used apps have accessibility issues.

• There are some accessibility checks that no tool contemplates actually.

• There are not enough guides that explain how to make an app accessible.

• Use custom elements could difficult the work to make an app accessible.

• NodeInfo class provides enough information to make some accessibility checks.

• There are some people who cares about the mobile app’s accessibility.

4.2 Future work

The project has some interesting points of work in order to improve the quality andapproach of the results:

• Improve the report adding a screenshot of the current view.

• Make the service buttons moveable (they just sit on top of the screen for now).

• Integrate the Google Accessibility Test Framework to make other checks likecontrast color.

• Make the tool totally automated.

• Avoid duplicated screens.

23

Bibliography

[1] Adobe. What is accessibility? URL: https://www.adobe.com/accessibility/gettingstarted.html (On page 1).

[2] BBC. Mobile Accessibility Guidelines. URL: https://www.bbc.co.uk/guidelines/futuremedia/accessibility/mobile (On page 5).

[3] Google Android developers. Accessibility Event - Constants. URL: https://developer . android . com / reference / android / view / accessibility /AccessibilityEvent#constants_1 (On page 16).

[4] Google Android developers. Accessibility Service. URL: https://developer.android.com/reference/android/accessibilityservice/AccessibilityService(On page 16).

[5] Google Android developers. Make apps more accessible - Use large, simplecontrols. URL: https : / / developer . android . com / guide / topics / ui /accessibility/apps#large-controls (On page 16).

[6] M. M. Eler, J. M. Rojas, Y. Ge, and G. Fraser. “Automated Accessibility Testingof Mobile Apps”. In: 2018 IEEE 11th International Conference on SoftwareTesting, Verification and Validation (ICST). 2018, pp. 116–126 (On page 4).

[7] Ethnologue. What are the top 200 most spoken languages? URL: https://www.ethnologue.com/guides/ethnologue200 (On page 11).

[8] Google. Basic Android Accessibility: making sure everyone can use what you cre-ate! URL: https://codelabs.developers.google.com/codelabs/basic-android-accessibility/#0 (On pages 13, 14).

[9] Google. Espresso. URL: https : / / developer . android . com / training /testing/espresso (On page 3).

[10] Google. Get started on Android with TalkBack. URL: https://support.google.com/accessibility/android/answer/6283677?hl=en (On page 14).

[11] Google. Get started with Accessibility Scanner. URL: https://support.google.com/accessibility/android/answer/6376570?hl=en (On pages 1, 3).

25

[12] National Eye Institute. Types of Color Blindness. URL: https://www.nei.nih.gov/learn-about-eye-health/eye-conditions-and-diseases/color-blindness/types-color-blindness (On page 10).

[13] Iristech. Statistics and how many people are Color blind. URL: https : / /iristech.co/statistics/ (On page 10).

[14] NDTV. These Were The 10 Most-Downloaded Apps Of The Decade. URL: https://www.ndtv.com/offbeat/these-were-the-10-most-downloaded-apps-of-the-decade-2150290 (On page 6).

[15] Ranorex. Why test automation. URL: https://www.ranorex.com/why-test-automation (On page 1).

[16] Statista. Which is the most important device you use to connect to the internet, athome or elsewhere? URL: https://www.statista.com/statistics/387447/consumer-electronic-devices-by-internet-access-in-the-uk/ (Onpage 1).

[17] C. Vendome, D. Solano, S. Liñán, and M. Linares-Vásquez. “Can Everyoneuse my app? An Empirical Study on Accessibility in Android Apps”. In: 2019IEEE International Conference on Software Maintenance and Evolution (ICSME).2019, pp. 41–52 (On page 3).

[18] W3C. Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI GuidelinesApply to Mobile. URL: https://w3c.github.io/Mobile-A11y-TF-Note/(On page 5).

26 Bibliography

List of Figures

3.1 Findings for resize text analysis. . . . . . . . . . . . . . . . . . . . . . . 83.2 Findings for screen orientation analysis. . . . . . . . . . . . . . . . . . 93.3 Twitter has a little color contrast with protanopia on its hashtags and

mentions. The user can change the color on the web app but it onlyapplies to the web app itself. . . . . . . . . . . . . . . . . . . . . . . . . 10

3.4 UC Browser night mode has color contrast problems. . . . . . . . . . . 113.5 Results from the multi-language analysis. . . . . . . . . . . . . . . . . . 123.6 As you can see, if the red color means bad and green means good, a

color-blind person with deuteranopia or protanopia can’t distinguishwell between both options. . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.7 Content Description Redundancy Screen. . . . . . . . . . . . . . . . . . 153.8 How the localizing works for English and Spanish languages. . . . . . 153.9 This is how the Translations Editor looks. . . . . . . . . . . . . . . . . . 163.10 In a question from Stackoverflow, the user chriscm2006 expressed that

his repository is an open source library (https://stackoverflow.com/questions/45423728/android-onaccessibilityevent-get-x-and-y-position-of-textview) 17

3.11 These are the two buttons at the top of the screen. . . . . . . . . . . . 173.12 Screen of the CONTENT LABELING SCREEN. . . . . . . . . . . . . . . 193.13 On the left with a bad size. On the right side, the size is corrected. . . . 193.14 Comparison between the results for contentDescription issues. On the

left are the results for the app without accessibility features. On theright side the app that is accessible. . . . . . . . . . . . . . . . . . . . . 20

3.15 Comparison between the results for touch area issues. On the left arethe results for the app without accessibility features. On the right sidethe app that is accessible. . . . . . . . . . . . . . . . . . . . . . . . . . 21

27

List of Tables

3.1 Comparison between the previous tools . . . . . . . . . . . . . . . . . . 63.2 Apps selected for the analysis . . . . . . . . . . . . . . . . . . . . . . . 73.3 Apps analysis summary (x indicates that the app has errors) . . . . . . 13

28