The Pain of Accessible PDFs from MS Word on Mac – Test Results

I get asked this question every so often, so I did some tests to see what the current landscape is in terms of creating accessible PDFs from MS Word on Mac. I was primarily looking at the workflow for adding headings and alternative text into Word and having those features show up in a PDF generated from Word. There are other accessibility issues to contend with as well, but for this evaluation I was looking at these two very important aspects of PDF accessibility which have a high occurrence.

Anyone who has worked in this space already knows that PDF accessibility support from MS Word on Mac is non-existent, however, can we improve things by introducing LibreOffice or OpenOffice into the workflow? First, I’m going to assume that most Mac users who are already using MS Word are not going to abandon it and start using LibreOffice or OpenOffice as their principal authoring tool. However, we might be able to convince these users to at least generate the PDF from one of these two products, at least for accessibility considerations.

So what did I test?

  • Authoring a document in MS Word 2011 on Mac, using headings and providing text in both the title and description fields
  • Converting it to a PDF using LibreOffice 4.2.3.3 for Mac
  • Converting it to a PDF using OpenOffice 4.0.1 for Mac

Here is what I found.

LibreOffice

LibreOffice recognized all of the headings and image titles and descriptions entered into Word. When exporting it as a tagged PDF, the headings are preserved, but only the image titles are passed through as the alternate text for the images

OpenOffice

OpenOffice recognized the headings but did not import the image titles or descriptions. Therefore, when you create a PDF from OpenOffice, none of the images have alternative text. If you manually enter image titles and descriptions directly in OpenOffice, then the titles are passed through to the PDF alternative text.

The Word for Windows Conundrum

If that was the end of the story then we could tell users to simply use LibreOffice to convert their MS Word files to accessible PDFs on Mac. The problem is if you take that same Word document to Word 2013 for Windows and create an accessible PDF straight from Word 2013, it’s the image descriptions that get passed through to the PDF as the alternative text. This might not be a problem if you aren’t sharing documents between Mac and Windows users who both might be creating PDFs from it. However, I would really like to be able to give one piece of advice to all of my MS Word users.

Recommendations

Here is the best advice I can give MS Word for Mac users. If you are the only person who will be generating PDFs from a Word file and you know the PDF will always be generated from a Mac…

  1. enter the alternative text as the image title
  2. open your Word document in LibreOffice
  3. export a tagged PDF from LibreOffice (tagged export should be selected by default)

If this file will be shared between Windows and Mac users, I would decide on a standard way of denoting your alternative text – either as a title or a description, and then based on that, decide which platform you will use to generate the PDF.

  • alternative text in the description = Windows
  • alternative text in the title = Mac, using LibreOffice

I hesitate to recommend putting the alternative text in both fields because that just seems like bad form and seems like it might cause problems in the future. It would also be cumbersome for someone with a screen reader actually editing or reading the document in MS Word itself.

Again, this analysis only looked at heading and alternative text preservation in the Word to PDF workflow. You might have to consider other accessibility issues too like tables, document reading order for floating text boxes, and document language. Ensuring heading and alternative text are preserved just saves a lot of work in any additional accessibility retrofitting that might have to occur in Adobe Acrobat.

 

 

Incredible Accessible Modal Window, Version 2

Just take me to the demo of the Incredible Accessible Modal Window, Version 2.

Rich Caloggero at MIT and I were talking recently about screen reader support in the original Incredible Accessible Modal Window and he pointed out to me that different screen readers handle virtual cursor support differently in the modal window. This sent me further down the rabbit hole of screen reader support with ARIA and what exactly is going on.

The Situation

I hesitate to call this the “problem” because I’m not sure what the real problem is yet. I’m sure it is some combination of differing interpretations of specifications, technological limitations of different screen readers, design decisions, the needs of the user, and bugs. The situation is that all screen readers, except for NVDA, can use their virtual cursor to navigate a role=”dialog”.

The root of the situation is that a role=”dialog” should be treated as an application window. This fundamentally changes the way a screen reader user interacts with an object because the default way the user is to now interact with the application window is by using the application’s defined navigation methods. In other words, the screen reader user is not supposed to use their virtual cursor.

It is clear from the spec that when a screen reader encounters an object with an application-type role, it should stop capturing keyboard events and let them pass to the application. This in essence turns off the virtual cursor for JAWS and NVDA. What is not clear is if it is permissible for the user to optionally re-enable their virtual cursor within an application. JAWS says yes and NVDA says no. (Just a note, JAWS actually requires the user to manually enable application mode instead of doing it for them automatically.)

This has real world implications. Typically for a role=”dialog” the user would use their Tab key to navigate between focusable elements and read the page that way. But what if there is text within the modal dialog that is not associated with a focusable element in the modal dialog?

The spec says that “if coded in an accessible manner, all text will be semantically associated with focusable elements.” I think this is easily achievable in many situations, however, I question if it is practical in all situations. In my experience a lot of content is being crammed into some modal dialogs, sometimes more content than can always be neatly associated with focusable elements. In theory, with enough tabindex=”0” and aria-labelledby attributes you could associate everything with a focusable element, but I wonder if this would get too unwieldy in some situations.

There is always the question of if developers should be cramming so much information into modal dialogs, but that’s another discussion for another day. I’m simply trying to deal with the fact that people are putting so much content in there.

A further real world implication of the ability or inability to use the virtual cursor is if you allow users to use their virtual cursor in some situations in an application region, are there situations where that could end up hurting the user? For example, it’s not hard for me to imagine a modal dialog where it would be useful to allow the user the ability to navigate with their virtual cursor, however, if a screen reader user is interacting with Google Docs, which is in essence one large role=”application”, the results can be disastrous. Are there certain application contexts where we would want the user to be able to enable their virtual cursor and other contexts where we would want to prevent it? That just made things a lot more complicated.

Just to complicate things more, VoiceOver and ChromeVox don’t really have a concept, to my knowledge, of turning a virtual cursor on and off. That means they can browse the contents of the role=”dialog” any way they want, and there is not much I as a developer can do about it.

A Partial Solution?

One of the things Rich and I learned in this adventure is if you include a role=”document” inside of the role=”dialog”, then NVDA allows you to use the virtual cursor. This now gives all screen reader users the ability to fully navigate all of the contents.

Is this a good thing? Based on the reality of how people are actually implementing modal dialogs, I think it is. Some modal dialogs are in essence becoming miniature versions of Web pages, not just simple forms or messages. Given the alternative of having to programmatically shoehorn every piece of text into a relationship with a focusable element, I think this is a good option for some pages.

I still think that people should revisit the overall usability of their application which might require such complex modal dialogs in the first place. There are probably better ways to design the user interactions.

So is NVDA wrong in their implementation of not allowing virtual browsing in an application? I don’t think so. That is the intention behind the application region. Is JAWS wrong for allowing the use of the virtual cursor in an application? Probably not, because it is always good to give screen reader users the option of trying to save themselves from bad coding and using the virtual cursor might be the only way they can do that. However, my guess is that using the virtual cursor in something designed to be an application will usually lead to more confusion than assistance.

VoiceOver Improvements

One additional improvement – in the original version of the Incredible Accessible Modal Window there was a shim in place for VoiceOver users so that the aria-labelledby attribute would be automatically announced. VoiceOver in OS X 10.9 fixes this problem so the shim is not needed any more.

The Incredible Accessible Modal Dialog

Update: Read about version 2 of this demonstration.

Just take me to the working model

Let me start by saying I originally created my demonstration page as an internal-only training document over a year ago. I left it untouched for all of that time until recently when it got mentioned on Twitter and started getting some attention. I was then shocked and humbled to find out that it was the number one result for a Google search on “accessible modal window”. After discovering that, I felt morally obliged to make the presentation of it semi-respectable, so I went back and updated it to reflect changes in screen reader support and created this more in-depth post.

So what is a modal dialog, or as they are also called, a modal window? A modal dialog is a window that pops up over top of another window where you must first interact with the new window before you can go back to the previous window. In Web pages, a modal dialog usually is a smaller window that almost looks embedded inside of the larger window, and the larger window is behind it and usually grayed out some. Additionally, users will not be able to click on the larger window to accidentally interact with it. If you’re still not sure what it is, it might be easier to just see it in action.

So What’s the Big Deal?

So what’s the big deal with modal dialogs? The problem is that they work great when you interact with your computer using a mouse, but if you only use a keyboard or if you use a screen reader, they can often be traps of insanity in terms of trying to figure out what is going on. When designing a modal window, there is usually only one main requirement in most implementations – the modal window should be the only thing the user can interact with on the current Web page.

There might be some other tweaks, like the ability to move or resize the modal window, or automatically setting the keyboard focus to a certain element in the modal window, but the fundamental principle is that the user can only interact with that single object within the Web page.

The Case of the Forgotten Keyboard-Only User

A lot of Web design is very mouse-centric and the fact that there are people that only use a keyboard for interacting with a computer is forgotten. Most modal dialogs are designed to keep mouse users from clicking on the parts of the page that are “off limits”, but sometimes designers don’t think of people using the Tab key to navigate to different focusable elements. If the keyboard focus isn’t trapped inside of the modal dialog, the user can begin interacting with the page behind the modal dialog. At this point, it’s anyone’s guess what is going to happen. I’ve seen cases like this where, even though the modal dialog was open, I was able to fully interact with the main window and execute functions, and I’ve seen cases where I could navigate the main window but when I tried to interact with elements, nothing would actually happen. Regardless of what happens, it’s usually difficult, if not impossible, for the user to find their way back to the modal dialog in order to dismiss it.
Lesson #1: Trap the keyboard focus within the modal window.

The Case of the Forgotten Screen Reader User

If you haven’t worked with screen readers before you might not know exactly how they interact with Web pages. Most people are used to having two different cursors on their screen that let them interact with the page – a mouse cursor and a keyboard cursor. Screen readers have a third type of “cursor” called the virtual cursor. (Different screen readers call it different things, but they all basically do the same thing.) This is separate from the mouse cursor and the keyboard cursor. You can think of the virtual cursor almost like a “eye” cursor – it is positioned where the user wants to read on the page. You will never see the virtual cursor on the page like you do the keyboard cursor. It’s an invisible pointer that allows the screen reader user to read text on the Web page. As they read down the page, the virtual cursor moves with them.

So what do you do with a modal dialog? You can keep the mouse cursor trapped in the modal window, and you can keep the keyboard focus trapped in there, but how do you trap the virtual cursor? In other words, how do you prevent someone from even reading the portions of the page that they should not be able to interact with? It’s like asking how do you keep a sighted mouse user from reading the text in that grayed out area?

It’s an important question because if you want your user to only be interacting with the content in the modal window, you don’t want them off trying to read other parts of the page that aren’t even active. In a case like this, the screen reader user might have a modal dialog popped up in front of them, but they could be happily reading along on another part of the page, oblivious to the modal dialog and any information it is presenting or asking them for. Or worse, they could be reading in the modal window and their virtual cursor could “escape” the modal window and start reading the page behind the modal window and the user wouldn’t have any idea what was going on. Fortunately, screen reader software has recently added support for dealing with this situation.
Lesson #2: Trap the virtual cursor within the modal window.

Designing and Accessible Modal Window

When you look at the ARIA spec, which defines ways to describe rich UI elements accessibly, you find something that says role=”dialog”, so the thought is maybe if I apply that ARIA attribute to my modal window all of my problems will be solved. Unfortunately, no. ARIA attributes do not perform magic.

a greyhound dog dressed in an AT-AT costume from Star Wars

<dog role=”AT-AT”></dog> does not turn this dog into an AT-AT. Photo Credit

You can apply the role=”dialog” but you are still responsible for implementing all of the functionality to make it into an actual modal dialog.

So what all goes into designing an accessible modal dialog? The W3C outlines what is needed to make a modal dialog accessible. There are some finer details, but the basics are as follows.

  • The first focusable item in the modal dialog should receive the keyboard focus.
  • The window behind the modal dialog should not be allowed to be clicked on
  • The modal dialog must trap the keyboard focus inside the modal dialog so the user can’t accidentally interact with the window behind the modal dialog.
    • When the user is on the last focusable item and presses Tab, the user should be taken to the first focusable item in the modal dialog.
    • When the user is on the first  focusable item and presses Shift-Tab, the user should be taken to the last focusable item in the modal dialog.
  • The position of the keyboard focus before the modal window opens must be saved, and the focus must be restored to this location after the modal dialog closes.

Implementing an Accessible Modal Dialog

The Basic Page Structure

First off, I’m lazy, and I like to find easy ways of doing things. To make things easy to manage I broke the page into three sections: the main page, the modal dialog, and the overlay that prevents users from clicking on the parent window but still lets them partially see it.

<div id="mainPage”></div>
<div id="modal" role="dialog"></div>
<div id="modalOverlay" tabindex="-1"></div>

With each of the modal areas I defined some CSS.

#modal {
  width:50%;
  margin-left:auto;
  margin-right:auto;
  padding: 5px;
  border: thin #000 solid;
  background-color:#fff;
  z-index:3; /* places the modal on top of everything */
  position:fixed;
  top:25%;
  left:25%;
  display:none;
}

#modalOverlay {
  width:100%;
  height:100%;
  z-index:2; /* places the modalOverlay between the main page and the modal dialog */
  background-color:#000;
  opacity:0.5;
  position:fixed;
  top:0;
  left:0;
  display:none;
  margin:0;
  padding:0;
}

When the user presses a button to make the modal window pop up, I simply switch the display:none property to display:block, and when the modal gets closed I switch them back. Note, I don’t apply display:none to the main part of the document, just the modal window. If I applied it to the main page, when the modal dialog opens, the user wouldn’t be able to see the grayed out portion of the page. There would just be a blank page behind the modal window. While this would actually help out some users like screen reader users, the visual change would be quite jarring to many users. Nonetheless, the standard way to present these windows is to gray out the main window and not to make it disappear, so I’ll solve that problem instead of solving problems that don’t actually exist.

Setting and Trapping the Keyboard Focus

The next thing I want to do is set the keyboard focus to the first focusable item in the modal dialog. That’s easy enough to do, but there are a couple of other things I need to do along the way. I need to remember where the user was before the modal dialog was opened so I can take them back there. If you are a mouse user this might not seem like a big deal, but if you depend on your keyboard alone for navigation, this is a huge deal. Imagine having to retab through dozens of links every time a modal dialog closes just to get back to where you were before.

Like I said earlier, I’m lazy, so enter jQuery.

// save current focus
focusedElementBeforeModal = jQuery(':focus');

When I close the modal dialog, I can set the user back to where they came from with the following.

// set focus back to element that had it before the modal was opened
focusedElementBeforeModal.focus();

Now the next challenge is to set the keyboard focus on the first focusable element and to also keep the keyboard focus within the bounds of the modal dialog. I’m actually going to solve both problems at the same time. Thinking through the problem you realize that you need to know what all focusable elements are in the modal window and then you need to direct the user to each next and previous element each time they press Tab or Shift-Tab. At this point images of tabindex might be dancing through your head. It’s definitely easy to implement, but please wake up from that nightmare.

Again, I’m lazy, so I don’t want to have to figure out each time I create a new modal window what elements are focusable. I want something more robust so that I don’t have to recalculate all of my tabindex values each time I update the contents of a modal dialog. And what if the contents of the modal dialog dynamically change. What then?

The W3C provides some pseudo code for how to handle the logic of all of this. I basically implemented that algorithm, except instead of prepopulating a list of focusable elements, I use jQuery to determine what elements within a modal are focusable. I recalculate this every time the user presses Tab or Shift-Tab. Every time the Tab key is pressed I execute the following.

var focusableElementsString ="a[href], area[href], input:not([disabled]), select:not([disabled]), textarea:not([disabled]), button:not([disabled]), iframe, object, embed, *[tabindex], *[contenteditable]";

function trapTabKey(obj,evt) {

  // if tab or shift-tab pressed
  if ( evt.which == 9 ) {

    // get list of all children elements in given object
    var o = obj.find('*');

    // get list of focusable items
    var focusableItems;
    focusableItems = o.filter(focusableElementsString).filter(':visible')

    // get currently focused item
    var focusedItem;
    focusedItem = jQuery(':focus');

    // get the number of focusable items
    var numberOfFocusableItems;
    numberOfFocusableItems = focusableItems.length

    // get the index of the currently focused item
    var focusedItemIndex;
    focusedItemIndex = focusableItems.index(focusedItem);

    if (evt.shiftKey) {
      //back tab
      // if focused on first item and user preses back-tab, go to the last focusable item
      if(focusedItemIndex==0){
        focusableItems.get(numberOfFocusableItems-1).focus();
        evt.preventDefault();
      }

    } else {
      //forward tab
      // if focused on the last item and user preses tab, go to the first focusable item
      if(focusedItemIndex==numberOfFocusableItems-1){
        focusableItems.get(0).focus();
        evt.preventDefault();
      }
    }
  }
}

To set the initial focus for when the modal first opens I simply call the following.

function setInitialFocusModal(obj){
  // get list of all children elements in given object
  var o = obj.find('*');

  // set focus to first focusable item
  var focusableItems;
  focusableItems = o.filter(focusableElementsString).filter(':visible').first().focus();
}

Keeping Screen Readers from Reading What They Shouldn’t Be Reading

Now I need to figure out how to keep the screen reader users from reading the portions of the page behind the modal dialog so they don’t get confused about what is happening on the page. This problem is actually the exact opposite of what we are usually trying to solve for screen reader users. Usually we are wanting to make certain text available only to screen reader users and not to other users, not hide something from screen reader users.

Until about the last year or two, the technique of hiding content from screen reader users, yet still letting others see the content was not possible in most screen readers, however, most major screen readers now support an ARIA attribute called aria-hidden which does just that. When aria-hidden=”true” that tells screen readers that they are not allowed to read or interact with that content even if it’s visible on the main page.

To implement this I simply modify my main page structure slightly to the following.

<div id="mainPage” aria-hidden="false"></div>
<div id="modal" role="dialog" aria-hidden="true"></div>
<div id="modalOverlay" tabindex="-1"></div>

In this initial state the main page can be accessed by screen readers but the modal dialog cannot. When I want to make the modal dialog visible I simply toggle the properties.

<div id="mainPage” aria-hidden="true"></div>
<div id="modal" role="dialog" aria-hidden="false"></div>
<div id="modalOverlay" tabindex="-1"></div>

Now the main page is still visible, albeit through the modal overlay, but it is hidden from screen reader users so there is no risk of screen reader users accidentally interacting with the main page while the modal dialog is open. Note, I don’t use aria-hidden on the modal overlay because the overlay doesn’t actually contain any content to interact with. It’s just a layer that changes the appearance of the page and prevents clicks on the main page.

Letting Screen Reader Users Know What Just Happened

Now I can control where all of my users are on my page, but how do I let screen reader users know that the modal dialog just opened up and what the dialog is asking for? The ARIA spec for the dialog role specifies that modal dialogs should have a dialog label either through aria-label or aria-labelledby attributes. This way, when the modal dialog receives focus the screen reader will simply announce the label for the dialog. Here is how I modified my page structure.

<div id="modal" aria-hidden="true" aria-labelledby="modalTitle modalDescription" role="dialog">
  <div id="modalDescription">Beginning of dialog window. It begins with a heading 1 called &quot;Registration Form&quot;. Escape will cancel and close the window. This form does not collect any actual information.</div>
  <h1 id="modalTitle">Registration Form</h1>
   …
</div>

In this description I’ve done a couple of things.

  1. I’ve described the structure of the modal dialog so screen reader users know how to interact with it
  2. I’ve given a brief description of what this dialog does, or in this case, doesn’t do

Building a Safety Net

So why do I bother saying that the modal dialog starts with a heading 1? There are older versions of screen readers, and some current versions, like Orca, that do not support the aria-hidden attribute, so it’s quite possible that some of my screen reader users might still be able to “escape” my modal window and start trying to interact with the main window. By telling them this information, if they do get lost somewhere else in the page, they know they can now use their heading navigation keys to quickly get back to the modal dialog.

ARIA is Great, But Performance May Vary

ARIA is a relatively new specification and browsers and screen readers are still in the process of implementing support for all of its features. This brings us to our first major problem. VoiceOver and Safari on OS X does not yet behave as the ARIA spec says it should in regards to modal dialog labels. The specification and implementation guide say that the focus should be placed on the first focusable element in a modal dialog when it opens. When that happens, the screen reader will announce to the user that they are in a dialog window and the subsequent aria-label or aria-labelled by element will be read. This works in the latest versions of JAWS, NVDA, and ChromeVox, however, the label is not announced in VoiceOver.

What I discovered though is if I make the modal dialog itself focusable (tabindex=”-1”) and then set the initial focus to the modal dialog instead of the first focusable item, then VoiceOver announces the label just fine. This isn’t really the standard way to do it so I don’t want all of my screen reader users, and non-screen reader users for that matter, to have to deal with the focus being set to the dialog itself instead of the actual first focusable item.

To solve the problem I just do a quick check to see which browser you are using, and if it’s Safari, I set the focus to the dialog instead.

var o = obj.find('*');

if(usingSafari()){
  // set a tabIndex of -1 to the modal window itself so we can set the focus on it
  jQuery('#modal').attr('tabindex','-1');

  // set the focus to the modal window itself
  obj.focus();
} else {
  // set the focus to the first keyboard focusable item
  o.filter(focusableElementsString).filter(':visible').first().focus();
}

Responding To Other Keyboard Events

The last thing I do is add support for other key presses, like Escape and Enter. Escape simply closes the dialog, like clicking the “Cancel” button, and Enter submits the form.

Putting it All Together

This tutorial shows the fundamentals that need to be considered when building an accessible modal dialog. This implementation is still fairly basic and utilitarian. To make it more robust you might want to make it so you can move or resize the modal dialog. You can view a working model of this demonstration along with all of the source code.

Accessibility and Code Development – 10 Thoughts from a MeetUp

I recently attended a MeetUp of usability specialists involved in agile development who discussed how usability can be successfully incorporated into the agile process. I don’t pretend to be an expert in either user experience testing or in agile development, but I think many of the topics that were discussed can be translated into accessibility and code development in general. I’m going to take some of the salient points from the discussion and present them as some accessibility and development tips. I present these more as thoughts than definitive how-to guides.

1. Deal with the high level problems first and fill in the pieces later.

This tends to work better in an agile environment where you are iterating very often and know a new release is only a few weeks away. In terms of accessibility specifically, no matter what development style you are using, just because you can’t fix all of the problems right now doesn’t mean you shouldn’t fix some of the problems. (Wow, that was a triple negative. In other words, do something rather than nothing.)

2. Establishing standards and guidelines upfront is important.

Developers have standards for acceptable coding styles and practices and if that style isn’t used the code isn’t accepted. Extending this to the way UI elements are presented is a natural progression. Be sure to talk about how accessibility will be incorporated into the overall process and have people on board with it. Don’t shoehorn accessibility in as an afterthought.

3. Having developers witness people encountering accessibility problems is priceless.

Sometimes you will find that the developer has fixed the bug before you can even get back to your desk to discuss what went wrong.

4. Make sure the team understands its not just your idea.

These needs come from users’ experience and there is data to back it up.

5. Value and trust people.

Value the role everyone on the team plays and recognize that without their contribution, the whole process will fail. You work with professionals who are good at what they do.

6. Embrace the toxic person.

Instead of ignoring the person who is grumbling and sowing dissent, give them what they want – make them the center of attention. Invite that person to be involved in some usability testing with people with disabilities. They will either join the party or dig their own grave all on their own.

7. Having an accessible design is pointless if it can’t be implemented.

I don’t mean that there are a slew of Web apps out there that are too complex to even attempt to make accessible. What I mean is make sure there is communication between you and the developer to make sure you both understand what is being asked. Sometimes when we express a need from an accessibility perspective there are certain technical implications that will mean massive amounts of work that we as the non-developer might not be aware of. If there is reluctance on the developer’s part to implement a certain feature find out why. It might be a misunderstanding. It might be a part of a feature that is not necessary but would just be nice to have and it’s OK to leave out part of it.

8. Find that one developer you can recruit to your purposes.

If you have someone on “the other side” working for you, it’s much easier to get your message across.

9. Work in the language that developers work in.

Don’t write design specs. Write code.

10. Questions to think about while working with developers.

  • How do you get people to respect everyone else’s role in the process? As an accessibility specialist, you are already in the business of building bridges. How can you take that skill set to help less-than-functional teams learn to work more effectively?
  • How do you make it so you aren’t the reason that a delivery date was missed? Is all of your input received as something which gums up the process? How can you make your input flow more fluidly in their development process?

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

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.

Creating Accessible PDFs: Microsoft Publisher

This is the first in a series of posts on ways you can, and cannot, create accessible PDFs from various applications.

Microsoft Publisher is most commonly used as an authoring tool for creating print materials like fliers, handouts, and brochures. A common practice is to also create a PDF version of the brochure to either email to people or post online. So is it possible to create a fully accessible PDF using only Microsoft Publisher? In short, sometimes, but only for simple layouts and it will still take you a fair amount of work. If you just want the moral of the story without all the gory details, avoid using Microsoft Publisher to create PDFs because it is too difficult to do, unless the document has an extremely simple layout and structure. Here are the issues to contend with.

Alternative Text

As with most Microsoft products, any image in Publisher can have alternative text added to it. You need to simply select the image and chose “Format Picture” from the context menu. Then in the “Web” tab enter the alternative text.

The problem occurs when you want to mark an image as a decorative image and you just want to make the alternative text an empty string so screen readers will ignore it. The problem is you cannot set the alternative text to an empty string in Publisher. You basically have two choices

  1. leave the alternative text field blank
  2. put a single space in the alternative text field

The problem is different screen readers handle these cases differently. If you leave the alternative text blank, JAWS reads each of the images while NVDA ignores them. If you make the alternative text a single space, JAWS ignores the images but NVDA reads each image. VoiceOver ignores all alt text, whether it is empty, a single space, or has real text in it.

In this case there is no best solution for how to add alternative text for decorative images directly from within Publisher. The best solution involves going into Adobe Acrobat and explicitly setting the image as a background object.

Reading Order

This is the most tedious issue to deal with in Publisher. Screen readers will read the objects on the screen in the order they were created. Technically, screen readers read the objects in the order they appear in the stack (z-index). Screen readers will read items furthest back in the stack first and items closest to the front last. Armed with this knowledge you will now need to go through your entire document and systematically select each item individually and choose to “Bring to front”, starting with the first item that should be read first and ending with the last item to be read. The only way to check that you got it right is to open the document in Adobe Acrobat and either use the built-in “Read Out Loud” feature or use a screen reader. Of course, if you missed anything you will have to repeat the previous process almost in its entirety.

Unless your document has a very basic layout this fact alone should deter you from using Publisher to create accessible PDFs.

Semantic Structure

By default, all text entered in Publisher is rendered as paragraph elements in the PDF. In order to add semantic structure to your document, in Publisher you will need to explicitly use styles like “heading” when you have a heading on the page. Even when you add a “Heading” from the “Page Parts” menu in Publisher it is still rendered as a paragraph element in the PDF, so you must go through and explicitly assign the correct style.

If you use other objects like tables there is no way to make them accessible directly within Publisher. That work will have to be done directly in Adobe Acrobat.

In order to check if you have properly assigned headings to all of the necessary elements you will need to either

  1. manually click through each element in Publisher to double check which style is assigned to the element.
  2. open the document in Adobe Acrobat and inspect the reading order and object properties
  3. use a screen reader to ensure each heading is being rendered as a heading

Exporting the PDF

When exporting a Publisher document as a PDF you MUST choose “Save as” from the file menu and choose the file format of “PDF.” In the “Options” you must then check “Document structure tags for accessibility”. If you simply choose “Save as Adobe PDF” from the file menu it will not create an accessible PDF.

Summary

You should probably avoid using Publisher to create accessible PDFs unless your Publisher document has a very simple layout and does not use decorative images. You will end up doing a lot of extra work with a tool set that is not designed to build in and test for accessibility, or you will need to correct errors directly in Adobe Acrobat. If you do make changes directly in Acrobat, if you ever re-export the PDF from Publisher, you will need to repeat all of the manual changes you made in Adobe Acrobat.

How To Display Read-Only (or Non-Editable) Parts of a Form

How To Display Read-Only (or Non-Editable) Parts of a Form

How should you display the parts of a form that are read-only? There are three main implementations that I have seen, and unfortunately the accessible version is the one I’ve seen used the least. The problem arises from the the way the screen readers interact with forms in Web pages. When a screen reader encounters a form it switches into “forms mode.” In this mode the screen reader will only read the form input elements and any corresponding labels. If additional plain text is inserted between two form elements, the screen reader will skip over the plain text and go directly to the next form input field.

Take the following three examples. In each of these examples the First Name, Last Name, and Email Address fields should be editable, but the Login ID should be non-editable and read-only.

Correct Implementation

Making the “Login ID” field and the data “jdoe” both form elements allows the proper semantic meaning to be defined, and also allows for screen reader users to more easily read this information. Using the readonly attribute prevents users from changing any of the information. Additionally, CSS can be used to make it clear that the input element is not editable. In this example the border is removed from the input field. When a screen reader user encounters this form their screen reader will switch to “forms mode” and they will very easily be able to read the “Login ID” information because it will be part of the form. Screen reader users will also know that the field is read only.

<form name="form1" method="post" action="">
 <p>
   <label for="first">First Name</label>
   <input type="text" name="first" id="first" value="John">
 </p>
 <p>
   <label for="last">Last Name</label>
   <input type="text" name="last" id="last" value="Doe">
 </p>
 <p>
   <label for="login">Login ID</label>
   <input name="login" type="text" id="login" readonly value="jdoe" style="border:none;">
 </p>
 <p>
   <label for="email">Email Address</label>
   <input name="email" type="text" id="email" value="jdoe@internet.com">
 </p>
</form>




Incorrect Implementation #1 – Unattached Form Labels

Making the “Login ID” field a label element and the data “jdoe” plain text is a popular implementation because the “Login ID” is still visually “labelling” something on the page. The problem is that label elements can only provide semantic meaning for a form input element. Without explicitly declaring that relationship, the user will have to intuit the relationship between “Login ID” and “jdoe”. Additionally, when a screen reader user interacts with this form, they will most likely not even know this text exists because when in “forms mode”, a screen reader will not read this text. The screen reader user would have to explicitly change their reading mode and go looking for information that was missed the first time they read through the page.

<form name="form2" method="post" action="">
 <p>
   <label for="first2">First Name</label>
   <input type="text" name="first2" id="first2" value="John">
 </p>
 <p>
   <label for="last2">Last Name</label>
   <input type="text" name="last2" id="last2" value="Doe">
 </p>
 <p>
 <label for="login2">Login ID</label>
 jdoe </p>
 <p>
   <label for="email2">Email Address</label>
   <input name="email2" type="text" id="email2" value="jdoe@internet.com">
 </p>
</form>



jdoe



Incorrect Implementation #2 – Not Using Form Elements

This implementation treats both the “Login ID” field and the data “jdoe” as plain text. This is a popular implementation because the user should not be able to edit the information, so why should it be a form element at all? Visually this works, but semantically and for screen reader users it is problematic. The information should be part of the form, but it should be treated as read-only. When a screen reader user interacts with this form as it is now, they will most likely not even know this text exists because when in “forms mode”, a screen reader will not read this text. The screen reader user would have to explicitly change their reading mode and go looking for information that was missed the first time they read through the page.

<form name="form3" method="post" action="">
  <p>
    <label for="first3">First Name</label>
    <input type="text" name="first3" id="first3" value="John">
  </p>
  <p>
    <label for="last3">Last Name</label>
    <input type="text" name="last3" id="last3" value="Doe">
  </p>
  <p>Login ID<br />jdoe</p>
  <p>
    <label for="email3">Email Address</label>
    <input name="email3" type="text" id="email3" value="jdoe@internet.com">
  </p>
</form>


Login ID
jdoe



Accessible “Read More” Links

When there are a bunch of “read more” links on a page, it is usually fairly obvious from visual cues what the “read more” refers to. However, when screen reader users encounter a bunch of “read more” links on a page, it is not always obvious which part of the page each “read more” link refers to. A simple solution is to use a bit more descriptive text than simply “read more” and use CSS to hide the additional text. In this example the following code is used.

<p><a href="#">Read more <span class="offscreen">About NC State</span></a></p>

This is the CSS rule.

.offscreen {
position:absolute;
left:-999px;
width:1px;
height:1px;
top:auto;
}

Notes:

  • The off-screen text needs to be included in the <a> as well, otherwise it won’t be read correctly by screen readers.
  • You cannot use the CSS rule display:none or visibility:hidden as that will make the content invisible to screen reader users.
  • This code is not unique to me. It is the compilation of different examples I have seen in various accessibility forum posts. I just want to put this example in writing for others.

Here is an example of this code technique.

What about using the title attribute of a link? Screen readers usually never read that text so it’s not a good idea to depend on that as a solution. Ian Pouncey has a good write up about why not to use the title attribute.

Using ARIA Landmarks – A Demonstration

What are ARIA Landmarks?

ARIA landmarks are attributes you add to elements to create semantically defined sections of a page that allow users of assistive technologies to navigate the page more easily. Think of ARIA landmarks as building a set of “skip to” links like “skip to main content”. You can add ARIA landmarks to define the following regions.

  • application
  • banner
  • complementary
  • contentinfo
  • form
  • main
  • navigation
  • search

By adding these landmarks you are in essence building a set of “skip to” links to allow users to jump to any of these sections and know what the function of each section is.

Adding ARIA Landmarks

Adding ARIA landmarks is very simple. You just need to add an attribute like role=”main” to the appropriate encompassing element. For example, if you have

<div id=”mainConent” role=”main”>…</div>

everything within the <div> will be considered the main content of the page. Similarly, if you have

<div id=”nav” role=”navigation”>…</div>

the contents of that <div> will be defined as the navigation section.

In addition to the role attribute, you can also add the aria-labelledby attribute to explicitly label each section. This is useful for a role like “complementary” where some part of the page is not considered the main point of the page but compliments the main point. A user can jump to this complementary section and know what it is about. For instance, on an “About Us” page on a school Web site that is describing the school, there might be a section off to the side that is showing live score updates from the sports teams. The score information is complementary to the main point of the page but still has important meaning. The code for something like this would look like

<div id="mainContent" role="main">
   About Us
   ....
</div>

<div id="scores" role="complementary" aria-labelledby="scoresLabel">
   <h3 id="scoresLabel">Live Scores</h3>
   ...
</div>

This way the user knows exactly what is in the complementary section. Adding ARIA landmarks will have no visual impact on your page so they are an easy way to add more accessibility to your Web page.

Does This Mean I Don’t Have to Provide a Separate “Skip To” Link?

ARIA Landmarks are fairly well supported in screen readers so most users will be able to take advantage of them. There are some older screen readers that don’t support them and some users with newer screen readers might not know how to use this feature. The most helpful data we have on this comes from WebAIM’s screen reader survey. While it shows a 42% increase in awareness of ARIA landmarks over the past year, only 40% of people indicate they use them, and a full 30% still don’t know that the functionality event exists. That being said, if you only provide ARIA landmarks you will be meeting the letter of the law in terms of providing a way to easily skip repetitive navigation, but not providing the traditional “skip to” links will probably make your site more difficult for some screen reader users to navigate. As with almost everything on the Web, we live in the in-between times where newer and better technologies are out there but adoption isn’t high enough to make it the de facto standard. For now, I would still include the “skip to” links in addition to ARIA landmarks.

A Working Model of ARIA Landmarks

Here is a working model of ARIA landmarks with explanations for how to use the various roles.

More Information

W3c ARIA Authoring Practices

Another blog post about using ARIA Landmarks

HTML5 Section Elements and ARIA Landmarks