Question 247538 in Android Studio Question posted in
The official documentation can be found here.

Android Studio – How to check TalkBack on/off status and get change notifications in Android mobile?

I’m working on an Android mobile application and need to know if TalkBack is active on startup and detect TalkBack off/on state changes while application is running.

Previously the code used JavaScript accessibility component and called C++ and then Java. Now we only want Java code.

How can I implement this functionality?

Tags:

2

Answers


  1. Chosen as BEST ANSWER
    0

    I was able to get the Talkback active/inactive status notification using AccessibilityManager.addTouchExplorationStateChangeListener. This resolved the issue I had with Android mobile.

        try {
        am = (AccessibilityManager) context.getSystemService(Context.ACCESSIBILITY_SERVICE);

        am.addTouchExplorationStateChangeListener(new AccessibilityManager.TouchExplorationStateChangeListener () {
            @Override
            public void onTouchExplorationStateChanged(boolean enabled) {
                onTalkbackStatusChanged(enabled);
            }
        });
    } catch(Exception ex) {
       ...
    }

  2. 0

    As with previous answers on this topic, you can check the state with the snippet below. This is best practice because not all versions of TalkBack (screen readers) are the same. Google, Samsung and Amazon have their own screen readers. Not to mention that a user may have installed a 3rd party screen reader.

    AccessibilityManager am = (AccessibilityManager) [context.]getSystemService(ACCESSIBILITY_SERVICE);
boolean isExploreByTouchEnabled = am.isTouchExplorationEnabled();

    There is no mechanism for "subscribing" to changes here, you’d have to roll your own by polling this value. I have done this in Kotlin but not java, and it reduces the efficiency of the app for all users (even if it’s just a little).

    You should also be aware that in Universal Design terms, you’d be going against the principle of ‘equitable access’:

    The design is useful and marketable to people with diverse abilities.

    Guidelines:
        1a. Provide the same means of use for all users: identical whenever possible; equivalent when not.
        1b. Avoid segregating or stigmatizing any users.
        1c. Provisions for privacy, security, and safety should be equally available to all users.
        1d. Make the design appealing to all users.

    This is not to tell you that your particular use-case (which I can’t tell from the question) does not call for it, but remember other people will be reading this answer too. It’s considered bad practice to detect screen readers:

    The reasoning boils down to two issues: development and privacy. And it’s bad for both.

    The core reason is that you’re not supporting all accessibility by supporting TalkBack alone, and creating a specific mechanism here, you’re missing Voice Access users, Switch Access users, Screen Magnifier users, or even custom accessibility service users.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search