Making America Great by Doing Good

Donald Trump wants to "Make America Great Again". I doubt that anyone can dispute that this is a noble goal. But what does "great" mean when referring to a country or nation state?

I'm afraid Donald Trump's definition of "great" doesn't mesh with mine and I wouldn't want to be associated with his vision, so unfortunately I won't be wearing one of those cool red hats.

Red cap with text on the front: Make America Great Again

For Trump, a "great" America is a country that's white, wealthy, and male-dominated (although served by stereotypically beautiful females), aggressively asserting its dominance over the rest of the world. In Trump's America, "great" is measured exclusively by wealth and power.

For me, a Great America is a country that is respected worldwide for its innovation. We grow by creating, not destroying.

A Great America is diverse, a "melting pot", that effectively utilizes the diverse ideas that come from a rich variety of perspectives and experiences. The growth and success that comes from this diversity is shared among all participants, not just a few white men at the top.

A Great America is compassionate. It's a country that has attained enlightenment but uses that to help others attain enlightenment as well. A Great America understands that it is greatest if the entire world is great. Anytime you have one great country and lots of other not-so-great countries, you have a recipe for resentment, conflict, and terrorism.

So, how can we make America great again?

Continue reading

Accessible Language Pickers: a11y meets i18n/l10n

Helena Zubkow and Mike Herchel published a great article recently comparing the U.S. Presidential candidates websites on accessibility. That article points out several features (both good and bad) that affect accessibility for some visitors to their sites. There's one feature in particular that I want to expand upon since it's been on my mind lately. Hillary Clinton's site ( is available in both English and Spanish, and there's a link in the main menu that takes users from one site to the other. (It's no surprise that Donald Trump doesn't have a Spanish version since he's the guy who wants to build un muro).

Anyway, I've developed an interest in how best to code a menu of languages, as in a language picker for translated versions of a website. Hillary's site provides an interesting example of why this matters. On the main menu bar at the top of her English website, she has a link to "ES" which targets the Spanish version.

Screen shot of menu bar from Hillary's English website, which includes an ES link

Why "ES", rather than "Español"? I'd be curious to know the thinking behind that decision. In contrast, the link from the Spanish site back to the English site says "English", not just "EN".

Screen shot of menu bar from Hillary's Spanish website, which includes an English link

For screen reader users, it's important for web developers to identify the language of the page so multilingual screen readers know how to pronounce the words they're reading. Hillary's sites as a whole are coded properly: The English site has lang="en" on the <html> element, and the Spanish site has lang="es".

It's also important though to identify the language of foreign language text within the body of a web page. Otherwise screen readers will pronounce the foreign words using the rules of the main language of the page, which at best makes the screen reader sound silly, and at worse is indecipherable. In Hillary's case, if she had used Español as the link text for switching to the Spanish site, she would need to specify in the code that Español is a Spanish word, like so:

<a href="/es/" lang="es">Español</a>

Of course, she doesn't really need to do this since "ES" isn't a word at all. However, she should do it on the Spanish version, where the word "English" is not correctly tagged, therefore is pronounced by screen readers in a thick Spanish accent. Here's how it should be tagged:

<a href="/" lang="en">English</a>

What about unpronounceable languages?

This is the issue that has brought me to ponder this topic. Able Player, the accessible media player I've developed with help from the open source community, supports subtitles in any language, and users can browse a list of available languages and choose the one they need. On the DO-IT Video website, which is running Able Player, some of our videos have been translated into Chinese (simplified and traditional), French, Greek, Indonesian, Japanese, Korean, Portuguese, Spanish, and Vietnamese as part of the DO-IT Translation Project. When subtitles are available for any of these languages, they appear in a menu that pops up when users click the CC button.

To me, it seems reasonable to list the languages in their native language rather than in English since the reader might be unable to read English. (Would you English readers recognize "English" if it appeared as "イングレス" on a Japanese website?)

As for Hillary's using "ES", that's the two-character ISO 639-1 code for Español—all major languages have one. But how many web users know their ISO 639-1 code? Maybe all Spanish-speaking people understand that an "ES" link is intended for them, but in case there are a few who don't, I think spelling it out makes more sense.

But what if a language picker includes multiple languages, including some not supported by users' screen readers? If we list the languages in their native language rather than English (e.g., 日本語) how will screen readers handle this?

Continue reading

Links from IAAP Accessible Media Player Webinar

On Tuesday May 31, Ken Petri of Ohio State University and I are giving a webinar titled What Makes a Video Player Accessible?, hosted by the International Association of Accessibility Professionals (IAAP).

If you're reading this before the event, I hope you can make it. Follow the above link to register.

If you're reading this after the event, I hope you were able to attend. And if not, I'm sorry you missed it.

In either case, our webinar slide deck includes a number of links to a variety of resources related to media player accessibility. In order to make those easy to access I've extracted them all here:

My Post-CSUN Comparison of Web Accessibility Checkers

Two weeks have now passed since the 2016 CSUN Conference, and I'm still inspired by many of the bright ideas that were generated from sessions, conversations, tweets, etc. and considering how to apply them.

I gave two sessions at CSUN, What's New With Able Player? and Web Accessibility 101 with Accessible University 3.0. In the second of these session, I modeled how to use our Accessible University (AU) demo site in an interactive training session on web accessibility. The AU site consists of three core pages: A "before" page, with at least 18 accessibility problems, an "after" page, with those problems fixed, and an intermediary page that describes the problems and solutions.

One of the sessions I intended to attend but was locked out due to a capacity crowd was Luis Garcia's Automated Testing Tool Showdown. Fortunately Luis shared his slide deck. After looking over his findings, I found myself wondering how the various accessibility checkers would do with a web page like AU's "before" page, the page with at least 18 known accessibility problems. I decided to find out.

Continue reading

YouTube Captions Revisited: Various APIs and Services

I did some work over the weekend to improve Able Player's support for YouTube videos. The changes will be available in the next major release of Able Player, which I'll be unveiling in my session at CSUN.

The biggest challenge with playing YouTube videos in a third-party player is getting access to captions. I described the issues in a previous blog post, Handling Captions via the YouTube Player API. The biggest problem with the YouTube IFrame API, which is used to embed a YouTube player in a web page, is that the API exposes captions and subtitles only after the onAPIChange event is fired, which doesn't happen until the video starts playing. This makes it very difficult to construct the player, as we don't know whether to include a CC button, and whether clicking on that button should display a pop-up menu for selecting available languages.

The workaround I used in Able Player was to autostart the video and play it for just long enough to trigger the onApiChange event, then reset the video back to the start and collect the caption data that had been exposed during the brief moment of playback. This is a clumsy hack, and I've been looking for a better way.

Continue reading