Android Accessibility Checklist

Eevis - Aug 7 - - Dev Community

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

Images and Other Visual Elements

  • Purely decorative images have content description set to null

Alternative ways of navigation

Orientation

  • Experience is similar for landscape and portrait modes

Semantics and Structure

Magnification

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

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .