Eevis
Posted on August 7, 2024
I'm studying for my second master's degree (for fun) and finished with my thesis in the spring. As part of my thesis, I developed an accessibility checklist for Android developers. While completing all the checks doesn't guarantee that your app is 100% accessible, the checklist aims to help catch many possible accessibility problems.
In this blog post, I'll first share a bit about the development process and then share the checklist. If you're curious, the whole checklist with accompanying material is behind the following link: Android Accessibility Checklist.
Background
As mentioned, developing the checklist was part of my Master's thesis, which has been published, and you can find it from the following link: Towards More Accessible Android Applications: An Actionable Accessibility Checklist for Android Developers.
I conducted the research with the help of Design Science Research (DSR). I collected material for the initial checklist from prior research and available Android accessibility guidelines, evaluated it with five interviews with Android developers, and then constructed an improved checklist. Then, I created the website with the improved checklist and collected feedback and material for the last analysis with a Google Form. I analyzed the answers from both interviews and the questionnaire with the help of content analysis. The result of the research is the Android Accessibility Checklist, or as DSR calls it, an artifact.
The checklist itself consists of two sections. The first contains the checks that every Android developer should do, and the findings should be fixable by the developer. The second section includes checks that might not be fixable by the developer alone and might either require help from other functions or be a huge change. I'll explain the reasoning for some of these checks later in the blog post.
Now that the work with the thesis is over, and I don't need to think about the thesis' scope anymore, I will update the page and the checklist occasionally. I already have some things in mind from both learning and checking perspectives. Also, if you want to contribute, the checklist website's front page has a link to a form, which you can answer.
Before sharing the checklist, I'll say a few words about two checks/categories I had to make hard decisions about and the reasoning behind the decisions.
Some Thoughts on Text Alternatives and Screen Orientation
The first check I'm going to discuss is related to visual elements and text alternatives. Why is there no check for visual elements having a text alternative? The reason for this is that quite often the actual copy of the text alternative (or content description) is not within the developer's control. They might not know the intended purpose of the visual, or there might be a copywriter responsible for all the texts in the app. That's why I've included the check for text alternatives in the "Checks that might be out of your control"-section and not the actual checklist.
The other category I'm discussing is the orientation. I had to think about it a lot. Should I include a check to ensure the orientation is not locked? I wanted to, but I had to keep in mind the fact that the checklist aims to be as easy as possible to integrate, and most Android apps don't support both portrait and landscape modes. So, I decided not to include that check but rather have it in the "Checks that might be out of your control"-section.
The Checklist
Alright, let's get to the checklist! It's also available in the Checks-section of Android Accessibility Checklist.
Automated Tools
- Ran Accessibility Scanner for the feature
Images and Other Visual Elements
- Purely decorative images have content description set to null
Alternative ways of navigation
- The feature works with keyboard and D-pad
- The feature works with Switch Access
- The feature works with Voice control
- The feature works with a screen reader
- Focus order matches visual representation
- Added accessibility actions for gesture based actions (e.g. swipe or drag and drop), or there is another way to interact than the gestures (e.g. buttons)
Orientation
- Experience is similar for landscape and portrait modes
Semantics and Structure
- Semantics (e.g. headings) are identified
- Form elements (such as text fields, radio inputs and switches) have a text label
- Custom components have correct semantics, state information and interaction patterns
Magnification
- The feature works when using magnification
- Read instructions for testing magnification
- The feature works with font size set to the biggest size
Checks That Might be Out of Your Control (But Worth Checking!)
Images and Other Visual Elements
- Every visual element that conveys meaning has a descriptive text alternative
Use of Color
- The app/feature works even if user can't see colors
Orientation
- Orientation is not locked to either mode
Audio and Video
- Audio and video clips have captions
Wrapping Up
In this blog post, I've introduced an Android Accessibility Checklist I developed when writing my Master's thesis. The checklist and learning materials are available on the Android Accessibility Checklist site, which also contains a link to a survey if you want to help with further research.
What's your relationship with accessibility? Do you consider it when developing?
Top Level Links in the Blog Post
Posted on August 7, 2024
Join Our Newsletter. No Spam, Only the good stuff.
Sign up to receive the latest update from our blog.
Related
