Welcome to Accessible Phones, your one-stop resource for information on phones which are usable by the blind and visually impaired.
Check out A T Guys for great prices on screen readers for your phone.Mobile Magnifier for Pocket PCS
I should preface this one with a bit of history. Back when a keyboard was a requirement for accessibility on Android, many apps included built-in keyboard navigation to control what would happen if, for instance, someone pressed the up or down arrow keys. This was great for 2010 but now just causes confusion for both users and developers. Sometimes it's just best to realize that your way of doing things doesn't make sense anymore and adopt practices that are more standard. Pressing right arrow should act the same as swiping right and pressing left arrow the same as swiping left. Other keyboard commands can be mapped to mimic other gestures. Being able to operate your phone primarily using keyboard input offers many benefits for those in quiet or loud places or for people with dexterity issues. Would you add a command to your program that did something different every time you performed it? That's essentially what pressing the arrows and other keys do now, and it just doesn't make sense.
One of my biggest annoyances is when a company touts an amazing new feature and then disables it for blind users. Android 4.4 added a feature where someone could say the phrase "OK Google" to activate voice search. It's the type of feature that could be really cool in the right situation, though I'm not sure if I'd always keep it turned on. As it turns out, I have no say in the decision because enabling Talkback disables the "OK Google" feature. Perhaps it had something to do with audio conflicts. Whatever the reason, it should at least be an option, just like it is for everyone else. Are we really afraid of Talkback activating Voice Search by itself? And if that really was a problem, I doubt it'd be a regular occurrence. We've seen this feature work on some alternative versions of Android, and it's time to bring it to the rest of us.
This is one of those features that may not see its way directly into Android 4.5, but is still deserving of a mention because it is sorely needed. It is not very efficient to type in braille with only uncontracted braille is an option. The translation tables are available, as one can display text in contracted braille. But input is another story entirely. Brailleback, Android's braille display driver, has been around since 2012, and it's time to move it forward.
It's very telling to me when a developer is having difficulty adding a simple accessible text box to their app. In fact, it's nearly impossible without lots of custom programming. There are methods in place to handle buttons, switches, sliders, and other common controls but Talkback falls quite short when it comes to edit boxes. Part of this comes from the lack of commands to navigate through a document while other behaviors just don't make sense. I should be able to move line by line through a document using a keyboard or braille display and have the text of that line displayed and spoken. What other system have you seen where moving to the next line just speaks the first character of the new line? This is one of those improvements that could provide increased accessibility to plenty of apps without the developer needing to do anything. Android 4.3 added some basic text selection controls, and some of these commands work well for short phrases. But there needs to be more ways to move around a document, regardless of the way you choose to type.
This one's simple and one of those features that was added in iOS 7 that should be copied for Android. It should be a simple task to enable or disable Talkback from voice search. Why not take it a step further and allow someone to select a voice, language, or voice speed? Google is starting to add shortcuts to open various settings screens by voice, and this would be a natural extension of this feature.
For those of you who use Android, you likely know of the immense power of widgets. Widgets are small blocks which can appear on a home screen to display information such as the weather, allow for shortcuts to an app's functions such as a record button for a voice recorder, or allow someone to change settings quickly. Google has created a widget for just about every other app, but not Talkback. A Talkback widget could allow someone to change their phone's voice from the home screen, or adjust the speech rate on the fly. It would be another level of convenience for users and a welcome addition.
Android accessibility has come quite far since 2010, but perhaps one of the most talked about changes in recent years was the altering of Talkback's sound scheme. It's more musical, more prevalent, and to many people, much more annoying. For me, I usually turn the volume of Talkback sounds down to 25 percent, but I know many others find the current tones unbearable. A way to mute certain sounds or replace them with alternate files would be quite useful to many. Or perhaps offering the old sound scheme as an app to download would be a reasonable compromise. Some have suggested shortening the sounds. I appreciate some of the cues that are given, especially the increasing tones when moving through a list of items, a rather innovative approach to an earcon. But since sounds are so commonly used in Talkback, more options to manipulate them would be something to think about. And while we're at it, a learn sounds page would be a great way to show users what all these beeps and blips mean anyway.
Android's most accessible web browser isn't built-in to the operating system, and I'm fine with this. Any user who has learned how to use Google Play can go get Firefox for a well thought out browsing experience that is one of the best on any platform. But users shouldn't have to deal with web lockups and clunky navigation when loading pages on Chrome. Since Chrome is the browser used for apps which choose to embed a web browser, it should be a priority for Google to make it work flawlessly. This includes lag-free navigation and ways to easily jump between elements such as headings or lists. I'll use Firefox for my serious web browsing, but that's no reason to forget about making Chrome sing.
If we could avoid duplicated effort, we would have more accessible mobile platforms. Android 4.3 added the ability to label icons. So instead of hearing "button 52" for example, you can attach a meaningful name to the button. But with many users playing with the same apps, a way to share icon labels would be a big leap forward. Missing icon labels is one of the biggest oversights by app developers, yet one of the simplest to overcome. Instead of having every user provide labels for the same app, why not allow for users to share icons? If a centralized repository is overreaching, Google could allow for users to import and export labels or allow for external programs to update them. Then someone could create an app to manage labels so the sharing could commence. The technology is all there, and this feature is a long time in coming.
One of Android's biggest accessibility shortcomings is its lack of documentation. I realize that Google has never been very verbose when it comes to explaining new features, and I can live with that. But downloading a new version of Android shouldn't lead us to an accessibility scavenger hunt. Without some pointers on what to look for, it's hard to understand how to use the latest accessibility features. There are some good developers working to improve access to Google products, but it's hard to talk about progress when new features are added without any fanfare. So if you're from Google and reading this, please tell us what you're doing and how to use it. Your message will spread farther than you ever imagined. Without a message to spread, mistruths are more likely to be tossed about instead.
This extends to developer documentation as well. If the fine folks at Mozilla have to go digging through Android source code to understand how to implement basic accessibility features, then how will other less-seasoned developers manage? Generally, they'll just ignore accessibility because it's too difficult in their minds to implement. It's just like math class, you need to explain your work.
On the Eyes-free Android mailing list, the accessibility developers at Google have remained mostly quiet for the past several months. This is usually a sign of big things to come. Android 4.5 will be a major test for Google Accessibility. It's now been two years since Android 4.1 and Android's first real touch-screen navigation features. It's now time to see if Google has learned from its users and is ready to take the next steps to creating a truly accessible product.
We do our best to present accurate information on this site, but errors may occur from time to time. Please contact us with any corrections or suggestions.