Skip to content
This repository was archived by the owner on Feb 21, 2023. It is now read-only.

Commit 94e5954

Browse files
committed
Closes #68: Add accessibility guide.
This information was compiled from the Oct. 25 2018 Android weekly team meeting.
1 parent aaaa357 commit 94e5954

File tree

3 files changed

+34
-0
lines changed

3 files changed

+34
-0
lines changed

android/CONTRIBUTING_code.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -18,6 +18,7 @@ Contents:
1818
Unfamiliar with the technology we use? No problem! We were once new to this
1919
too! Here are few guides we've compiled to help you get started:
2020
- [Android guide](android_guide.md)
21+
- [Accessibility guide](accessibility_guide.md)
2122
- [Kotlin guide](kotlin_guide.md)
2223

2324
If these are confusing or if you have questions, please let us know!

android/accessibility_guide.md

Lines changed: 32 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,32 @@
1+
# Android Accessibility Guide
2+
Accessibility (or "a11y") is about making apps usable by everyone. Android developers need to pay particular attention to users with visual impairment, auditory impairment, and restricted motor skills. This guide is intended to get you started with making your Android app more accessible.
3+
4+
To identify how well the accessibility of your app is working, try it as a user! For example, try closing your eyes while using the TalkBack screen reader. You can also use [the Accessibility Scanner][scanner] for an automated analysis.
5+
6+
If you have questions, please ask!
7+
8+
## Introductory resources
9+
The [official Android accessibility overview](https://developer.android.com/guide/topics/ui/accessibility/apps) is a great overview to common issues users may face and how you should address them as an Android developer. A good supplement, for visual impairment, is [this official Android Developers video](https://www.youtube.com/watch?v=1by5J7c5Vz4). This [presentation on accessibility](https://www.youtube.com/watch?v=UOr3mgqJU0A&feature=youtu.be&list=PLnVy79PaFHMUqqvwbjyKJZv1N8rzHOCBi) and [this podcast](https://androidbackstage.blogspot.com/2014/10/episode-14-accessibility.html) are also recommended by our developers.
10+
11+
Some general tips:
12+
- Look through the accessibility preferences in the Developer Options: there are many features, such as visual simulations, to help you.
13+
- If it is impossible to provide an intuitive, accessible user experience for your current UI, this is a design smell: a UI that is accessible tends to be the best experience for all users.
14+
- For example, a dialog with one option, like "Remove", that is dismissed by clicking outside the dialog, will be unintuitive to screen reader users. However, this dialog may be unintuitive to users who are unfamiliar with common software paradigms (i.e. tap outside to dismiss) too. A better dialog would be one with a "dismiss" option in addition to "remove"
15+
- Avoid creating separate code paths and user experiences to address accessibility issues: in our experience, accessibility is not often tested so it's easy to break the experience if you forget to update one code path
16+
17+
## Screen reader tips
18+
**TalkBack** is the default Android system screen reader: it's usually installed by default but you may need to install it from the Play Store. When testing, don't forget your headphones!
19+
20+
**VoiceView** is the default system screen reader on Amazon products: it is installed by default.
21+
22+
Some development tips:
23+
- Don't try to override TalkBack's behavior outside of what is suggested in the docs: users expect the system to work consistently so overriding that behavior can be unintuitive.
24+
- Generally let the system handle focus changes: it's unintuitive when it jumps around.
25+
- Overriding the accessibility APIs in code is a code smell: generally, you can make the changes you need using the methods recommended in the docs, which provides a more maintainable and intuitive experience to users. Also note the code APIs are unintuitive and not well documented.
26+
27+
## Automated testing
28+
You can regularly use [the Accessibility Scanner][scanner] to get a cursory overview of how the accessibility of your app is doing.
29+
30+
Unfortunately, we don't have much automated testing experience outside of this. However, this [official documentation](https://developer.android.com/training/accessibility/testing#automated) seems like a good starting point. If you find out more, please share with the team and consider updating this doc!
31+
32+
[scanner]: https://support.google.com/accessibility/android/answer/6376570?hl=en

android/android_guide.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -31,6 +31,7 @@ If you like staying up-to-date on the latest Android topics, members of our team
3131
## Intermediate topics
3232
Comfortable with the basics? Here are a few of our favorite resources to get started on intermediate topics.
3333
- [Android style tips](http://blog.danlew.net/2014/11/19/styles-on-android/) (circa 2014)
34+
- [Our Accessibility guide](accessibility_guide.md)
3435

3536
### Navigating the Android source code
3637
Oftentimes, it's easier to solve a problem when you understand how your code is interacting with the Android framework: you can do this by reading the Android source code! You can do plain-text searches on the Android source code at http://androidxref.com/ (choosing the latest API level and searching in the "frameworks" is usually sufficient).

0 commit comments

Comments
 (0)