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.
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?
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 (hillaryclinton.com) 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).
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:
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.
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.