How to Use Video.js – The Big Picture

This is a high-level overview of how to use Video.js to display your videos in HTML5 pages. This assumes you know some basics about video. Using Video.js is a three step process.

  1. Creating the video in the appropriate format
  2. Creating your transcript
  3. Inserting the correct HTML code in the page

Creating the video in the appropriate format

One of the strengths of HTML5 is the ability to add video right in the Web page without any additional software, like QuickTime or Flash. However, due to licensing conflicts and turf wars, not all browsers support all video formats. Fortunately, with HTML5 video you can provide the video in multiple formats and the browser will choose the one it can play.

To get this to work there are a few things to keep in mind. At a minimum, you should provide your video as an MP4 file. This will work in all browsers except for Firefox. Unless you want your Firefox users to have to use the Video.js Flash fallback option, you should also include the video as a WebM file.

If you need help converting your video from one format into another, use the Miro Video Converter.

Creating the captions

To create captions the first thing you need to do is create a plain-text version of what is said in the video. If the video is short, like 5 minutes long, this is easy to do in a text editor. If it is longer, you might want to pay someone to create a transcript for you. The IT Accessibility Office can provide you with a list of transcription companies.

After creating the transcript you have to add in the time stamps to the file to tell when each piece of text is supposed to display on the screen. The IT Accessibility Office provides a free service to add time stamps. If you are interested, please contact the IT Accessibility Office.

Inserting the correct HTML code in the page

After you have your video file(s) and caption file, upload them to the server along with an HTML5 file with the following code embedded in it.

In the <head> section:

<link href="http://vjs.zencdn.net/4.0/video-js.css" rel="stylesheet">
<script src="http://vjs.zencdn.net/4.0/video.js"></script>

Somewhere in the <body> section:

<video id="my_vid_id" class="video-js vjs-default-skin" controls preload="auto" width="640" height="264" poster="poster.png" data-setup='{}'>
   <source src="movie.mp4" type='video/mp4' />
   <source src="movie.webm" type='video/webm' />
   <track kind="captions" src="captions.vtt" srclang="en" label="English" />
</video>

When this page is loaded in a Web browser, Video.js will

  1. check to see which of the video formats the browser natively supports
  2. load the Flash fallback video player to handle any browser/video format compatibility problems
  3. replace the browser’s default video controls with its video controls

A New Look-And-Feel

I’ve updated the blog with a new template. It’s one that we use on campus on several sites. I like this one better than my old one, and this way any accessibility work I do on it will also be transferred to several other sites around campus.

Accessible Video.js Player Available on Global Accessibility Awareness Day

Video.js is an HTML5 video player that makes embedding video in HTML5 pages very easy and gives you a consistent look-and-feel across browsers. Video.js will use the browser’s built-in ability to play video in the format the browser prefers, but it uses a standard set of user interface (UI) controls that work across browsers. It will also work on mobile devices.

One of the strengths of Video.js is how it solves one of the big problems with HTML5 video – browser support of codecs. If you’ve ever worked with HTML5 video you know you usually have to provide your video in at least two formats to ensure that it will work in all browsers – MP4 and WebM. With Video.js, you can still provide the video in multiple formats and it will use the browser’s built-in ability to play that video in the preferred format, however, if a browser does not support one of the formats you have provided, Video.js will use a Flash fall-back player to play the video while still using its standard set of UI controls.

Now one of the other great strengths of Video.js is the player controls are accessible. Video.js is an open source project and I’ve been working with the community to make the player more accessible. With this new version of Video.js released today, which is coincidentally Global Accessibility Awareness Day, the player is now accessible to keyboard-only users, screen reader users, and voice-interface users. The specific accessibility improvements are:

  • The UI controls are keyboard accessible, including seeing the visual focus on the controls.
  • The UI controls are named properly and the status of each is updated by the appropriate ARIA attributes, so screen reader users can fully interact with the player. It works with JAWS, NVDA, and VoiceOver. The accessible controls include the following:
    • Play/Pause Button
    • Progress Bar
    • Time Elapsed
    • Time Remaining
    • Fullscreen Toggle
    • Volume Slider
    • Mute Button
    • Caption Button
  • The tab order for the UI elements has been altered to make the flow more logical.
  • The font size of the caption track is now enlarged when viewing the video in full screen mode.

Making Video.js accessible is a work in progress and there are still a few things that need to be done.

  1. The tab order probably needs to be adjusted some more to make it more logical. To alter it any more that what it is right now will take some significant modifications to the CSS and markup.
  2. Full keyboard accessibility needs to be more robust. Because the player controls show and hide themselves based on if the mouse is hovering over the player or not, this causes problems for keyboard users. The solution isn’t as simple as just adding in the appropriate onfocus and onblur events, because the video player is made up of multiple UI elements, and bubbling up the focus through multiple elements takes some extra testing to make sure it works in all browsers. However, currently there is a little of what I call “accessibility by accident.” If you start playing the video by using the keyboard, the mouse never enters or exits the video area, thus never triggering the show/hide event. That makes the player controls stay visible all the time. The downside is that the controls cover the bottom portion of the video, albeit in a semi-transparent manner. There are, however, a couple of edge cases where the controls do end up hiding themselves. Coming up with a more robust solution will solve this problem. Playing the video in full screen mode seems to also eliminate the problematic edge cases.
  3. Currently the caption button is acting as a menu with a sub-menu. To get it to truly act the way a submenu is supposed to will require some more significant modifications to the code.
  4. The time progress bar currently increments and decrements by 5 seconds when using the left and right arrow keys. This is better than what it was before, when it only changed by 1 second. I’m not sure what the ideal amount is and am open to suggestions.
  5. Support for technologies like Dragon Naturally Speaking need to be more robust. You can currently navigate the entire UI with Dragon, but it could be made more elegant.

If users, particularly keyboard-only users or screen reader users, have difficulty interacting with the player, viewing it in full screen mode might correct some of the problems.

There was no long term plan to release this today on Global Accessibility Awareness Day – it was just serendipitous.

2013 Global Accessibility Awareness Day Challenge Results

Congratulations to all of the Web site owners who participated in NC State’s First Annual Global Accessibility Awareness Day Challenge! As a group we corrected 194,232 accessibility errors across many NC State Web sites over the past two weeks. Here is a summary of some of what we fixed.

  • 96,747 link related problems
  • 23,702 alternative text instance
  • 15,546 heading structure problems
  • 14,586 code validation errors
  • 9,963 keyboard access problems
  • 5,930 form element problems
  • 4,749 table problems
  • 1,792 language definition problems

For the full listing with the final standings, visit the NC State Global Accessibility Awareness Day Website Challenge page.
In the next blog post, I’ll discuss some lessons learned from this contest.

NC State Global Accessibility Awareness Day Website Challenge

Are you ready to put your website up to the challenge? Over the next two weeks, ending on May 9, one way NC State will be celebrating Global Accessibility Awareness Day is by having NC State’s First Annual Global Accessibility Awareness Day Website Challenge.

The Challenge is to see how many accessibility errors you can correct in your Web site by May 9. The results are based on the percentage of errors you correct according to the Accessibility Scan being done by the IT Accessibility office. Your starting point will be the first scan that was completed on your site. The final point will be the most recent scan you submit before May 9. To participate here is what you need to do.

  1. See if your site has already been scanned. If it has, on the same page request access to the data. If it has not, also on the same page submit your site for its initial scan.
  2. Between now and May 9, correct as many of the accessibility problems as you can. Only the “accessibility” errors in the report will count towards this contest.
  3. Before 11:59 PM on May 8, be sure to submit a rescan request for your site.

On May 9 fabulous accolades and digital blingage will be bestowed upon the sites in each size category that have shown the most improvement. The three size categories are 1-99 pages, 100-999 pages, and more than 1000 pages. There will be additional recognitions for sites that have corrected at least 25%, 50%, and 75% of their accessibility errors.

If you would like some additional help with your scan you can

  1. Come to the Interpreting Your Accessibility Scan Report Lunch and Learn on Monday, April 29 from 12:00-1:00 in ITTC Lab 1A in the D.H. Hill Library.
  2. Come to the Co-Working Day on May 3 from 9:00 AM – 5:00 PM in The Avent Ferry Technology Center, room 106, to ask Greg Kraus, the University IT Accessibility Coordinator, any questions you would like and get expert advice.
  3. Consult the Accessibility Handbook for techniques to create accessible Web pages.

Global Accessibility Awareness Day, which is celebrated on May 9, is a community-driven effort whose goal is to dedicate one day to raising the profile of and introducing the topic of digital (web, software, mobile app/device etc.) accessibility and people with different disabilities to the broadest audience possible.

Testing Web Page Readability

I’ve developed a readability bookmarklet that lets you easily analyze a Web page or a portion of a Web page to see how readable the text is. This tool is available to anyone in the world, not just NC State University. To get it, first visit the readability bookmakrlet page. After adding the bookmarklet to your browser, go visit a Web page, select some text, and run the bookmarklet. If you want to analyze the whole page, do not select any text before activating the bookmarklet.

The results are based on several tests that examine the number of words, sentences, and syllables to estimate how easily the text can be read. Most of these tests estimate what grade level is required to comprehend the text. The recommended levels are based on the WCAG 2 Level AAA conformance for making content readable and understandable which says that text which cannot be understood with a 9th grade education (15-16 years old) must also be presented in an alternative way.

One of the features of this tool is the ability to analyze only part of a Web page instead of an entire Web page. A lot of the text on Web pages exists as menu items or other short blurbs. If you analyze a page in its entirety, these bits of text can skew the results of a readability test because they will change the ratios of things like words per sentence.

Download Google Doc as Microsoft Office Document Tool Updated

The Download Google Doc as Microsoft Office Document Tool has been updated to handle a couple of problems.

  • The script is now delivered via SSL. Previously the script was served from a non-SSL server. Google Docs are delivered as SSL pages and some browsers do not allow insecure content (this script) to interact with secure content.
  • The script now handles spreadsheet conversion better. Sometimes the URLs for the spreadsheets have different formats depending on how they are shared and how you get to them. The script now accounts for these differences.

Because of the change to SSL, if you previously added this bookmarklet to your browser, you will need to delete the original one and add the new version of the Download Google Doc as Microsoft Office Document tool.

Previous announcement about the Google Doc Download Tool.

Getting My Google Doc in a More Accessible Format

For some assistive technology users, Google Docs still has significant hurdles that prevent them from fully using the product. Often the user just wants the document in a more accessible format, like a Microsoft Office document. Within Google Docs, you can download a Document to Microsoft Word, a Spreadsheet to Microsoft Excel, and a Presentation to Microsoft PowerPoint. It is even possible for some assistive technology users to do this themselves. If the user is able to access the File menu they can usually navigate to the “Download as” option. Once they download the file they can interact with it in a more accessible interface, like Microsoft Office.

Even though the user can sometimes do this themselves, it often requires numerous tabs and key presses, and sometimes a little hunting, to find this functionality. In order to make it simpler for assistive technology users to quickly download any Google Doc as a Microsoft Office document, we are releasing the Download Google Doc Tool.

http://go.ncsu.edu/download-google-doc

This tool is a bookmarklet that will work in any browser. If you have never heard of a bookmarklet, just think of it as a regular bookmark you are adding to your browser. The technical difference between the two is a bookmark is a URL that points to a Web site while a bookmarklet is a collection of JavaScript code. In the end, your browser treats bookmarks and bookmarklets exactly the same. They can both be added to your regular browser bookmarks or bookmark toolbars, either by using the context menu to add the link as a bookmark or dragging it to your bookmark menu or toolbar.

To use it you open a Google Doc in your browser window, click on the bookmarklet in your browser and the document will be downloaded as the corresponding Microsoft Office document. That’s it.

It is important to note that this tool does not add any extra accessibility information into the document, like adding alternative text for images or inserting headings where none existed previously. It simply is a convenience tool for quickly converting a Google Doc into its corresponding Microsoft Office format. It is also important to note that any changes you make to the Microsoft Office document will not be passed back to the online Google Doc. This is a one-way information highway.

So Why Make This Tool At All?

It is becoming increasingly popular for groups to publish Google Docs online for others to read. Sometimes they are notes from meetings or information they want to share and easily update. If Google Documents is the chosen platform for publishing this content, in order to make it accessible to everyone, the content creator would need to also provide a link to the same file as a Microsoft Office document, and then share that link with everyone so that an assistive technology user will be able to access it. This raises lots of logistical issues like

  • Where do you store the Office document?
  • Where do you publish the link to it?
  • Will you remember to update the Microsoft Office document each time you update the Google Doc?

By providing this tool, it allows the user to instantly convert a Google Document into a Microsoft Office document without having to have access to a link to an alternative format that the content creator maintains.

It also needs to be noted that this tool is not supported by Google and it comes as is without any guarantees. If later changes in Google Docs prevents this tool from working, efforts will be made to restore functionality if possible. For any questions about this tool please contact it-access@ncsu.edu.

Google Apps Accessibility Guidelines

Google Apps are increasingly being used on campus in a multitude of ways, from academics to staff meetings. Because of the ease of publishing content from Google Apps to the Web and sharing it with others, care must be taken to ensure that all people are able to fully participate in online university activities. There are a number of accessibility problems with Google Apps. These guidelines will help you understand what needs to be considered when using Google Apps in various contexts.

http://google.ncsu.edu/accessibility/google-apps-accessibility

Please note that these guidelines in no way inhibit you from using Google Apps @ NC State for your own personal work. The limitations and considerations begin when you share your content with others.

Questions about accessibility and the use of Google Apps should be directed to Greg Kraus, University IT Accessibility Coordinator, at greg_kraus@ncsu.edu.

FAQs for ICT Accessiblity Regulation

The IT Accessibility Committee, in conjunction with the Office of Information Technology and the Office of General Counsel, has released a set of frequently asked questions for the revised Information and Communication Technology (ICT) Accessibility Regulation. These FAQs give guidance in understanding accessibility laws and policies, accessible content, procurement practices, and emerging technologies. Questions about the FAQs should be directed to Greg Kraus, University IT Accessibility Coordinator, at greg_kraus@ncsu.edu.