Do you have to support landscape in your Android app?

Having trouble reading this? So are some of your users with disabilities.

If your app provides a public service in the US, ADA Title III law says YES. The required WCAG 2.1 level AA guidelines forbid locking orientation to portrait. Here’s what you need to know.

One historically problematic issue with development on Android is support for landscape orientation. Developers often loathe the extra work involved, or neglect it entirely. Now, that’s no longer a (lawful) option for some apps.

Android, at the platform level, was designed to put apps through what are called “configuration changes” in order to allow them to best adapt to specific changes in the device’s environment. The most common configuration change is an orientation change — switching from portrait to landscape and back. (It’s actually a lot more than just device orientation. You can see the whole list of possible configuration changes in the documentation.)

By my experience, correctly and efficiently supporting orientation changes can involve roughly 20–30% more development time and code related to Activities, Fragments, and Views, even for a straightforward, text-based app. And it gets more complicated when layouts cannot be reused as-is for each screen.

To ease this pain, many app developers simply opt out of it altogether, choosing to lock activities in portrait in the Android manifest like this:

<activity
    android:name=".MainActivity"
    android:screenOrientation="portrait"
    ...
    />

While this certainly does seem to make things easier, locking orientation to portrait is actually skirting the issue of accessible app design, not to mention introducing other problems as well. (Note that there are a few valid reasons to lock orientation, but ease of development is not one of them — more on that later.)

So, why do we have to do this?

A majority of people use their Android devices in portrait, because that’s the way a phone naturally fits in your hand. However, for people with disabilities, one-handed portrait use is not the norm.

In October 2019, the US Supreme Court decided that public services provided through web and mobile apps must be accessible to people with disabilities, according to the Americans with Disability Act (ADA) Title III. The standard for compliance is codified using the Web Content Accessibility Guidelines (WCAG) 2.1 with a level of conformance rated AA. While WCAG was initially designed for the web, it applies to any graphical user interface for general public use, such as apps and kiosks.

Usually, we think of WCAG in terms of fonts, colors, keyboard accessibility, and screen readers. It’s fairly straightforward to design and implement these requirements. But there is one requirement for screen orientation in success criterion 1.3.4:

Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential.

You can read in more detail about this requirement. In particular:

The goal of this Success Criterion is that authors should never restrict content’s orientation, thus ensuring that it always match the device display orientation.

The criterion comes with a note suggesting that this isn’t a hard and fast rule:

Examples where a particular display orientation may be essential are a bank check, a piano application, slides for a projector or television, or virtual reality content where binary display orientation is not applicable.

So, if there is something special about some screen in your app that absolutely requires a locked orientation, that’s exempt. But as a general rule, locking an app in any orientation is effectively discriminating against some set of people who could be interested in using your app.

Developing apps requires developing empathy

If this requirement for flexible orientation makes you uncomfortable from a design and engineering perspective, that’s understandable. However, if your app isn’t providing a public service in the US, there are other reasons to care about accessibility. It helps to see some specific examples, so you can better understand where your users are coming from. Here are three ways that landscape orientation is essential for people with disabilities.

Tablet mounts for wheelchair users

Tablets are commonly mounted to wheelchairs for use by disabled persons. These mounts do not all switch between landscape and portrait in order to mount firmly, or they require outside help to remount. Apps locked to portrait are essentially inaccessible in this situation.

Click here to do an image search for wheelchair tablet mount to see lots of examples. Notice that they are mostly mounted in landscape.

On-screen keyboards are easier in landscape

Given the extra horizontal screen real estate, on-screen keyboards are much easier to use for people with motor control impairments. The difference in the size of the touchable area of each key is obvious on this 7” tablet:

Keyboard buttons are larger and easier to use in landscape

The keys in landscape are nearly twice as wide, meaning they require less manual dexterity to operate. The larger keyboard buttons are crucial for people with disabilities such as cerebral palsy, multiple sclerosis, essential tremor, and Parkinson’s disease. Your users might also simply prefer landscape for typing on smaller devices (I know I do sometimes).

Easier reading

Depending on the user’s font size preference, reading might be easier in landscape. There is an ideal line length for content (50–75 characters per line), and landscape orientation can provide that option for your users. This is especially important for people with cognitive disabilities.

Which text is easier to read at this font size? Research suggests landscape in this case.

Supporting orientation changes on Android

Hopefully, you’ve decided that supporting landscape (and switching between portrait and landscape) is a good idea. There is a wealth of information out there on the topic, so I won’t bother repeating the whole discussion. The good news is that it’s gotten a lot easier lately. Here are a few resources to look into:

Core Android support: To create responsive UIs based on the size and orientation of the screen, the core Android platform offers ways for app developers to easily indicate which layout and other resources should be used with various configurations. It’s critical to understand the various qualifiers for Android resources that make this possible.

ViewModel (part of Android Jetpack architecture components) makes it much easier and less prone to activity leaks when retaining data and ongoing work across configuration changes. When ViewModel is used correctly, the user should be able to pick up exactly where they left off when a configuration change occurs.

The Activity Result API makes it easy to handle the results of activities. For fragments, it was particularly painful to get the result of a launched activity when configuration change was involved. This API makes that specific task considerably easier. This API was first introducded in AndroidX Activity 1.2.0-alpha-02 and Fragment 1.3.0-alpha02

Material design components: Going deeper into handing varying configurations from a UI perspective, material design offers components such as bottom app bar, navigation drawer, and rail to tailor your app’s UI to the dimensions of the screen. Effective use requires significant design effort, but the result is an app that’s WCAG compliant, and a pleasure to use for as many people as possible.

Image from Android documentation

While supporting landscape is definitely requires more work during design and implementation, the result is that more people are able to use your app. Given that 1 in 5 people in the US have some sort of disability, this is an important segment of the population to consider.