I recently worked on accessibility and implemented it’s missing elements to the apps I am working on.

While doing so, I learned and observed quite a few things about accessibility in Flutter on both platforms which I am going to share in today’s article.

Approach on accessibility during development

We all know how important accessibility is to any app, as it gives an opportunity to users with special needs to access and use the app and therefore, helps to reach wider user base.

One good approach while testing out accessibility for any app especially for visually impaired users is, to turn ON screen reader, close eyes and start navigating through the app. This way, the app would expose minor things to the developers who may not have thought of cases or might have missed adding labels or tooltips to the widgets while implementing accessibility.

I used the same approach to get an idea of how Flutter handles the following aspects:

Accessibility on both platforms

What are the ways to implement it

How to use those ways

Where do the apps-under-test stand from an accessibility perspective?

Testing

Accessibility in Flutter

Flutter gives developers a jumpstart by identifying and reading most of the widgets on screen as is. Meaning, if a non-text widget doesn’t have a label, tooltip or text property specified, then Flutter would only read that widget based on its type. For instance, an image would be read as {image} or an iconButton would be read as {button}.

As an end-user with visual limitations, these would not be enough and convincing, because they would not know what kind of image is on-screen or what type of button is it. They would always expect that the app will read something like {Company logo image} instead of {image} or {edit button} instead of {button}.

This is when developers would need to add required properties to corresponding widgets and use various accessibility widgets, so that the widgets are read as expected and users would get a smooth and seamless accessibility experience navigating the app.

Let’s now see how accessibility in Flutter works by default with a demo app.

Demo app

As seen above, we have a login screen with an image at the top followed by two textformfields with hintText , a password obscure icon , a switch widget and a RaisedButton .

Now if we turn ON screen readers on both platforms and navigate through the widgets on screen, we notice below behavior:

Note: I used Android Nexus 5X (8.0) and iPhone 6s (11.2.1) configuration.

As we see from the table, some of the widgets are not read as expected (highlighted in blue). Let’s now see how we can make use of accessibility properties to fix the above behavior.

Starting with the image at the top, since I used Image.asset , it provides property named semanticLabel which, as the name suggests, is specifically used for accessibility. Here we provide the appropriate label to the image so that the screen readers can now read it properly.

Image.asset('assets/images.png', height: 100, width: 100, semanticLabel: 'Company Logo'),

Coming to the textformfields with hintText, as the table above suggests, the screen readers don’t read hintText of first textformfield when we select that widget (highlighted in red).

This seems to be an issue with the accessibility framework at the moment and I’ve raised an issue.

As a workaround, if we use labelText instead of hintText , then screen readers reads first textformfield properly as {username editbox} , but password textformfield is read as {Password password editbox}.

One might wonder why the password is read twice. This is because it first reads the labelText password followed by password editbox.

Next, we can use semanticLabel for red_eye icon, so that screen readers will read it as expected.