Android accessibility

Recent conversations around my circles have led me into thinking about Android accessibility both native code, web, and packaged web applications. I’m using this post as a note taking scheme for myself and anyone who may stumble upon it. I’ll update this post as I find more.

Native code

“Latest Android Accessibility Features for Smartphones and Tablets”
A youtube video, which you should start after the 11 minute mark to avoid house keeping stuff demonstrates the accessibility interaction with TalkBack. This was filmed in 2013 and given Android fragmentation, your mileage may vary.


This appears tobe a great library to install inside a PhoneGap/Cordova App. It gives the developer some JavaScript level awareness of what accessibility features may be turned on.

My workspace


It’s always nice to be reminded of our greater goals — to know why we work. I love what I do on a daily basis, be it Drupal or ASL interpreting. Surrounding the warm purplish hue of Ubuntu’s login screen is my daughter’s drawings, a Aria Landmark cheat sheet, and a listing of Drupal hook functions.

Drupal 7 and accessibility

Drupal 7, two new system classes to improve accessibility

I just came across this article in which Drupal 7 provides two classes in the theme layer to help design for screen readers. One hides from sighted users but still allows a screen reader to access the content. The other shows the content when a user tabs over to it.

Two separate classes have been defined, one to be used for elements that cannot receive focus, and a second for elements that can receive focus. When a focusable element is styled with the .element-invisible.element-focusable class it will appear visually when it receives focus. This is to help keyboard users to not lose the system focus into an invisible black hole.

TerpTimer, Synchronized

A fellow interpreter suggested  to have multiple copies of TerpTimer synchronized so that team interpreters don’t have to depend on one device. Well, I have the start to this under development and I’m releasing today to the Android App Market.

To use it,  enable this feature through the App Prefs. If you don’t wish to use it, no worries — no data is transmitted unless you check the box and save the settings.  It is important to state I’m just testing this. No warranties or guaranties are implied or offered.

How it works (so far): When the application starts, it generates a pseudo-random device ID.  If TerpTimer has permission from the App preferences, it will transmit the following the count down, your device (or browser’s) time, and device ID to an application on Google’s AppEngine running an instance of OpenBD. To share the information, TerpTimer gives you a URL via a QR code. Your team interpreter can scan this code to see a webpage containing a near-synchronized countdown.

More updates are to come of course, but I wanted to release this to begin gathering information on how interpreters will use this in the field. As always comments are welcome!

Browser test for media types

Using the modernizer script I’m testing media capabilities in the browser with the following script:

          Video Test with Modernizr and>
	<script type="text/javascript" src="tools/getscript.php?modernizr&jqueryui"></script>

<script  type="text/javascript">

		$(function() {
			var videotest = {
				webM : false,
				ogg : false,
				h264 : false,
			if ( {
				if ( {
					videotest.webM = true;
				} else if ( {
					videotest.ogg = true;
				} else if ({
					videotest.h264 = true;

			var videoResult = 	"WebM : " + videotest.webM +
						"<br/> OGG  : " + videotest.ogg +
 h264 : " + videotest.h264;


			if (console) { console.log(videoResult) }


Chrome 8.0.552.237:

WebM : true
OGG : false
h264 : false

Firefox Beta 4.0b9:

WebM : true
OGG : false
h264 : false

IE 7.0.6002 and 8.0.7006

WebM : false
OGG : false
h264 : false