Tag Archives: Accessibility

Introducing an Accessible HTML5 Video Player


Video on the web has come a long way over the years. From applets to RealPlayer (who remembers that?) to QuickTime to Flash, and now the HTML Video element.

For the last few years, many HTML5 video implementations have included Flash fallbacks, especially for Microsoft’s Internet Explorer (IE). But HTML5 video in IE has been supported since version 9. It’s time to end this era and provide web-based video without plugins.

The player and its goals

Customizing an HTML video player is still required for a fully functional and accessible experience across browsers and platforms. Browsers’ native controls are still not accessible as a whole, nor is rendering captions.

Although browser support isn’t quite there yet, the new open-source Accessible HTML5 Video Player takes one big step closer to a fully standards-based and accessible video player. The project takes advantage of HTML5 and avoids dependencies and plugins.

The goals of this project were to:

  • Take advantage of the latest web technology; use HTML5 for the video, controls, and captions.
  • Reduce code weight (the CSS is 5k and JS is about 18k, not minimized!).
  • Make fully accessible especially to keyboard and screen reader users.
  • Support captions (uses WebVTT, the HTML5 standard).
Screen shot of the Accessible HTML5 Video Player

Screen shot of the Accessible HTML5 Video Player

Solid foundation

Browser support for HTML5 video is very good (only IE8 doesn’t support it). So the code for the Accessible HTML5 Video Player starts with that; the markup consists of only the Video element and a few divs for the controls, captions, and a container.

The video element remains as-is if rendered a mobile or tablet device since native functionality is well-supported. This also occurs when JavaScript is unavailable on a desktop browser.

If rendered on a modern desktop browser with JavaScript, the experience is enhanced with custom controls, captions (if provided), and a slick design. This is the main use-case for the project. (IE8 and IE9 have fallbacks).

The controls

As mentioned above, accessibility of video controls in browsers is still lacking, so they must be customized. Careful attention was given to the semantics. The Restart, Rewind, Play, and Forward buttons use the button element. The Mute and Captions controls are checkbox inputs because they each have two states, selected and not selected.

In addition to the Video element, other HTML5 features can go mainstream and work great in the video controls. Cases in point, the range input (slider) and the progress element. The volume setting is implemented with an input element with a type of range since it is “representing a number, but with the caveat that the exact value is not important”. The video progress indicator is implemented with a progress element as it “represents the completion progress of a task”.

Addressing quirks

Although web standards is used as much as possible, there are many nuances to tackle including caption support and rendering of HTML5 elements.

WebVTT captions on the latest iOS and Android operating systems are supported which is a huge win for everyone. But on desktop browsers, support is still quite inconsistent (Chrome proved to be the best). Although WebVTT support is claimed by the latest versions of mainstream browsers, work-arounds had to be implemented which was disappointing, particularly in IE11, Safari7, and Firefox31. This is especially strange because the WebVTT implementation worked well in Safari 6 and Firefox 30.

To make the design of the HTML5 elements consistent across browsers, browser-specific CSS selectors were used in certain cases. For example, the progress bar required a webkit selector (webkit-progress-bar) to ensure the design was rendered more accurately. The range input had the most variance; between that and the design, custom styling was required for webkit, mozilla, and IE10 and higher. IE’s rendering is considerably different and was most difficult to address.

Give it a go

Feel free to visit the Accessible HTML5 Video Player on GitHub and clone or fork the code. In the JavaScript initialization, several options are provided but only the first is required (the ID of the container). There are no dependencies. We are open to suggestions and pull requests.

Looking forward

Hopefully in the near future, the nuances experienced in this project will go away and thus make the code even more simple, light, and robust. This mostly boils down to better support of WebVTT more consistent rendering of HTML5 controls. There are also plans to enhance the player further, including adding support for multiple caption files and support for audio description.


It’s time we make video on the web quick and easy to implement with accessibility in mind, not plugins. The Accessible HTML5 Video Player project helps make this happen. HTML5 video is well on it’s way to being the global solution for web-based video, but at least for now, not without several browser support and rendering issues remaining.

Get a Sneak Peek into PayPal Accessibility Showcase

By and

As a technology-driven company, PayPal strives to promote the best development and design practices across our organization. One of the disciplines we have been especially proactive in fostering is accessibility. Making our products accessible to as many people as possible makes sense, not only from a business point of view, but also supports our goals to deliver high quality products our customers love.

The PayPal Accessibility Team works closely with product teams to make sure they are delivering the best accessible user experiences possible.

While the need for creating accessible products is understood by product managers, designers, and developers, most of them do not have experience working with people with disabilities that use our products.

The PayPal Accessibility Team created the Accessibility Showcase where employees get a chance to experience, first-hand, what it is like to use our products by simulating the experience of people with disabilities. Some of the simulations visitors experience  are:

  • Low vision conditions: Visitors wear goggles that are hard to see through and then share their experience and the strategies they would use to remedy a problem. As visitors navigate a site, they better understand the importance of design choices that affect readability such as size, and color contrast for content, and the coding practices that enable resizing and zoom in the browser and assistive technology such as screen enlargers.
  • Experience of a blind user: We turn off the monitor and ask participants to navigate a Web page using a screen reader. This experience reinforces the importance of the non-visual metadata and page structure such as labels for form fields, alt attributes for images, and the use of HTML headings. Since a blind user does not use a mouse, this simulation also emphasizes the importance of keyboard navigation principles
  • Limited use of arms:, Participants are asked to type their name using their nose as an input device. This simulation shows that technology should be agnostic of the input device the user may be relying on to interact with the computer.

Since the official launch of the Accessibility Showcase as part of the Global Accessibility Awareness Day, on May 9, 2013, over 170 PayPal designers, developers and product managers have experienced first-hand what it feels like to browse the Internet as a user with a visual or physical disability. Surveys and visitors’ feedback indicate the experience has changed the way they think about accessibility and the importance of creating products that work for everyone.

Check out the video below to learn more about the Accessibility Showcase and how it works!


Bootstrap accessibility plugin: making the popular web development framework better


Bootstrap Accessibility Plugin is an extension for the Bootstrap 3 web development framework that makes many of the components of this library accessible for keyboard and screen reader users. Today we are launching this plugin on Github under the BSD license. We hope that this extension will make it very simple for website developers who use Bootstrap 3 components to provide great user experience for as many users as possible.

If you develop websites or web applications using Bootstrap components and want it to be accessible with a minimal development effort, this accessibility plugin may be the perfect solution. By adding the JavaScript plugin in your Bootstrapped HTML pages, you extend the stock components with an additional mark-up and events without modifying the original Bootstrap code. In doing so, you make those widgets keyboard-navigable and introduce the compatibility with screen reader software used by people who are visually impaired.


This plugin provides enhancements to the Bootstrap 3 components in two areas: keyboard navigation and screen reader compatibility. There are also minor changes to improve color contrast in alert messages.

Keyboard Navigation

For some widgets, like tab panel, carousel, drop-down menu, etc, the onKeyDown event is employed in various places in order to make the desktop-style keyboard navigation possible. This enables someone who does not or cannot use the mouse navigate those components using tab and arrow keys. To further enhance the seamless navigation for keyboard users the plugin manages keyboard focus wherever appropriate.

Compatibility With Screen Readers

Once the plugin is loaded into your page, it will search for any available Bootstrap components and, if found, append the necessary ARIA roles and states to provide the enhanced semantics to those widgets. This is primarily useful for screen readers. Without ARIA mark-up it is difficult for this technology to express the meaning of dynamic elements, such as modeless alerts, tab panels, popup menus, carousels, etc, to users who cannot see the screen.

Color Contrast

We found that the foreground-to-background color contrast ratio for a Bootstrap alert message is too low. To make it easier for users to read, the color contrast has been increased.

Please see the README file for the list of components and more implementation details.

Try it out

If you want to use the Bootstrap Accessibility Plugin in your project, simply include the JavaScript file right after Bootstrap’s JavaScript file. The exact instructions of how to do this can be found in the README.

Also, play around with the live demo of the Bootstrap Accessibility Plugin. For better effect, you may want to get hold of one of the popular screen readers if you would like to immerse yourself into the screen reader user experience. Seeing and hearing how “accessified” widgets work in this demo will help you verify whether the plugin is installed correctly on your website.

We look forward to improvements and suggestions from the community. To learn more about how Bootstrap Accessibility Plugin works, check out our detailed documentation.

To stay in touch with us, follow @PayPalInclusive and submit issues on GitHub.

The Bootstrap Accessibility Plugin was primarily authored by Nawaz Khan ( @mpnkhan ) from the PayPal Accessibility Team. The README file provides the full list of contributors.


A sweet toggle switch


In today’s world of front-end web development, it’s becoming increasingly complex to create custom interface elements. A common scenario is when your design team has required a non-standard web-based form component. This time it’s a toggle switch which seems to be becoming more popular in the web design world.


Winging the development of a toggle switch for a prototype is one thing, but for production a gracefully degradable and fully accessible version is required. Let’s walk through the strategy and code for developing a sweet toggle switch. We’ll create a control where the user can select either a “checking” or “savings” account.

Coding Strategy

As we should with any front-end project, let’s start with HTML semantics. Because the switch is essentially selecting between two options, let’s use two radio inputs each of course with a label. Using basic form elements will also make submitting the form simple and not require any scripting. At first glance, it may seem that a single checkbox element may work; but two labels are required, and the form data to be passed may need to be more than a simple Boolean value. The radio inputs and labels are contained in a div and then within a form. The labels are styled to create the toggle switch effect. Paragraph text provides the instructional text which tells the user what the toggle switch is for.

Marking It Up

Below is an example of the basic HTML. The checked attribute is optional; if removed, the toggle switch renders as expected on page load (neither option selected). The labels will be floated left in the next step, so a “clearfix” class is added to the container. The radio inputs are hidden visually using an “accessAid” class (which uses the clipping technique to hide rather than off-screen).

  <p>Select the type of account:</p>
  <div class="toggle-btn-group clearfix">
    <input type="radio" id="checking" name="accountType" value="checking" class="accessAid" checked="checked" />
    <label for="checking">Checking</label>
    <input type="radio" id="savings" name="accountType" value="savings" class="accessAid" />
    <label for="savings">Savings</label>

For accessibility and structure, sets of radio or checkbox elements many times require a fieldset and legend elements or an ARIA substitute. But in this case, it’s not needed because the labels by themselves are clear. Web accessibility experts at WebAIM say “basic radio buttons (such as male/female for gender) that make sense from their labels alone do not require fieldset and legend.” If a use case requires the added clarification of the controls, use the aria-describedby attribute. Here’s an example:

<p id="p1">Select the type of account:</p>
  <div class="toggle-btn-group clearfix">
  <input type="radio" id="checking" name="accountType" value="checking" class="accessAid" checked="checked" aria-describedby="p1" />


The CSS of course will transform the appearance of the radios to a toggle switch; well, more accurately, the radio inputs are visually hidden and their labels create the visual effect.

.toggle-btn-group label {
  padding: .5em;
  display: inline-block;
  width: 8em;
  float: left;
  text-align: center;
  cursor: pointer;
  color: #000;
  background-color: #ddd;
  border: #999 2px solid;

Rounded corners are added to create the pill-like shape.

.toggle-btn-group label:first-of-type {
  border-top-left-radius: .5em;
  border-bottom-left-radius: .5em;
.toggle-btn-group label:last-of-type {
  border-top-right-radius: .5em;
  border-bottom-right-radius: .5em;

With some fun CSS selectors, the selected/checked state of the label is created through the “checked” pseudo class of the associated radio element (the adjacent sibling). The focus state is normally indicated by the radio inputs; but since they are visually hidden, we return that functionality.

.toggle-btn-group input[type="radio"]:checked+label {
  background-color: #00a1ff;
  border: #000 2px solid;
  color: #000;
.toggle-btn-group input[type="radio"]:focus+label {
  outline: 2px #999 dotted;

And then the default hover and focus states.

.toggle-btn-group label:hover,
.toggle-btn-group label:focus {
  background-color: #ccc;
  border: #000 2px solid;
  color: #000;

Falling Back and IE8

In modern browsers, JavaScript is not required so the toggle switch will function fine when JavaScript is not available. If CSS is not available for any reason, the toggle switch simple renders as the basic radio inputs with the associated text labels.

Internet Explorer versions 8 and below do not support the checked CSS pseudo-class selector (input[type="radio"]:checked+label). To make it work, JavaScript is required. A listener on the labels can be implemented to add and remove another class which gives the same styling.

Putting it all together

You can view an example of this toggle switch here. Feel free to model the code and share with your peers.


Native web components are always the best way to go. But when it’s not possible due to design requirements, there’s usually a good way to solve while keeping degradation and accessibility in mind. In the toggle switch example, we started with fundamental radio inputs within a form and enhanced the design with CSS.

Thanks to fellow PayPals Victor Tsaran and Dereck Quock for input in this article.

Interactive elements within a grid layout


Often times, the best way to begin marking up HTML content is to put aside the visual design and concentrate on the semantics. A good example of this is when a design first appears to be a data table but actually includes content other than data.

The Challenge

In the following wireframe design, transaction records are displayed in a table-like format, a grid. Each row is designed to be a link (the entire row) and has a grey hover/focus effect. Data includes a date, description, and dollar amount. There is also a menu button in each of the records; clicking it opens a drop down menu.

Screenshot of layout grid

At first glance, the design appears to be a data table. But the row link and the menu button within a data table create fundamental markup and accessibility issues. (If the design called for traditional text links instead of the row link and menu button, a data table is a solid option.) A layout table would create similar issues as a data table but we’re not going to go there in the name of Web Standards.

First Approaches

Definition List

One idea for marking up this content is to use a description list. For each row, a unique identifier (like a record number) would be the DT and would be visually hidden. The rest of the row content would be contained in DD elements. Example:

  <dt>Record 1</dt>
  <dd>[menu button]</dd>

But like the table, the row link would certainly be challenging, and would add to the complexity of the extensive CSS already required to make this fit the visual design. Also, the menu button doesn’t fit the semantic meaning of a DD (description data).


Another approach is to use divs and spans with the ARIA grid role along with the associated row and gridcell roles. In this technique, “the grid construct describes relationships between data such that it may be used for different presentations”. In other words, a more flexible data table-like structure can be developed. Example:

<div role="grid">
  <div role="row">
    <a href="#">
      <span role="gridcell" class="date">date</span>
      <span role="gridcell" class="desc">description</span>
      <span role="gridcell" class="price">amount</span>
    <span role="gridcell" class="menu">[menu button]</span>

To give context to screen reader users, it may be a good idea to add the aria-labelledby property and the rowheader and columnheader roles.

The main problem with this technique is support. ARIA is still relatively new, and inconsistent results are found among the different screen readers (JAWS, NVDA, VoiceOver). There is also a lack of semantic elements, and the abundance of ARIA creates code complexity (especially to those not yet familiar with ARIA).

A Solution

Let’s take a step back and simplify. There are three main piece to the puzzle: a unique identifier (not in visual design), some linked text, and a menu button.

One feasible solution is to use:

  • a heading as the unique identifier for each record (like the DT in the example above), 
  • an anchor element containing spans for the link (like the ARIA example above), 
  • a div to contain the menu button.

Divs are also used for CSS hooks in order to create the grid/table-like design. Example:

<div class="table">
  <div class="tableRow">
    <h3>Record 1</h3>
    <div class="tableRowInner">
      <a href="foo.html">
        <span class="tableColumn date">date</span>
        <span class="tableColumn desc">description</span>
        <span class="tableColumn price">amount</span>
    <div>[menu button]</div>

For the title of the grid content, let’s use a heading, say an H2 in this case. For proper heading levels, each record will then require an H3 heading. This is great for not only page structure but also helps screen readers users for context and navigation. The menu button is separated in its own Div but still falls under the record’s H3 heading.

Using CSS we create the grid design. Here’s an excerpt:

.tableRow .tableColumn {
  display: block;
  float: left;
  color: #333;
.tableRow .tableRowInner > a {
  display: block;
  float: left;
  padding: .75rem 0;
  text-decoration: none;
  width: 118%;
.tableRowInner {
  float: left;
  width: 85%;
.tableRow:last-child .tableRowInner {
  padding-bottom: 1.5em;
.tableRow .tableColumn.date {
  width: 25%;
.tableRow .tableColumn.desc {
  width: 40%;
.tableRow .tableColumn.price {
  text-align: right;
  width: 25%;

With some CSS magic, we can position the menu button to appear within the row (check the widths of the row and anchor). And there we have it; a grid layout with interactive elements which is accessible. It also a robust solution; it functions well without JavaScript or without CSS.

Check out the working example

Final Words

Developing ideal solutions can be difficult in these days of complex web apps, stringent design requirements, and increasing accessibility concerns. The solution in this article isn’t perfect (could use less divs and spans and more semantic elements), but it certainly does the job. Do you have any suggestions for this issue?