Re: can i disabling talkback for specific app?

[Cheryl Simon]

Hi Shiro,

This is probably a better question for the eyes-free-dev list (cc'ed).  In general if you want to make your app accessible, rather than speaking directly you can send accessibility events to the accessibility services.  This will allow your app to work with all of the available screen readers.  You could alternatively suppress all of the accessibility events and just speak yourself, but this would give users a less unified experience, and less choices about how to consume your app (the different screen readers may choose different wording for events that some people like better or worse).  For more information on the accessibility events, check out the developer docs: http://developer.android.com/guide/practices/design/accessibility.html

On Mon, Apr 25, 2011 at 8:43 PM, shiro <shi...@gmail.com> wrote:

hai, sorry for my bad english i have a project to modify android phone
for blind people, thus i use android text to speech. I've managed to
create a SMS and phone application using TTS library from http://
code.google.com/p/eyes-free/ and use myTTS.speak to speak a text. the
problem comes when i use talkback to speak other application like a
launcher, browser etc. when i use talkback they can speak those app,
but when i open my app ( SMS and Phone) there are two sound, first
from talkback and from built in myTTS.speak in my app, how i can
disabling talkback only in my app(SMS and Phone)?so the speak only
come from my app built in TTS, because i'll need talkback when i open
other app

Thanx

--
For Android accessibility documentation, click on this link:
http://eyes-free.googlecode.com/svn/trunk/documentation/android_access/index.html
You received this message because you are subscribed to the Google
Groups "eyes-free" group.
To post to this group, send email to eyes...@googlegroups.com
To unsubscribe from this group, send email to
eyes-free+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/eyes-free?hl=en?hl=en

[blindfold]

Hi Cheryl,

How can one "suppress all of the accessibility events"? Is there
example code somewhere?

Thanks!

Peter


The vOICe for Android
http://www.seeingwithsound.com/android.htm

> >http://eyes-free.googlecode.com/svn/trunk/documentation/android_acces...

[Julian Harty]

Shiro, Peter,

The following code looks like it might be what you're looking for:

    // Don't send any accessibility events since this is a fully self voicing
    // app.
    @Override
    public boolean dispatchPopulateAccessibilityEvent(AccessibilityEvent evt) {
        return true;
    }
And there's a couple of sample applications on the eyes-free project site e.g. RockLock, and see the following file for the example I pasted above for you.http://code.google.com/p/eyes-free/source/browse/trunk/RockLock/src/com/marvin/rocklock/RockLockActivity.java

I think you can also create a service that filters events for a given java package e.g. for com.example.fly which would take priority over the global AccessibilityService services such as TalkBack. Your custom service could handle events and discard those that you don't want to be passed to the global AccessibilityService service(s).

Julian

[blindfold]

I'm still puzzled by what dispatchPopulateAccessibilityEvent() is
supposed to do, or how to use it. Unlike
dispatchTouchEvent(MotionEvent event), which senses any touchscreen
motion in an Activity, putting
dispatchPopulateAccessibilityEvent(AccessibilityEvent event) in an
Activity appears to only generate an event when that Activity is
started and when a new view is set via
setContentView(R.layout.whatever). For instance, the code

@Override
public boolean
dispatchPopulateAccessibilityEvent(AccessibilityEvent event) {
super.dispatchPopulateAccessibilityEvent(event);
event.getText().clear();
event.getText().add("This is a test for replacing screen reader
text");
return true;
}

makes Talkback speak the specified line instead of whatever was set in
the Activity's setTitle(). So at least it does something! Now how can
I use dispatchPopulateAccessibilityEvent() to change what gets spoken
upon a button press? For instance, I have

mybutton.setOnClickListener(new Button.OnClickListener() {
public void onClick(View v) {
// Do something with the button press, e.g. make it self-
voicing in multiple languages
}
});

but where/how do I place dispatchPopulateAccessibilityEvent() code to
make Talkback speak something other than this button's label - for
instance make it speak nothing at all upon a button press?

Thanks!

On Jun 18, 5:33 pm, Julian Harty <julianha...@gmail.com> wrote:
> Shiro, Peter,
> The following code looks like it might be what you're looking for:
>
>     // Don't send any accessibility events since this is a fully self
> voicing    // app.    @Override    public boolean
> dispatchPopulateAccessibilityEvent(AccessibilityEvent evt) {
> return true;    }
> And there's a couple of sample applications on the eyes-free project
> site e.g. RockLock, and see the following file for the example I
> pasted above for

> you.http://code.google.com/p/eyes-free/source/browse/trunk/RockLock/src/c...

>
> I think you can also create a service that filters events for a given java
> package e.g. for com.example.fly which would take priority over the global
> AccessibilityService services such as TalkBack. Your custom service could
> handle events and discard those that you don't want to be passed to the
> global AccessibilityService service(s).
>
> Julian
>

[Cheryl Simon]

Have you checked out the accessibility doc in the android dev docs?  It has an example of using the dispatchPopulateAccessibilityEvent.  Typically you implement this in a custom view in order to dictate what the custom view will say in the events: http://developer.android.com/guide/practices/design/accessibility.html#CustomViews  

In your case, I think you want to extend Button, and override the method to say what you want to say.

[blindfold]

Thanks for your input, Cheryl! Your suggestion of using custom views
indeed gave me progress:

After creating a custom button named myButton through "public class
myButton extends Button {...}", with

@Override public boolean
dispatchPopulateAccessibilityEvent(AccessibilityEvent event) { return
true; }

in it, and using myButton instead of the standard Button, I find that
Talkback no longer speaks the button's label (but my app's self-
voicing does, in the user-selected language). So that is good!

However, Talkback then still speaks the view type, "Button", when
myButton receives focus. How can I keep Talkback from saying "Button"?
Talkback should not be saying anything with myButton.

Thinking (*assuming*) that the event that caused Talkback to say
"Button" came from the parent view, I tried creating a custom
myLinearLayout - since LinearLayout in my case holds the Button/
myButton - and again with

@Override public boolean
dispatchPopulateAccessibilityEvent(AccessibilityEvent event) { return
true; }

in it, but this time it did not make any difference; myLinearLayout
did not receive any AccessibilityEvents.

The second hunch I had was to set the event type in the myButton code
to a non-existent type, event.setEventType(0), and that finally
worked!!

However, knowing that Dianne Hackborn eats developers raw for using
features that are not specified and documented in the Android SDK, I'd
like to know if indeed an event type of 0 is equivalent to what I
would call a (non-documented) "TYPES_NONE_MASK", constant Value: 0
(0x00000000), and if this will be documented and supported as such?

Thanks!

Peter

On Jun 20, 7:24 am, Cheryl Simon <clsi...@google.com> wrote:
> Have you checked out the accessibility doc in the android dev docs?  It has
> an example of using the dispatchPopulateAccessibilityEvent.  Typically you
> implement this in a custom view in order to dictate what the custom view

> will say in the events:http://developer.android.com/guide/practices/design/accessibility.htm...

>
> In your case, I think you want to extend Button, and override the method to
> say what you want to say.
>

[Cheryl Simon]

When you override dispatchPopulateAccessibilityEvent you are controlling what is said along with the event, not if the event is sent at all.   TalkBack has some things it will say along with specific events (like button clicked), and overriding dispatchPopulate lets you add info.

If you really want to eat the events, I think you could override sendAccessibilityEvent and do nothing.  (The View class generally controls the basic event sending, so if you want to see what's going on take a look at that code).

I'm not quite sure what you are trying to accomplish though.. you talk about speaking in different languages, are you just trying to internationalize?  Because there are easier ways of doing that..

[blindfold]

Hi Cheryl,

> When you override dispatchPopulateAccessibilityEvent you are controlling
> what is said along with the event, not if the event is sent at all.

True. I don't really care as long as the main result is that Talkback
does not speak. Making custom controls and there overriding
dispatchPopulateAccessibilityEvent() and setting setEventType(0)
appears to do just that, and my only concern now was that the needed
event type 0 is not defined in the documentation.

> TalkBack has some things it will say along with specific events (like button
> clicked), and overriding dispatchPopulate lets you add info.

Yes, but I wanted to remove info or eat the event to the extent that
Talkback says nothing.

> If you really want to eat the events, I think you could override
> sendAccessibilityEvent and do nothing.

Cool, yes, that works too and avoids my use of an undocumented event
type with dispatchPopulateAccessibilityEvent(). Had not realized it
would work like this. This is more elegant, so I'll use it instead.
Thanks!

> I'm not quite sure what you are trying to accomplish though.. you talk about
> speaking in different languages, are you just trying to internationalize?
> Because there are easier ways of doing that..

Hmm, yes, I am "just trying to internationalize", but not in the usual
static sense where the app follows the locale, TTS engine and voice as
set in the phone Settings. I'm doing it dynamically through a dialog
in my app, and independent of whatever TTS engine and voice is set in
the phone Settings. I do things like speak a sentence about current
location in one language while speaking embedded street names in
another (native to the country) language. Moreover, it all has to work
both with and without Talkback (or Spiel) running. I believe that only
self-voicing with effectively muting the screen reader can accomplish
this, but if there are easier ways then I'd love to hear about it!

Thanks!

On Jun 20, 5:10 pm, Cheryl Simon <clsi...@google.com> wrote:
> When you override dispatchPopulateAccessibilityEvent you are controlling
> what is said along with the event, not if the event is sent at all.
> TalkBack has some things it will say along with specific events (like button
> clicked), and overriding dispatchPopulate lets you add info.
>
> If you really want to eat the events, I think you could override
> sendAccessibilityEvent and do nothing.  (The View class generally controls
> the basic event sending, so if you want to see what's going on take a look
> at that code).
>
> I'm not quite sure what you are trying to accomplish though.. you talk about
> speaking in different languages, are you just trying to internationalize?
>  Because there are easier ways of doing that..
>

[Cheryl Simon]

Ok, I'm not sure if there is an easier way if you want to mix and match languages like that.  Generally, you'd just follow the phone's locale and provide alternate text for each language, but it sounds like you want something more complicate.d

[Mike Arrigo]

One thing you might consier is to do things the way the sendero look around app did. Rather than trying to prevent the screen reader from saying anything, you might consider allowing the screen reader to speak the controls, but using a self voice feature to speak the result of something, such as a color or a location, I would think that would be much easier.

[blindfold]

Hi Mike,

What you describe is the approach that my app (The vOICe for Android)
has been using since October 2009. In fact it goes beyond Sendero GPS
LookAround by automatically detecting if a screen reader is active,
and then restricting self-voicing accordingly (with LookAround, the
user currently has to do this manually). The approach works well for a
single language, but not when switching languages on-the-fly. There is
no API for telling Talkback or Spiel at runtime what TTS engine and
voice they should be using. Now that The vOICe for Android is used in
over 120 countries, I wanted to introduce internationalization in the
most flexible manner, with default language selection based on the
phone's locale, but with options to select a different language on the
fly.

Thanks to the very helpful hints from Cheryl (thanks Cheryl!) it all
works like a charm now.

Peter

[blindfold]

Thanks Cheryl. Yes I wanted more flexibility (not complexity!), and
there is also developer benefit. For instance, while adding support
for a language that I do not know, say Russian, the standard
internationalization approach has two problems with testing:

1. My test phones do not support Russian in the menu Settings |
Language & keyboard.

2. Even if it did support Russian, I would get lost in the phone's
menus after switching to Russian.

Thanks to your suggestions it all works like a charm now in my
developer version.

Peter


The vOICe for Android
http://www.seeingwithsound.com/android.htm

[Cheryl Simon]

Hi Peter,

It was pointed out to me that there is another solution available.  If your goal is to handle all accessibility events for your application yourself, you can write an AccessibilityService and register it such that it receives all events from your package, allowing other accessibility events to pass through to TalkBack/Spiel.  The user would need to enable your accessibility service, but it would prevent you from having to create customs views for each view type.  To do so:

You create a 

AccessibilityServiceInfo

object and set it to have the packageNames that you are interested in. You can then do setServiceInfo with that from inside your AccessibilityService, and that tells the system to only notify you about events from those package names. Anything else will still get passed on, so this will allow your custom service to coexist with TalkBack.

See:
http://eyes-free.googlecode.com/svn/trunk/documentation/ClockBackTutorial/ClockBack0/src/com/google/android/marvin/clockback/ClockBackService.java

Full tutorial here:
https://sites.google.com/site/gdevelopercodelabs/android/accessibility

[blindfold]

Hi Cheryl,

Thank you for the additional info about an alternative service based
approach. I think this is also what Julian hinted at. For me the main
disadvantage would be the need for the user to enable the service,
plus the additional appeal on "trust". I prefer things to be as
transparent as possible to the user. In my case there was already a
lot of control-specific code that I wrote to implement an experimental
iPhone-like touch screen exploration mode, so creating customs views
was a minimal change by comparison, and the user now need not do
anything extra nor give any extra permissions to the app. A slight
downside is that the "look and feel" of the controls will be somewhat
different from TalkBack and Spiel, because neither are used in my
fully self-voicing mode, but I can if needed tweak the self-voicing to
make it look like one or the other screen reader. Right now in my
app's own little world there are no events that I would want to pass
through to TalkBack or Spiel, especially given the fact that I cannot
force TalkBack or Spiel to use the same TTS engine and voice
(language) that my app was dynamically switched to by the user (or by
the app, e.g. when speaking street names in the country's native
language). I will keep your alternative service based approach in mind
in case issues arise that are not easily resolved using my current
approach. I would have been stuck though if it hadn't been for your
very helpful comments on how/where to use
dispatchPopulateAccessibilityEvent() and sendAccessibilityEvent().

Thanks!

Peter


The vOICe for Android
http://www.seeingwithsound.com/android.htm

On Jun 22, 2:06 am, Cheryl Simon <clsi...@google.com> wrote:
> Hi Peter,
> It was pointed out to me that there is another solution available.  If your
> goal is to handle all accessibility events for your application yourself,
> you can write an AccessibilityService and register it such that it receives
> all events from your package, allowing other accessibility events to pass
> through to TalkBack/Spiel.  The user would need to enable your accessibility
> service, but it would prevent you from having to create customs views for
> each view type.  To do so:
>
> You create a
>
> AccessibilityServiceInfo
>
> object and set it to have the packageNames that you are interested in. You
> can then do setServiceInfo with that from inside your AccessibilityService,
> and that tells the system to only notify you about events from those package
> names. Anything else will still get passed on, so this will allow your
> custom service to coexist with TalkBack.
>

> See:http://eyes-free.googlecode.com/svn/trunk/documentation/ClockBackTuto...

>
> Full tutorial here:https://sites.google.com/site/gdevelopercodelabs/android/accessibility
>

[Vijay Koushik Dwarakanath]

Hi Cheryl/ Peter,

I know it is three year old conversation. After looking at the conversation I thought of asking you a question on the accessibility.

I have developed an application for the blind. This application uses my own style of gestures compared to the default gestures on accessbility. My questions is how to do I override the accessibility function? I have my own TTS etc. I tried the following before onCreate.

// Don't send any accessibility events since this is a fully self voicing

// app.

@Override

public boolean dispatchPopulateAccessibilityEvent(AccessibilityEvent evt) {

return true;

} But doesn't do anything. can you please help me out in telling me how to override this the accessibility function

?

Awaiting your response!

Thanks,

Vijay

[blindfold]

Hi Vijay,

The way I do it is to define my own version of the controls that I use, for example myButton, and then use myButton instead of Button everywhere (also in the layout XML). Then you can control which events go to the screen reader and which ones your control "eats" because you handle those yourself elsewhere. E.g.,

public class myButton extends Button {

    public myButton(Context context) {
        super(context);
    }

   public myButton(Context context, AttributeSet attrs) {
      super(context, attrs);
   }

   public myButton(Context context, AttributeSet attrs, int defStyle) {
      super(context, attrs, defStyle);
   }

   @Override
   public void sendAccessibilityEvent(int eventType) {
      if (accessibilitymanager.isTouchExplorationEnabled()
            && eventType != AccessibilityEvent.TYPE_VIEW_CLICKED
            && eventType != AccessibilityEvent.TYPE_VIEW_FOCUSED
            && eventType != AccessibilityEvent.TYPE_VIEW_SELECTED) {
         super.sendAccessibilityEvent(eventType);  // Let screenreader have it
      }
   }  // Don't send any other events

}

Peter


The vOICe for Android
http://www.seeingwithsound.com/android.htm

[David Engebretson Jr.]

I'm in the market for a new Android phone.

What is the best phone to ghet for TalkBack usefullness, and longevity of
usefullness as a development/test hardware device? All bells and whistles
wanted, and I don't want to have to buy another phone next month to keep up
with the changing phones and market.

Thanks,
David

[@Dev]

Thanks for the quick reply Peter.

I tried it out. Works just fine for phone or tablet until 4.0.3. There are two problems here.

1. I have lot of image buttons, text box, labels etc... used and disabled this just for show. Creating buttons programmatically in the same format like the xml file is not possible very difficult job.

2. The idea below doesn't work for 4.1 and above.

Is there any other way? Like create our own accessibility service using.. accessibilityserviceinfo ???? Have you tried this?

Awaiting your response,
Thanks,
Vijay

[blindfold]

Hi Vijay,

I do not know what Google changed with Android 4.1, if anything, that breaks what used to work. I have not made changes for Android 4.1. Perhaps Google's developers can answer your accessibility question.

Peter

[Koushik]

Have you tried accessibilityserviceinfo????

--
You received this message because you are subscribed to a topic in the Google Groups "Eyes-free Programming and development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/eyes-free-dev/DN5FXGmyJWg/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to eyes-free-de...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[NiS]

Hi Dev,

Google published on Google Play an update for TalkBack that brings back the manual check box for Explore By Touch.

Maybe it would be a good time to try again the code that worked for the previous android versions.

Please update if it works for you, I am also trying to work this out.

Thanks

בתאריך יום ראשון, 31 במרץ 2013 02:54:17 UTC+3, מאת @Dev:

[gustavo...@gmail.com]

Hi all !

I know that this post is very old. But i can´t resolve my problem...

I'm developing an aplication for the visual impaired. As I'm using TTS, i want to disable all TalkBack notifications.

I've read a lot of post, but nothing seems to work. Is there any way to do this ?

Thanks !!

[stere...@yahoo.com]

I would like blind users using Accessibility TalkBack with Explore-By-Touch to STILL be able to draw on a view with a single finger.

I can catch the single finger "Hover" events using onHoverEvent() etc. - however the Explore-By-Touch sounds are still issued when the finger swipe begins and also the first section of the drawn stroke lags which spoils the drawing.  Meanwhile a two-finger draw stroke is more responsive - as it generates onTouchEvent() method calls.

Is there any way to disable Explore-By-Touch sound as well as any processing being done - so that the draw stroke by a single finger can be captured efficiently - i.e. as good as the one with 2 finger swipe draw on screen ?


I tried adding the suggested method to the custom view:

   @Override
    public boolean dispatchPopulateAccessibilityEvent(AccessibilityEvent evt) {
        return true;
    }

however, it didn't seem to help in this regard.

Thanks.

[stere...@yahoo.com]

The problem with single finger drawing on a view is that, even if you handle the onHoverEvent(), the touch events after the first event are not delivered until the finger moves far enough away from the first pen down point.

As this seems to be the trigger for Explore-By-Touch swipe sound - i.e. you press the screen and swipe and if you swipe far enough away you hear the sound.

The problem is that after the first pen down point, further points are not delivered until after the sound has been emitted - thus for EVERY stroke on screen, the first and second points are always very far away and all the points in between are missing.

Also if you press and draw something small, those mouse events are not delivered.


So any way to disable this behavior so blind users can draw using single finger on a view ?

Thanks.

[stere...@yahoo.com]

Quote:

I tried adding the suggested method to the custom view:

   @Override
    public boolean dispatchPopulateAccessibilityE

vent(AccessibilityEvent evt) {
        return true;
    }
End of Quote.

Using dispatchPopulateAccessibility() as above DOES seem to help in that the Explore-By-Touch sound is no longer issued (when you single-finger swipe).  HOWEVER, the MouseEvent points are the same as before i.e. for every stroke the first two points are very far away (i.e. second point only delivered AFTER have swiped far enough away from original pen down point).

So rest of behavior ie. pen events is same - just the the Explore-By-Touch sound is no longer delivered.

On Monday, March 10, 2014 10:50:31 AM UTC+5, stere...@yahoo.com wrote:

[Pedro Colinas Núñez]

Thanks Peter, very useful tip, I was incapable of solving the "talkback talking over my TTS" problem and creating my own controls was the only way.

Pedro.

[Mateus Machado Luna]

I know I might be bringing something out of the darkness of 2014, but have you found any solution to this?

I'm facing a similar situation where I want to implement a different behavior to an specific activity. I want to handle clicks and gestures by myself there,and I could disable Talkback audio feedback, but I'm not able to prevent it's touch interaction scheme...