IssueTracker

Working as intended. Snackbar now disables animations if there is an accessibility manager enabled on the device. The reason why this happens is to enable Talkback to be able to reliably announce Snackbars.

It is intended to slide up with a flickering animation then stays up there even after the snack bar disappears?

I am also sure that all accessibility options are disabled on my device unless you're talking about a different options beyond the normal settings.

I mean with overlapping animation for a second the snackbar goes under the fab then the fab slides up after that then stays there.

The check is AccessibilityManager.isEnabled(), which returns true when any accessibility service is enabled. I've just check on various API levels Snackbar is working fine without an accessibility service enabled.

The FAB now returning is a bug, but that only happens with an accessibility manager enabled.

Can this check be any more fine grained to Talkback instead. It seems a little strange that I don't get animations just because I use Tasker.

No, since Talkback isn't the only accessibility manager out there, we do not want to get into the business of whitelisting things. The accessibility manager APIs are there to support accessibility, if Tasker is misusing them for other purposes, then so be it.

Then maybe make the accessibility check configurable so a developer can make it opt in/out.

Accessibility is a broad spectrum that can cover a lot of things. Personally I think it is a poor decision to remove visual niceties because an unrelated option is enabled.

Some of the bugs (like your non returning Fab bug) it will cause will be so hard to track down as a dev has no way of knowing what options are enabled on a users device or even that it makes a difference.

Users are unforgiving too and the poor appearance of the Fab (appearing behind the snackbar then jumping above it) will likely be cause for complaint.

The FAB not returning will be fixed in a future release.

Does it make sense that the snackbar will not animate for ANY accessibility manager? I have only 1Password autocompletion enabled, and it doesn't make any sense to disable animations with that.

Released in 23.4.0

I'm still seeing the same behavior in 23.4.0

[Comment deleted]

My comment in #5 still stands. Animations are disabled when there's an accessibility manager is enabled. That's not changing.

The thing that was fixed was the that the FAB did not return when animations are disabled.

Ok, I had some custom behaviors based on the FloatingActionButton's behavior and probably need to look at the new FloatingActionButton.Behavior.

I'm curious, why is this deemed a bug in the Snackbar/FAB instead of TalkBack?

The animations cause it not to see the text, and therefore not announce the Snackbar.

>The thing that was fixed was the that the FAB did not return when animations are disabled.
I am still seeing this bug even with 23.4.0.


1 - I have disabled animations from the developer options in order to reproduce the bug:
Animator duration scale -> Animation off

2 - I am pulling in the 23.4.0 release:
compile 'com.android.support:design:23.4.0'

But the issue persists.

I should note that if you swipe the snackbar manually the FAB returns to its original position (in both 23.3.0 and 23.4.0). But if you let it disappear on its own the FAB stays elevated.

[Comment deleted]

23.4.0 fixed the issue for me, now the FAB goes back to its initial position after sliding up when SnackBar.
Thanks Google.

Z1 Compact - API level 21

[Comment deleted]

[Comment deleted]

On my LG G5 I turned off all accessibility features, but AccessibilityManager.isEnabled() always returns true, so I can't see any Snackbar-Animations. It does not seem to be the right solution to use such a general dectivation for the animation

One addition: if it is for talkback like mentioned in #2, why not use

AccessibilityManager.getEnabledAccessibilityServiceList(AccessibilityServiceInfo.FEEDBACK_SPOKEN)

If the returning List<AccessibilityServiceInfo> is empty, there is no ScreenReader and we can animate. Maybe there are more flags to check, but it is possible.

Also happened in samsung 7.0 。 The animation is fine in 6.0,but failed after upgrade to 7. The library version is 25.2.0

I have parts of layout which should slide up and down above snackbar. Version 25.3.1. Still not returning back after snackbar disappears if accessibility permission for Twilight is enabled.

See http://stackoverflow.com/questions/32798807/floatingactionbutton-does-not-come-down-when-dismissing-snackbar - answer by newfivefour. It seems to solve the issue with non-returning fab.

This is still a major issue in 25.3.1, and is becoming a larger issue as more people use things like password managers, which qualify as Accessibility features and disable snackbar animations. Seems a bit absurd to globally disable animations for a small use case like TalkBack. Right now we're stuck rolling own snackbar implementation if we don't want it to look like crap for half our users.

Hitting this issue too – it is probably not a good idea to globally disable a framework component's feature for a single app (TalkBack). There are probably better ways to achieve good accessibility integration than downgrading the general user experience.

#30 & #31: Talkback is a core accessibility service. The accessibility APIs are there specifically to enable more accessible interfaces. Password managers are a minor use case for the APIs, which is why the auto fill APIs have been announced in Android O. We have no plan to change the behavior in Snackbar.

So rather than make it easy-to-use, you've just used the heavy handed "we don't care" approach to this fix?  Great, sounds like a good way to continue "improving" the API by just ignoring the problem and saying "we won't fix it".

If the animations are causing TalkBack (and possibly other Accessibility things) to "not see the text", I think that's a bug with Snackbar, and just disabling animations does not seem to be the best way to fix it - rather, fix the core problem, by doing whatever is necessary for those features to "see the text" WITHOUT having to outright disable the entire animation effect.  This is still a bug with the way Snackbar works.  Animation and accessibility do not need to be mutually exclusive.

If the animation causes an issue with TalkBack, why not use the approach suggested earlier in the thread by checking the kind of accessibility service used from the AccessibilityServiceInfo?

In my case my BaseTransientBottom bar shows an indeterminate progress bar with no text, so despite having no text to read my SnackBar doesn't animate with a password manager accessibility service. Why should users of my app suffer a subpar experience for something like this?

Furthermore there's a bit of a double standard here as certain Google Apps despite having an accessibility service on still animate their SnackBars.

So please reconsider the stance on not changing this API. A ProgressBar SnackBar should animate, there's no text to read and so an API decision made regarding TalkBack should NOT affect it, the fact that it does suggests solving a problem by treating a symptom, not the cause.

I opened a new issue with a fix proposal to disable animations only if there's a screen reader accessibility service. Feel free to star it: https://issuetracker.google.com/issues/72245698

This has been fixed since Material Components for Android 1.0.0-alpha3! Here's the commit: https://github.com/material-components/material-components-android/commit/7aff9d2e8b5d62d3d7c554d3debfe9f1a11a7c77