You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Feb 21, 2023. It is now read-only.
Copy file name to clipboardExpand all lines: android/accessibility_guide.md
+38-1Lines changed: 38 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -42,6 +42,43 @@ This is both inefficient and confusing for the user, since they will encounter e
42
42
## Automated testing
43
43
You can regularly use [the Accessibility Scanner][scanner] to get a cursory overview of how the accessibility of your app is doing.
44
44
45
-
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!
45
+
When adding specialized accessibility logic, it is encouraged to add as much testing as possible since these code paths are not excercised in typical use and the chance of regression is high. Below is an example Mockito and Robolectric test that validates accessibility events that are resulted from a [loading progress update](https://github.com/mozilla-mobile/android-components/pull/2526).
46
+
47
+
```kotlin
48
+
@Test
49
+
fun`displayProgress will send accessibility events`() {
In addition the [official documentation](https://developer.android.com/training/accessibility/testing#automated) seems like a good starting point to learn more about accessibility validation in tests. We should look into integrating this into our CI.
0 commit comments