Accessible Android Inputs with Material Design

Material Design for an input

Update – August 2016

I first wrote this post shortly after textinputlayout was introduced and there was a distinct lack of documentation. My original code example for setting the error was incorrect. Per Victor Tsaran:

There is no such attribute as android:setError. There is a method called setError in the View class that can set the error message dynamically. That method actually works with TalkBack.
Victor Tsaran

Do not include the android:seterror line shown below. Please see the official Android Documentation for TextInputLayout. I’m leaving this post live for archival purposes. It’s an example of trying to use new APIs with minimal documentation and learning via trial and error. Now we have official documentation.

Google has done an admirable job defining the Material Design style guide. They’ve also begun rolling out new APIs that make it much easier to implement the interaction designs within Android and HTML. However, there are still some gaps. This article looks at the popular Text Input for Android interaction. Please note: the code in this article is not fully documented and the best practice may change as the Google Accessibility team updates their documentation. Consider this a beta pattern and I will gladly update it as we learn better practices.

Breakdown of Design

Material Design specification for an input
The text input includes a label that moves up above the input when the user places focus in the input. If the user enters invalid data, the error message appears at the bottom of the input.

Basic Code

The basic code uses a new parent container <TextInputLayout> which contains the <EditText>. The EditText includes an android:hint for the visual label and android:setError for the subsequent error message. (note: android:hint is not the same as iOS accessibilityHint)

    android:seterror="Create a valid email address"

Making it Accessible

My current testing shows the hint is announced by TalkBack when the user first enters the input. However, the hint is ignored when the input contains a value. Also, the error message is not being announced by TalkBack when it appears. In the above image, TalkBack would announce “edit text 100 days of ice cream“. We need to assign a label to the input that will be announced along with the value.

To understand this suggested solution, I like to think about a much simpler coding pattern: the label/input relationship in HTML. It’s possible to wrap an input with a label.

  <input type="text">

Now, we could also add a placeholder to the input (android:hint) and apply a hidden label to the input by using aria-label on the label tag.

I’m not suggesting this as a best practice, but it’s possible and easy to see the relationship. The label’s now using an attribute to provide the text node to the input. The input has a placeholder attribute that provides a visual label, but is lost when the user adds value to the input.

<label aria-label="Name">
  <input type="text" placeholder="John Doe">

Going back to the Android pattern, we can define the TextInputLayout as the label for the EditText by using android:labelFor and provide a contentDescription. This is essentially defining a solid label for the input that will remain after the user adds a value to the input. The contentDescription has no visual impact, so the android:hint will continue to be your visual label.

      android:seterror="Create a valid email address"

We also need to trigger TalkBack to announce the error message when it appears. Fortunately, Android has adopted the ARIA live region pattern. We can place android:accessibilityLiveRegion="polite" on the TextInputLayout to trigger the announcement. Please note: I haven’t been able to trigger this to work yet. It may be that the live region belongs on the input or this could be a TalkBack bug.


The pattern for creating an accessible text input is fairly simple. I like how they’ve removed the label functionality from android:hint and treat it as just a placeholder value. The labelFor attribute is much stronger. The Google Accessibility team is working on improved documentation and I hope this post helps to understand the issue, but I point back to the Android documentation as the final resource. I’m not an Android developer, but I know enough to be dangerous.

Please leave your comments with suggestions for improvements.


There is a serious bug with wrapping an editText within a textInputLayout with Lollipop and KitKat. The android:hint is not appearing on load and the hints appear as a user places focus in one of the inputs. This is not necessarily affecting TalkBack accessibility, but certainly affects the visual experience.

Author: Ted

Accessibility is more than making sure images have alternate text. I work with engineers, product managers, and designers to understand how accessibility impacts the users, set realistic deadlines, and create the solutions to provide a delightful experience to all users, regardless of their physical, sensory, or cognitive ability.

4 thoughts on “Accessible Android Inputs with Material Design”

  1. Any further updates on this? Trying to design an accessible simple log-in form without visible labels using, and can’t have the hint hidden from visual users.

  2. Good question. I haven’t tested lately. I pinged my friend at Google to see if there has been an update on the error message announcing via TalkBack. Also, the bug mentioned in the Update section is still open.

  3. the labelFor (in the textInputLayout) may announce the editText’s hint, but then the talkBack doesn’t announce that this is an editText box at all.

Leave a Reply

Your email address will not be published. Required fields are marked *