Similar to this iOS-question ( VoiceOver announces dimmed instead of disabled for buttons ) I have the same problem, but for Android devices with Talkback.
Why is Talkback announcing some elements like buttons or checkboxes as "dimmed" instead of "disabled"?
Should I somehow change this, or leave it as Talkback reads it? If I should change it to "disabled / dimmed" so that it's consistent over the whole app, how?
[EDIT]:
Example:
It seems that not only buttons use "dimmed", but check / tick boxes as well.
Also only the english language seems to use "dimmed", in german it's still read as "deaktiviert" (disabled).
Don't change it. TalkBack is responding to properties in ways that users would be accustomed to. Sometimes the default behavior is the most accessible because it is expected, even when it isn't quite ideal.
If you would like an answer to the "why" I would need more information on the particular examples that your talking about. Are there apps that exhibit this behavior? TalkBack updated not too long ago, but I generally hear the "disabled" announcement over the "dimmed" announcement from TalkBack from the "obvious" times that such an announcement would apply. I certainly wouldn't expect there to be a general distinction between the two.
Also, I'm looking through the current version of TalkBack (again TalkBack has been updated recently, so the open source version may not be up to date and available) and can't find the localized string "dimmed" anywhere. There are references to "screen dimmed" but this is certainly different from what you're talking about. Which suggests to me that the "dimmed" announcement is coming from changes in the code that I would recommend be UNDONE, so as to allow the "disabled" announcement that TalkBack users would be accustomed to. This sounds to me like something someone coming from an iOS background wanted to duplicate. The behavior in iOS is to announce disabled things as "dimmed". Duplicating this on Android would absolutely be innapropriate. Let TalkBack do its thing!
Providing code examples would be helpful for me to be more sure about all of these things, your question is quite ambiguous. What types of controls? A Button for example may behave different from a Tab in a TabWidget, and this may be intentional. The way your question is worded, any more specific answers than I have given would be speculative.
EDIT:
The different parts of this announcement:
Every Sunday (0): The text of the control
Tick Box: The calculated role of the control. In stock Android this will announce as "CheckBox" (I'm testing on 7.0, with the current GitHub TalkBack). Samsung would be best off to leave this as "Check Box" from stock Android OS, I don't know why they felt the need to change "Check Box" to "Tick Box" just to be different. Doing things just to be different is annoying, there is no objective difference between "Check Box" and "Tick Box" (licensing???).
Not Selected: The current calculated state of the control. In Stock Android this would read out as "Not Checked". Unless the app is overriding this, Samsung would seem to be mucking with this as well. They should stop doing so, but again, out of your control and best left alone. Samsung users will be used to this. Though ultimately I find "Not Selected" to be a little ambiguous in terms of a CheckBox control. "Not Ticked" I think would be better.
Dimmed: Again, another thing that, unless your code is overriding (which I don't think it can in this case for this bit of calculated state). This is the calculated enable/disabled state of the control. In stock Android this would read out as "disabled". Again, leave this alone. Samsung would ALSO be best to leave this alone.
It would definitely appear that Samsung is doing strange things to the Accessibility read outs of calculated components. I'm not sure what version of Android this Samsung flavor is built off of, but I don't believe those read outs have changed. I know CheckBox and Disabled have been the same since 4.2 - 7.0 (probably Android O as well.). These minor changes fracture the Android Accessibility Ecosystem. For these particular elements, Samsung would definitely be best off just to leave them alone. HOWEVER, given that Samsung has made these changes, you are best off NOT fixing this fragmentation. Let Samsung users and Nexus users and Motorola users experience things in the way they are used to and get accustomed to their devices. Allow default behaviors unless overriding them is absolutely necessary. Hearing "disabled" when your expecting "dimmed" is confusing, not to mention a maintenance nightmare should Samsung decide NOT to override this any more or vice versa. When the OS is "calculating" state and doing so reasonably... let it happen!
Related
I'm looking into these docs: TelephonyManager, Preference and others, but I cannot find anything useful related to Left handed layout.
As far as I know Android 2.3 had that setting. Right now I am unsure if it was deprecated or not. Is there a way to detect if "left handed mode" is set?
Left Handed Mode is possibly similar to "Force RTL Layout Direction" In "Developer Options".
There was never an Android standard setting added to the API for a 'left handed mode'. You may have seen a manufacturer specific change to Android, but I don't know of any recent Android device that has a similar feature.
Individual Android app developers may add the option to switch to a "left handed mode" that will alter the UI to be better formatted for users who hold phones and devices in there left hands. I am an active "Lefty rights" advocate in the app world and call-out developers who could easily better accommodate left handed people. As far as a handicap/accessibility setting there is no current setting on Android for that. There is actually a RTL layout setting in "Developer options" you can enable it through these instructions, and apps like Chrome and Google Maps use it. I would think some more research would need to be done to check for that seeing how it's a developer option and not an accessibility option. My guess would be it is similar to getting the device locale and adjusting. I'm not sure if you could find the developer options in resources though. (Noting for full disclosure, the last time I programmed android was a few months ago.)
I would buy a phone that had RTL/ Lefty Mode perfectly implemented though.
Hope this helps a little.
Have an awesome day, and be well!
I've been writing an new app for our company and came across an odd thing. On the test device (running 2.3.x) the alert dialog buttons will always be in the order of:
POSITIVE | NEGATIVE
Yet, when I tested the app on my personal cell (running 4.x) the alert dialog buttons were switched to:
NEGATIVE | POSITIVE
The code is obviously the same.
I don't really want to make different versions. But I could cater for later versions in code, and maybe (although its rubbish) swap the text of the positive and negative buttons... Which would work, I'm guessing, but it's a bit horrible!
The only problem I can foresee, is that our end-users aren't that tech-savvy and having multiple devices, using differing versions of the OS, could cause issues (which I could easily cater for, but would rather some kind of 'standard').
Is this something I can get around? Or is it best to leave as is and let the OS handle it (as I am doing now)? Also, are there any other small issues I'm going to run into. I.e. Can I guarantee that on 4+ devices that if I'm only using 2 buttons that they will remain in the above order.
What I'm hoping someone will post is a hidden flag that magically sets 4.x alert dialogs to 2.x style :) I'm pushing my luck, I know!
Cheers. Any help is greatly appreciated.
It's an interesting piece of lunacy from Google (see issue 24138) but, as of ICS, this is how it's supposed to be. Definitely best to let the OS choose the ordering.
If you wish to have it the same for all versions, you could potentially check which version of Android is being run, and change the negative/positive buttons yourself. I don't recommend it, and people will expect it to like it is on their device, don't shoehorn everyone into having the exact same flow.
We’re porting to Android some interactive iOS apps used to teach young children with learning disabilities. We have hit a major usability issue, because we can't figure out how to disable physical or on-screen navigation buttons (Home and Recent Apps).
Before anyone says “you don’t want to do that”, we fully understand why you would always want these buttons enabled for an able-bodied adult, but these children pose a unique set of accessibility issues. Specifically:
Their fine motor control may be poor - they may inadvertently touch a different area of the screen to the area they intend, or accidentally use more than one finger at once.
They may have weak muscle tone and poor physical strength – so e.g. the bottom of the palm of their hand may drop and touch the screen while trying to just use a finger.
They struggle to achieve and easily become disheartened or disruptive if they fail.
For instance, a typical 5 year old child with Down syndrome will accidentally drop out of the app they are using as a result of inadvertently touching the Home button: when this happens repeatedly, and the adult teacher or parent has to go back into the app for them repeatedly, the child loses interest and focus. Another typical scenario is a young child with Autism, who may freak out completely and need physically restraining if this happens while using their favourite app. Also, many disabled children will try to poke any other button they can find, in search of a response. In any of these situations, a potentially valuable educational session may have to be completely abandoned.
We're aware of SYSTEM_UI_FLAG_HIDE_NAVIGATION and SYSTEM_UI_FLAG_LOW_PROFILE, but these only reduce the visibility of the on-screen buttons until the child touches some other part of the screen, and then they re-appear in a way that’s more distracting than if they were visible all the time.
On iOS there is the “Guided Access” feature that solves this problem trivially. Can we emulate anything similar on Android?
On iOS there is the “Guided Access” feature that solves this problem trivially.
Guided access appears to be a device setting, not something that developers enable unilaterally themselves, thank heavens.
Can we emulate anything similar on Android?
There is no similar device setting in stock Android.
You can download the Android source code, modify it as you see fit, build the results into a ROM mod, and install that ROM mod on devices as you see fit.
Or, you can perhaps work with a device manufacturer creating tablets aimed at children to see if either they have already added this capability to their devices, or would be willing to work with you to add such a capability in a future iteration of their devices.
Android SDK suggests developing button states (if on a custom background) around Normal, Disabled, Focussed, Focussed + Pressed and Focussed + Disabled etc.
What I have observed is that mainly android tablets and modern phones, they all have given up on a trackball and nobody really supports them. So in that case, focussed and the related states are something that will never become visible.
Is it necessary to include all those states? Or, can I intelligently save some APK file size by avoiding those graphics currently.
Please send your thoughts.. Thanks
I'm inputting my point of view myself. I have included all the states as of now because I think its best from a standards perspective and I think of one situation when users will really encounter the state where focussed styles have to be shown. I imagine the case when users have external hardware (like a bluetooth keyboard) attached and it somehow enables them to move to those buttons using the arrow key.
Please comment in your thoughts around this perspective too
Here's what I need to do. I want to use an Android tablet for science research, but I will need to programmatically control the screen/backlight. Specifically, there is a mode where my app will need to communicate with other systems via WiFi, play sounds, and have the touchscreen active, but the backlight must be completely off; in this mode, the device cannot emit any light, or it will interfere with the science. Obviously, this cannot be sleep mode! Is this feasible?
I've looked around a bit, and this sounds really promising, but it isn't crystal-clear (to me, anyway!) whether this will work. Can anyone vouch for that?
Finally, does it matter which tablet I choose? Basically, there seem to be three possibilities: the backlight is controlled with a switch (doubt that is done anymore), the CPU can only turn it on or off, or the CPU can adjust it fully. Writing this makes me feel rather silly about being concerned, but a Samsung rep yesterday told me I can't do this on the Galaxy. Anyone care to recommend a tablet?
Thanks!
Specifically, there is a mode where my app will need to communicate with other systems via WiFi, play sounds, and have the touchscreen active, but the backlight must be completely off
Android does not support "have the touchscreen active, but the backlight must be completely off". And, you do not have the ability to turn the backlight "completely off" programmatically.
I've looked around a bit, and this sounds really promising
That sets the backlight to be low. Some devices may elect to turn the backlight off when it is set low. That is up to the device manufacturer.
Finally, does it matter which tablet I choose?
See above.
Since its a science research I'm going to assume you may not need to divulge this application and want it in a controlled environment. If this is the case, a little creative thinking suggests that since the touch screen will still react to even if covered by a thin layer of plastic (like the screen protectors for instance) you may be able to apply some opaque vinyl on top of the screen (easy to remove) for doing the experiments.
This may not be useful but since to me it sounded like it could I thought I'd share my thoughts with you on this one. Once you've covered the screen with the vinyl, the rest is as usual, keep screen on, and do your magic.
:)