Android Custom Views Part 4: Making Views More Accessible

Robin Kamboj
MindOrks
Published in
3 min readAug 13, 2017

developer.android.com provides a very good and descriptive explanation as to how can one add accessibility hooks onto a custom view, my only complaint (and many others’ complaint) is the elaborative length of the same. So here basically instead of explaining it all the same, I will be giving out key highlight points from the documentation provided here.

The following are the key take-away points:

  1. Implementing accessibility API methods: There are four main accessibility api methods: sendAccessibilityEvent(), sendAccessibilityEventUnchecked(), dispatchPopulateAccessibilityEvent(), onPopulateAccessibilityEvent(). Some other useful methods are onInitializeAccessibilityEvent(), onInitializeAccessibilityNodeInfo(), onRequestSendAccessibilityEvent().
  2. sendAccessibilityEvent(): This method is used when user is intended to take an “action” onto your custom view. For example, if a user clicks on your custom view, you will be required to override onTouchEvent(MotionEvent event), then apply switch case on event.getAction(), then at case MotionEvent.ACTION_DOWN add sendAccessibilityEvent(AccessibilityEvent.TYPE_VIEW_CLICKED). Similarly, there are other symbolic constants named in the documentation to be used in a similar way. The action taken on these “sent” accessibility event occurs only if accessibility is enabled in the system settings.
  3. sendAccessibilityEventUnchecked(): This method performs the sending of accessibility events same as sendAccessibilityEvent(), except the fact that action taken on these “sent” accessibility event occurs regardless of the fact if or if not accessibility is enabled in the system settings.
  4. dispatchPopulateAccessibilityEvent(): The default implementation of this method calls onPopulateAccessibilityEvent() for this view and then the dispatchPopulateAccessibilityEvent() method for each child of this view.
  5. onPopulateAccessibilityEvent(): This method sets the spoken text prompt of the AccessibilityEvent for your view. This method is also called if the view is a child of a view which generates an accessibility event. For example, a Textview with content description “Text View” was clicked, a sound prompt “Text View was clicked” may be triggered if TYPE_VIEW_CLICKED was dispatched.
  6. onInitializeAccessibilityEvent(): The system calls this method to obtain additional information about the state of the view, beyond text content. If your custom view provides interactive control beyond a simple TextView or Button, you should override this method and set the additional information about your view into the event using this method, such as password field type, checkbox type or states that provide user interaction or feedback.
  7. onInitializeAccessibilityNodeInfo(): This method provides accessibility services with information about the state of the view, particularly when your view extends the bounds of a simple view, for example, a custom calendar with 30 dates information cant be sent out without this method. Without this function information sent out will be “Calendar”, or at the very best, “April calendar”.
  8. onRequestSendAccessibilityEvent(): The system calls this method when a child of your view has generated an AccessibilityEvent. This step allows the parent view to amend the accessibility event with additional information. You should implement this method only if your custom view can have child views and if the parent view can provide context information to the accessibility event that would be useful to accessibility services.

To sum up, as compared to an inbuilt view such as TextView and ImageViews, where just adding static (xml) or dynamic (java) contentDescription suffices for the accessibility to a great extent, making custom views accessibility seeks for a longer route to accomplish something better and new.

If you want to know more about making simple views accessible, you may visit my post on the same here.

I hope this post was of useful context to you. If it was, please hit the heart ❤ for this post. And as usual, happy programming. :)

Link to other parts of this series:

--

--

Robin Kamboj
MindOrks

Software Engineer by profession. Designer by force. Bibliophile by nature.