One of the best ways to learn is to jump right in and start applying your new knowledge. Throughout this book, you’ll be working on making an app more accessible. You’ll be able to apply the techniques you learn here right away, whether you’re working on an existing app or building a new one outside of this book. You don’t even need to finish the book to start applying the new information from each chapter in your projects!
You’ll soon see that you already have the tools to get started and that it takes only a couple of lines of code to make a big difference for your users.
Introducing Taco Tuesday
Taco Tuesday is the name of the app you’ll develop as you work through this book. It allows you to discover and save new recipes to enjoy on your next Taco Tuesday. Once you’ve found a recipe you like, you can indicate that you made it, rate it and add notes.
Find the starter project in the materials for this chapter and open it in Android Studio. Build and run.
You’ll see that there are auto-advancing slides followed by recipe cards at the on-boarding stage. You can swipe the recipe cards to the right and left to save for later or pass them up, respectively, and move to the next recipe.
Tap Favorites to see the saved recipes. To see a details screen that shows all the ingredients and instructions for a certain recipe, tap the View icon on the recipe card. From here, you can add your rating and notes if you’ve saved the recipe.
Finally, you’ll see some pop-up dialogs and a bare-bones settings screen.
You may have noticed the app has several unpleasant features. The pop-ups are disruptive and the on-boarding process is unclear.
As you improve the app’s accessibility, you’ll also improve the overall user experience. When you complete this book, the app will look more like this:
So much nicer! Without further adieu, it’s time to dig in and start improving this app!
Improving accessibility through linters
Do you feel lucky? Well, you are! Not only do you have this book in your hands, but you probably use one of the tools that can make your app more accessible: lint. Android linters include a category that’s all about supporting accessibility.
Seeing lint errors
You have some options for how to view lint errors. The first way is to use Gradle in the command line. Run this command if you’re on Linux or Mac:
Understanding content descriptions
contentDescription warning is one of the accessibility components. But what does it mean?
Adding content descriptions
Open fragment_discover.xml. The first element you’ll fix is the topmost
ImageView with the
contentDescription warning that has the ÍD
discover_button_discard. This is the thumbs-down button on the first screen that you tap to pass on a recipe.
Adding more content descriptions
You’re a pro at this now! See if you can work through the following content descriptions with minimal instruction. If you get stuck, check the solution in the final project for this chapter.
Programmatically adding content descriptions
Sorry to inform you, but there’s one issue with your changes to
recipe_detail_try_discard_button. Depending on whether you’ve saved the current recipe to try later or not, this view toggles between “Try it” and “Dismiss” in its behavior. This means you also need to toggle the content description. Next, you’ll implement a bit of Kotlin code to fix this issue.
recipeDetailTryDiscardButton.contentDescription = getString(R.string.shared_discard)
recipeDetailTryDiscardButton.contentDescription = getString(R.string.shared_try_it)
When you design for accessibility, you need to think about two types of content:
Handling decorative views
Go to fragment_recipe_detail.xml and find a view with the ID
recipe_detail_divider. As the name suggests, this view is a thin line that acts as a divider between sections. What should the user know about this?
<View android:id="@+id/recipe_detail_divider" android:layout_width="match_parent" android:layout_height="1dp" android:background="?colorControlHighlight" />
Fixing keyboard inaccessible widgets
When you run the linter, you’ll see KeyboardInaccessibleWidget amongst the warnings. Find and click it to go to the detailed list of files.
This book teaches you the best practices for and conforms to the Web Content Accessibility Guidelines (or WCAG) version 2.1 as the standard for accessibility. These guidelines are an industry standard.
Building a POUR app
WCAG uses a lovely little acronym to categorize the principles of the requirements:
Measuring using levels of compliance
WCAG provides levels of conformance for each of its guidelines, which include A, AA, and AAA, going from lowest to highest. Level A conformance means you’ll meet most people’s needs The industry best practice is to meet at least A or AA.
Choosing universal design
There are two predominant strategies for designing accessible apps: accessible design and universal design.
Challenge 1: Solve the ContentDescription warning
Remember, the last time you ran the linter there was one more
ContentDescription warning. Now’s the time to show your stuff by solving it!
- Android lint is a useful tool for identifying accessibility issues.
- One or two lines of code can often solve accessibility warnings.
- Content descriptions tell accessibility services what a given image is.
- To improve keyboard users’ experiences, add
android:focusable="true"to a view that you declare
- WCAG and the Android docs are excellent resources for understanding accessibility requirements.
- Choose universal design over accessible design so that everyone has the same experience in your app.
Where to go from here?
Congrats! You’re already making great improvements to the app. If you got stuck at any point, check out the final and challenge projects included in the chapter materials.