Skip to the content.
This is the Winter 23 final website.

as3: Accessibility

Last revised: Tuesday 24 Jan, 2023
Assigned:
  • Wed 25-Jan
Due:
  • Code and report/reflection Thur 2-Feb, 10:00pm

HCI Goals:

  • Update an application with app accessibility as a focus
  • Experiment and evaluate the impact of different accessibility issues
  • Create a thorough report describing accessibility issues within the application and general concerns

Android Goals:

  • Gain exposure with reading, understanding, and modifying existing repository code for an application
  • Explore several different Android assistive tools
  • Develop a solution or alternative approach to address accessibility issues in the codebase
  • Use value `xml` files to refactor dimensions, colors, and strings

Turn-in links

Assignment Description

This assignment involves finding, fixing, and documenting all the accessibility problems in the code base for a modified version of the app AskForHelp (available on the Android play store, modified with permission). You will use a number of tools to find accessibility issues with the App, including but not limited to the Google Accessibility Scanner and TalkBack. It will be important for you to experience the app through the use of a screen reader to find all of the problems a user might encounter. You should fix problems that users with a variety of disabilities might encounter (i.e. your app should be usable by someone with low vision, difficulty with motor control, or blindness).

This assignment is very different from other assignments in this class, because it will depend primarily on you using your judgement. You will have to explore your own ideas for how to make this app accessible and implement them using any approach you believe works. Ultimately, you will need to be able to justify your decisions based on what you’ve learned in class: Would a reasonable person think that you have made the app accessible based on the screen/audio recording that you make?

Another reason this assignment is different is because you will need to read and understand someone else’s code to make the changes you want to make. The decisions they made will influence how you are able to solve accessibility problems, and you will need to think about where to modify their code. You do not need to write any new methods to solve the accessibility problems, or remove or add elements to the interface. You also don’t need to add any new event handlers - code that will allow the app to respond to user input.

You will, however, need to modify things like the content descriptions of on screen elements, whether they are focusable, and so on, and announce changes to the screen that are visible but not to a screen reader.

Tasks

Accessibility is an important part of any app. Whether you are developing a new app or adding features to an existing one, it is important to consider the accessibility of your app’s components.

In this assignment you will:

Your tasks are as follows:

  1. Do the background readings required for class
  2. Set up your phone with the accessibility tools and the AskForHelp app.
  3. Read and understand the starter code base, including the class hierarchy as well as the interactor hierarchies.
  4. Ensure it is possible for anyone to complete the following four tasks using AskForHelp.
    • Go to settings from the home screen and turn on location
    • Add a request
    • Choose a request, choose a contact, and initiate a send of the request (they don’t actually have to press send on the request)
    • Delete a request
  5. Make a video of yourself, a friend, or family member completing all required tasks, in order, using the screen reader, without looking at the screen.
    • Note: if we are in person we may ask that you record someone else using your app without looking at the screen, as long as it can be done safely. One way to have someone else test your app remotely via Zoom or other platforms is to send them the apps .apk file, then have them load it onto a device using Android Studio.
  6. Document the problems you fixed in your report/reflection.

1. Background Readings

Read (or watch) the following (required) if you did not before our lectures. You will need these for background information:

Additionally the following will help you understand how to make your apps more accessible.

Optional readings that may also help you with the code or the report:

2. Setup your phone and the app

Check your emulator

Ensure that your emulator have access to the Google Play Store. Emulators such as Pixel 2 allow you to install the Play Store using the Tools->Device Manager. The best way to determine if the emulator has the Play Store is to look for the text under the name of the device in the Device Manager.

:img Screenshot of the AVD Manager with an emulator that has the play store and one that does not, width, 300px

To create another emulator, press the Create Virtual Device button, then find an emulator that has the Play Store icon in the Play Store column. Click Next and follow the instructions for the rest of the installation.

:img Creating a new device with the play store using the AVD Manager, width, 100%

Note that you will have to specifically choose this new emulator (as opposed to the one you were using before) when you are running your application on the emulator through Android Studio.

Installing Assistive Technologies for testing

It will be necessary to test the user interface with TalkBack, Android’s built in screen reader, to find all of the problems. TalkBack is part of the Android Accessibility Suite and Android support provides a tutorial on how to install and use it. Another assistive tool in this suite is Switch Access, which you may choose to explore.

To install the Android Accessibility Suite, search for it in the Play Store on your device or emulator and install it. The installation process will be the same for a physical phone or the emulator equipped with the Play Store.

Finally, install the Accessibility Scanner. Follow the instructions on the Getting started with Google Accessibility Scanner page to get the scanner working on your device.

The Accessibility Scanner will show you information about some (but not all) accessibility problems. Below we show an example of what it finds on the About screen for AskForHelp.

Accessibility Scanner Scanner Screenshot Focus on Problem item
:img Screenshot of the main screen of the Accessibility Scanner showing two items that are not fully accessible, 20%, width :img Screenshot of the About screen of AskForHelp showing two items that are not fully accessible highlighted in red, 20%, width :img Accessibility Scanner after one of the problems is selected mentioning target size and contrast, 20%, width
     

Install the Accessibility assignment code and try using it

Note: The first time you run the application (which we will refer to as AskForHelp) it will ask for permission to access your contacts and to access this device’s location. Please allow the app to do both of these things — you will not be able to test the app fully if you do not.

AskForHelp will show a tutorial when you run it. The goal of this application is to let people who have certain types of fatigue related disabilities to send text messages quickly and easily when they fall or become weak.

In order to work, the user has to preset some important messages (called Requests in the app) and one or more groups of contacts to whom messages will be sent. If the user turns on the Send location toggle in the AskForHelp settings, their GPS location will be included with the message.

Message requests and contacts are set up in AskForHelp through the Settings page. Setting up contact groups are a two step process - first the user gives the contact group a name, then they select which contacts to message from a contact manager in Android. You must make the screen where you set the contact group names accessible, but you do not need to make the contact picker accessible as we are using a 3rd party library for this functionality.

Note: In order to get the app to work correctly you must have at least one contact listed with a mobile number set up in your Android Contacts application. Thus you will need to create a contact or two if you are running on the emulator OR a physical mobile device.

Once the user has set up the requests and the contacts, they can set up a message with two clicks after opening the app. AskForHelp will open up your preferred text messaging app and pre-populate the message (along with location if that is turned on). To actually send the message the user would only need to press send in the messaging app.

To prepare your application you must add at least one request and at least one contact to it before your testing.

Note: These values are stored in the SharedPreferences used for this application. You may want to review the slides and/or documentation related to this interface. Your interaction with SharedPreferences will likely be minimal; nevertheless, you can examine or clear SharedPreferences from Device Explorer where you can navigate to data -> data -> cse340.askforhelp -> shared_prefs -> cse340.askforhelp.PREFERENCES.xml.

3. Read the starter code

As with our other assignments, it’s vital that you start by understanding the inheritance hierarchy for the application. The following diagram contains all of the classes you will need to explore, but does not list all of the methods for each class.

classDiagram AbstractAFHActivity <|-- ChooseRequestsActivity AbstractAFHActivity <|-- ChooseContactGroupsActivity AbstractAFHActivity <|-- EditRequestsActivity AbstractAFHActivity <|-- EditContactGroupsActivity AbstractAFHActivity <|-- SettingsActivity AbstractAFHActivity <|-- InfoActivity AbstractAFHActivity <|-- ApacheLicenseActivity TableLayout <|-- EditableList class AbstractAFHActivity { #getPrefs() #switchActivity() }

Unlike our previous assignments, there is no tab bar at the bottom of the screen. Instead there are buttons (such as the Home or Settings button) that will respond to an event (in this case an action the user takes) by setting up a click listener (by calling View#setOnClickListener(). If the user performs some action (such as clicking on a Button), the toolkit will “call back” into our code to perform some action (in this case, switching the activity). We will learn more about events and how to handle them in our next unit.

Make sure you read the documentation for each method, which will give you a clue as to what that method does. You can also find all of the occurrences of a method call by using Edit->Find In Files.

EditableList

The EditRequestsActivity and EditContactGroupsActivity both use a custom view called an EditableList, which shows a list of contacts/requests with a Delete button next to each item. You will need to modify this class in order to make both screens more accessible.

The EditableList is customized for each Activity by setting the mTypeOfItem String to a word describing the type of item in the list (“Request” or “Contact”). You may find this String useful in content descriptions or announcements!

4. Make AskforHelp accessible

Now that you are set up and you have explored the code, you will make the following tasks accessible for anyone. Note that we are assuming you have already set up at least one contact in your phone. (We are not including this in the list of tasks because it requires interacting with a different app to select the contact. You can use a fake contact name and number like 206-555-1212.)

For example, it should be possible for someone with low vision or for someone using a screen reader who is swiping from interactor to interactor (rather than directly clicking on them) to complete these tasks using your accessible version of AskforHelp.

You should start by trying each of these tasks without any changes to the app. Then you should turn on the screen reader and try the same tasks while using the screen reader. Finally, run the Accessibility Scanner on each of the screens. (Hint: you may have to re-run through this process a few times to catch everything. Once you fix one thing, it may uncover other issues.)

You will need to use a combination of XML modifications and modifications to the source code to make AskforHelp accessible. You will need to document your changes in your report, so it would be wise to create your report/reflection document early to track these changes. You could also track changes easily if you remember to commit and push your work frequently to your Gitlab repository.

XML modifications

When making repairs certain resources should be stored in the XML files. You must modify or add entries within these files before referencing them elsewhere in the code. Stylistic rules to keep in mind:

Recall that you can reference values in any of these by specifying @<filename>/<valuename>.

You may ignore any “Missing ‘contentDescription’ attribute” warnings in your xml files if you will be adding a content description to those elements programmatically.

You may note another resource file we have not yet discussed: styles.xml. Android Styles and Themes are a good way to refactor common appearances. A style is a collection of attributes, such as color, dimensions, etc, that can be used to change the appearance of Views. Styles can be reused to provide common appearances to multiple elements. For instance, the Settings ImageButton in activity_choose_requests.xml has an attribute style="@style/icon" instead of the three attributes listed in the style named "icon" in styles.xml`:

    <style name="icon">
        <item name="android:layout_width">@dimen/buttonHeight</item>
        <item name="android:layout_height">@dimen/buttonHeight</item>
        <item name="android:tint">@color/iconTint</item>
    </style>

This style is used in other XML files as well — this is a good opportunity to try Edit->Find In Files to see where is this style is used.

String formatting

Sometimes you will want to reuse a string that allows for substituting part of it, similar to String#format(String, Object ...) in Java. Conveniently, the Resources#getString() method is overloaded: one version of the method takes only one parameter (which we’ve seen frequently), and the other addition parameters (after the resource ID) which will substitute them for special patterns within the string that is specified by the resource ID. More information can be found within the Android documentation for getString().

Note: For the convenience of graders, please put new <string ...>...</string> entries at the bottom of strings.xml.

Important: You may change the wording in an entry in strings.xml, values in dimens.xml, or colors in colors.xml but you must not remove any entries from the original files. However, you may add additional entries in these or the styles.xml file.

Source code modifications

We have heavily scaffolded this assignment by adding TODOs in the code where our solution may require code changes. For instance, at some point a user may choose to delete a request or contact. Without visual feedback, it may be unclear that anything has changed by selecting this button. There is a TODO marked in a place where you could announce this change.

5. Make a video

Make a video of yourself completing all four tasks, in order, using the screen reader. You may also ask a friend or family member to do these tasks (while you record) as long you have their permission to record them for this assignment.

Whether it is you or another person demonstrating the accessibility of this app, the following must be true in the video you submit:

When doing these tasks on either device phone, you should demonstrate navigation order by moving from item to item and listening to the screen reader, rather than using your eyes or knowledge of the location of that item on screen to complete a task.

An example video of a user demonstrating the use of the Layout App with a screen reader is below. While this video demonstrates both methods for demonstrating the accessibility of an app, you only need to do one: either using the emulator or a physical phone. Remember:

Remember: before you begin recording you will need to have a valid contact with a phone number in your phone, and you will have to set up a contact on the Set Contacts And Numbers screen.

The tasks required to be demonstrated in the video are:

  1. Go to settings from the home screen and turn on location
  2. Add a request on the Set Requests Texts screen
  3. Go back to the home screen
  4. Choose a request, choose a contact, and reach the sending message screen (do not have to actually send a message)
  5. Navigate back to Set Requests Texts screen and delete a request

You can achieve the recording in many ways, however the easiest may be to start a Zoom meeting and press the record button, then hold up the physical phone to show how it is being tested. Record the session to your computer which will result in a .mp4 when you exit the Zoom meeting. See below for instructions on how to turn in the .mp4 file.

6. Write your report/reflection.

Your report/reflection for this assignment will be sumitted to Gradescope. We recommend you create a MS Word, Google or other type of document and copy the following questions (in italics below) into that document before you even start coding. Add your responses below each question. You can have more than one answer per page, but if you can, please try to avoid page breaks in the middle of a question. Insert page breaks between questions as needed.

  1. Pick two descriptions you added for distinct UI elements or actions in your AskForHelp app (either alt text or text announcements). Explain why these descriptions follow the WebAim Alt text guidelines.
  2. Give an example of a problem in the AskForHelp that was not solved simply by writing good alt text. Tell us:
    • How you identified that problem.
    • How you fixed the problem.
    • Whether Android’s accessibility tool(s) were helpful in identifying or fixing it (including which tool helped, if any).
  3. You used the screen reader to help you identify problems in the AskForHelp app. However, the AskForHelp app also requires a user to interact with standard android apps (contacts and messaging). Detail the accessibility issues you found in the portions of these apps needed to fully use AskForHelp.
  4. We presented a list of Best Practices for Mobile App Developers in our Security lecture. a. List each of these practices and categorize them as (1) violated, (2) met, or (3) not relevant in the AskForHelp app. Defend your reasoning. b. Overall, how secure do you feel the AskForHelp app is? What security and/or privacy issues could arise with this app?
  5. The AskForHelp codebase was more complicated than our first two assignments and included concepts we had not yet covered in class at the time of its release.
    • How did you initially approach learning how the code is organized and what parts of the code needed to change to make this app more accessible? What parts of the code did you need clarification on or help in understanding? What did you learn in approaching this app’s development that will help you in the future?
    • What are some of the techniques the developer(s) used to make the codebase easier to understand?
    • What is one thing you would like to changed about this application codebase?
  6. Acknowledgements: Cite anything (website or other resource) or anyone that assisted you in creating your solution to this assignment. Remember to include all online resources (other than information learned in lecture or section and android documentation) such as Stack Overflow, other blogs, students in this class, or TAs and instructors who helped you during OH.

Turn-in

Submission Instructions

You will turn in your code via Accessibility Assignment on Gradescope assignment. The files you will need to include are:

- dimens.xml
- strings.xml
- colors.xml
- any other xml files you need to change to improve accessibility
- any .java files you need to change to improve accessibility

Grading (50pts)

The Accessibility assignment will be out of 50 points and will roughly (subject to small adjustments) be distributed as:

Grading of video (10 total):

Grading of code (21 total): (Some of these elements will be confirmed in the video.)

Grading of report/reflection (19 total):