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.

(EDIT) Testing Files

 

2014 NC State Global Accessibility Awareness Day Website Challenge

The University IT Accessibility Office is once again sponsoring the NC State Global Accessibility Awareness Day Website Challenge to encourage campus website owners and designers to make accessibility improvements to their websites. Global Accessibility Awareness Day is held annually “to get people talking, thinking and learning about digital accessibility and users with different disabilities.”

The contest, which runs April 15 to May 14, includes two categories:

  • Sites that improve their overall accessibility by the greatest percentage.
  • Sites that have the ARIA roles “main” and “navigation” added to at least 80 percent of their pages.

You can view the current leader boards and see how you stack up against the competition. The winners will be announced on Global Accessibility Awareness Day, which is May 15. Sites will be considered in three size categories for determining the largest percentage of accessibility errors corrected.

  • 1000+ Pages
  • 100-999 Pages
  • 1-99 Pages

You can learn more about adding ARIA landmarks to Web pages. Also, you can come to a number of workshops and training sessions over the next month to learn how to make your Websites more accessible.

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.

2013 NC State World Usability Day Website Challenge Results

Congratulations to all of the NC State Website owners who participated in NC State’s 2013 World Usability Day Website Challenge. NC State users can view the detailed results of the challenge. Website owners competed in two areas.

  1. Which sites, in their respective size categories, could correct the largest percentage of their accessibility errors in the month leading up to World Usability Day.
  2. Which sites could include a skip to main content link on at least 80% of their pages.

Accessibility Errors Corrected

Together we corrected a total of 416,196 accessibility errors for this challenge. Since the Accessibility Scan started in March of 2013, we have collectively corrected 1,188,908 accessibility errors.

Skip to Main Content Links

During this challenge we added 2,661 new skip to main content links across our pages, with 128 of our sites now having skip to main content links on at least 80% of their pages.

Congratulations again to all of the NC State Website owners!

Color Contrast Analyzer for Chrome: Text in Images, Gradients, PDFs and More

There are several good color contrast analysis tools available. I’ve come to heavily depend upon some of them for analyzing text, but they all lack some functionality that I find I’m needing. I would like to be able to

  • analyze text within images, and
  • analyze text over top of background images or gradients.

To solve these problems I’ve developed a Chrome extension called the Color Contrast Analyzer for Chrome and it is now free to download in the Chrome Store. The tool analyzes screenshots of Web pages to determine, pixel-by-pixel, where the color contrast changes enough to pass a given WCAG 2 conformance level. You can choose to analyze a portion of a page, the visible portion of the page, or the entire webpage. The end result is a mask that shows outlines of all of the elements that pass the conformance level. This isn’t a tool to replace the functionality of all of the other color contrast tools I that I use – it is to compliment them.

Here is an example of a page that has a set of menus that does not have enough contrast along with the results the Color Contrast Analyzer produces.

screenshot of a web page where the menus do not have enough contrast but the rest of the page doesscreenshot of the results showing outlines around all of the items that have enough contrast but no outline around the menus

Because the menus are not outlined, that means they don’t have enough contrast to meet the given conformance level.

Because this tool examines a page pixel-by-pixel, it can analyze text over top of background images. Here is an example of some text placed over an image along with the results, showing the text does have sufficient contrast over top of the image.

screenshot of text written over top of an image

screenshot of the results of the analysis showing outlines of the text that meets the contrast requirements

It also works for text over gradients. This is an example of where the gradient eventually transitions to a color that does not provide enough contrast.
the text get help written in white over a color gradient that transitions from light gray to dark grayscreenshot of the analysis showing that the lower half of the text get help meets contrast requirements but the top half does not. The bottom half of the text is outlined but the top half is not.

In addition to analyzing webpages, it can analyze almost any file that Chrome can open from your local computer. This includes JPEG, PNG, and PDF files. With PDF files you will be limited to analyzing the entire visible portion of the document as opposed to using the other selection tools.

It is important to remember that the WCAG 2 color contrast ratios only apply to text. Additionally, there are certain types of text that WCAG 2 makes exemptions for, like logos, inactive form elements, purely decorative text, or incidental text in photos. For not-text items like borders and other graphical elements, while these ratios can be helpful in determining if items have enough contrast, the WCAG 2 ratios do not address these types of elements.

You can download the extension and read more instructions about using it. You can also watch the YouTube video demonstrating it.

For the record, here are the other color contrast tools I depend upon.

NC State Web Accessibility Challenge on World Usability Day

NC State University’s Office of IT Accessibility is sponsoring a Web Site Accessibility Challenge in conjunction with World Usability Day. World Usability Day brings people together “to ensure that the services and products important to life are easier to access and simpler to use.” In order to encourage Web site owners to help make our university Web pages more accessible, there are two challenges.

  1. To address general usability, which sites can correct the largest percentage of their accessibility errors.
  2. To address users who cannot use a mouse, which sites can add a specific accessibility feature to at least 80% of their Web pages – the ability to allow users to skip to the main content of a page using only a keyboard.

To learn more about your Web site’s accessibility and to see tutorials on how to improve its accessibility, view your Web Site Accessibility Scan.

To learn more about adding skip to main content links to a page, view the Skip To Main Content Link Tutorial in the Web Accessibility Handbook.

The contest winners will be determined by the last rescan submitted by 11:59PM on November 13 and the winners will be announced on November 14 on World Usability Day.

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.

Screen Readers at a Crossroads

I believe screen reading software stands at a crossroads right now. At Google I/O 2013, Google showed some of the possibilities of the ChromeVox API. What they demonstrated showed some fundamental changes in the ways screen reader software interacts with Web browsers. In this post I will discuss how I see this as a fundamental shift. I’ll discuss both the risks and rewards that I see with this model.

So what’s the big deal?

The first thing to look at is how does screen reading software typically interact with a Web page. Usually the software pulls data out of some model representing the Web page, interprets it, and presents it to the user. The data could be coming directly from the browser and the DOM or through the operating system’s accessibility layer. No matter where it gets that data, the screen reader almost always pulls the data then interprets the data itself based on the semantic markup on the page. The Web page does not usually push data to the screen reader software or tell the software how to interpret the data independent of the semantic markup. This means that when a screen reader user interacts with the page, every time they navigate somewhere or interact with an element, the screen reader is pulling information from the data source, interpreting it, and presenting it to the user.

This is why we tell people to build pages with good semantic structure and all of the other accessibility things we say. This way when a user encounters one of these elements the screen reader software can interpret what it is and present it to the user in a consistent way. So no matter what screen reader software you use, when something is coded as an <h1>, all screen reader software reports to their users that they are reading a heading level 1. Each screen reader application might speak this information differently or have slight variations for how you navigate the items, but there is always consistency within the screen reader application itself. This is good for both the screen reader user and the developer. The screen reader user can know that his heading navigation keys will always get him to a particular heading and to the next and previous headings. The developer doesn’t have to worry about how each screen reader will represent this <h1> to the user – they just know it will work. There is a standard which defines what <h1> means, and everyone agrees to follow that definition.

Now none of that has changed in ChromeVox. An <h1> is still reported as a heading level 1 to the user and the user can still navigate through the headings the same way. What has changed with the ChromeVox API is now the Web page has the ability to modify the way that an <h1> gets interpreted by the screen reading software. In fact, the ChromeVox API allows the Web page to reinterpret ANY semantic markup or even ANY action the screen reader user takes the way the page sees fit. The fundamental shift is from the screen reading software pulling and interpreting the data to the Web application interpreting and pushing the data to the screen reading software.

An example

To see this in action you can either watch the following YouTube videos demonstrating this or you can read the demonstration page using two different screen reading programs, ChromeVox and any other screen reader.

With this example, please keep in mind that I am not an expert on the ChromeVox API. This example is what I cobbled together after watching a presentation at Google I/O and seeing some sample code on their slides. There is not a well documented public API to do all of this yet to my knowledge.

In this example there is a simple page with four headings, some text, and an image. If you use any screen reader software other than ChromeVox the page will behave just as you expect it to. The user can browse the page linearly or jump around from heading to heading.

Page read with JAWS and Internet Explorer

If you read this page with ChromeVox you will have a very different experience because I have used the ChromeVox API to change the way certain semantic elements are presented to the user, and I’ve even overridden the natural flow of the page so unexpected things happen when you browse the page. The two items I have changed are:

  1. When using the commands to go to the next and previous headings, instead of relying on ChromeVox to announce the heading text and then say “heading level 1”, I have told ChromeVox to say “You have jumped to the next heading which is called <insert heading text>.“ I have redefined the built-in behavior of ChromeVox when it encounters headings when navigating to the next and previous headings.
  2. When browsing to the next and previous heading, when you try to go between the third and fourth headings, ChromeVox will tell you “You are not ready for the next heading yet. First you must spend time frolicking with the penguins. After that you may go to the next heading. Image. Penguins frolicking.” I have redefined ChromeVox navigation commands to do whatever I want, independent of the semantic structure of the page.

Page read with ChromeVox and Chrome

It seems silly, but there are serious implications

Yes, that example is rather sophomoric, but it proves a point. Despite using <h1> elements, I was able to present those elements to the user in a very non-standard way. Also, despite using a navigation technique that is only supposed to allow me to jump from heading to heading, I was able to force the screen reader user to the image, even though they requested the next or previous heading. I am not doing any keyboard trapping to do this. It’s all done with the ChromeVox API so ChromeVox will behave differently than expected.

So why would they do this?

Does Google have evil intentions with this to trick users? I don’t think so. Google is actually doing some pretty cool things with this. For instance, this is how they are adding additional support for MathML. ChromeVox now has some native support for MathML, but it doesn’t fully implement it. What if you are trying to express math in a way that ChromeVox does not support yet? As a Web page developer, you have the ability to write some JavaScript to access the ChromeVox API that tells ChromeVox to interpret certain MathML symbols differently than it would natively.

If you aren’t so mathematically inclined there are other benefits too. If you do have a user interface that is tremendously complex and doesn’t lend itself to navigation by semantic markup, you could make the screen reader do and say whatever you want based on the user’s input. There’s now no reason to tie yourself to semantic navigation or even ARIA attributes for trying to convey richer UI elements. You can in essence write your own screen reader for each application you develop, and just use ChromeVox as the TTS engine to actually speak it.

Is this a bad thing?

Not always, but it definitely opens the door to abuse. Most Web pages and applications can be written accessibly using semantic markup with ARIA attributes, and ChromeVox can still handle those things just fine. In fact, I bet Google will still encourage you to use standards in your Web page. What this opens the door to is creating ChromeVox-only solutions for certain Web pages and applications.

This page best viewed with Internet Explorer 6…

Are we really ready to go back to this, or is Google, as they claim, advancing Web accessibility with features that have never been possible before?

On the positive side, this has the potential to let developers create Web pages and applications accessible to a level that has not been possible before. However, will ARIA not suffice to meet most if not all of our needs?

On the negative side, creating custom user interfaces for one particular group of users means, in essence, creating two sets of code. Will all of the new features in the non-screen reader UI be translated instantly over to the screen reader UI?

Well I heard that screen reader users like it when …

How many times have we heard misinformed developers start a justification for a particular implementation with these words? With great power comes great responsibility. I know Google does not intend for developers to use this API in obnoxious ways, but it’s out there now, and the reality is it will get misused some. Do we want to trust the same developers who just now figured out that “spacer graphic” is never appropriate alt text to be able to define Web page navigation in a way that is “more superior” than just using good heading structure?

So where do we go from here?

If ChromeVox had a bigger market share, this conversation would probably be a little different. ChromeVox does have one advantage over other screen readers though. It is by far the most accessible way to interact with Google Apps. Are we experiencing a market shift? Is Google trying to redefine the way screen reader software should work with Web pages? Is Google promoting it’s own ecosystem as the superior answer to their competitors? It worked for Apple, iTunes, and iOS devices. Are we at that early stage where the benefits of the ecosystem are not yet fully realized? When big players with lots of money start playing, they like to change the rules of the game to give themselves the advantage. That’s the free market and it’s seldom ever a tidy process.

How will the other screen reader vendors respond? Will developers start utilizing this API in ways that make ChromeVox the necessary choice for their application? Is this just JAWS scripts now being implemented by Web developers? Does this fundamentally break the Web? Is this all just a tempest in a teapot?

I believe Google is in it to win it. They don’t see this as a research project or a neat idea. They believe they are advancing the state of Web accessibility. Do we agree with that?

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?

The Gamification of Accessibility, Round 1: Lessons Learned

NC State held its first ever Global Accessibility Awareness Day Challenge to see which campus Web sites could correct the largest number of accessibility errors. The challenge was based upon automated scans of Web sites which evaluated for both Section 508 and WCAG 2 conformance. The winners were the sites which corrected the highest percentage of errors. The challenge was just one part of the larger accessibility scanning system we have set up.

I could write up a lot about the system that I’ve created to do this, and I’ll have more details about the mechanics of the larger system, but I wanted to share some lessons learned about one of the more novel aspects about this system – the game aspect. What happens when you introduce gaming aspects into accessibility?

For this project, the game aspects I introduced were the following.

  • the ability to see where you rank anonymously among all other sites on campus
  • guides for how to improve your site
  • the ability to quickly see how changes you make impact your accessibility ranking
  • awards and recognition, not just for the “winners” in each category, but for all sites which show significant improvement

1. Sometimes it’s all about the game…friendly competition is a motivator

In fact, some people will fix things without you even having to ask them. If I had approached a group on campus and said, “You have 28,000 accessibility errors spread across 8000 pages and I need you to correct them,” let’s face it, I would have gotten no traction. Perhaps they feel that if they’ve had 28,000 errors for this long, why do they need to fix them now? Perhaps they had other pressing matters they had to deal with. Who knows why.

Instead, I sent out an email that in essence said, “We are having a contest to see who can correct the greatest percentage of accessibility errors in their site over the next 2 weeks.” When they went to view their current standing they saw that they were ranked as the 371st most accessible site out of 385 and ranked in the bottom 10% in all categories for all sites on campus. At the end of two weeks the site in question had corrected about 27,500 errors, ranked as the 40th most accessible site out of 385, and was in the top 5% in all categories for all sites on campus. I didn’t have to ask for this group to do anything – they just did it themselves. They ended up doing quite well in the contest. After the contest was over I saw one of the directors which oversees this group who had only learned about the contest after it was over and I told him that I was co-opting his employees for my own purposes.

2. But sometimes it’s all about the beer…it’s about building relationships

Yes, we play games because we like to win, but we also play games with people because we like to be with the other people. When I started the contest I knew who several of the participants would be because I’ve gotten to know them over the years and knew they would jump all over this. The great surprise though is who else shows up to play the game. It’s like a “pick-up” game of accessibility fixes. You bring a ball to the playground and you never know who is going to want to play.

Lots of people decided to come play. Currently 65% of all of the Web sites on campus have had someone claim them as their own and look at their accessibility report. What percentage of people normally would hit “delete” or “mark as spam” when they receive an email from “the accessibility guy” saying he has an accessibility report for them? (I’m not saying that would ever happen here at NC State – it’s just a hypothetical question.)

Not all of those Web site owners decided to play in the contest, but them coming to the game and the discussions I had with them led to the next three lessons learned.

3. Have training and tutorials immediately available to users that solve the specific problems they are trying to fix

WCAG 2.0 is great, but let’s face it, not everyone was meant to have a deep meaningful relationship with the WCAG documentation. The documentation is extremely thorough, but that’s also what makes it so unapproachable for so many people. The documentation is War and Peace, but what people really want is the Cliff’s Notes version.

Most people aren’t like me. They don’t like to read about all of the nuances and possible implementations for each success criteria in WCAG or come up with creative implementations that haven’t been thought of yet. They have other jobs they want to do.

The moral of the story – don’t send people to the WCAG documentation to learn more about their errors or how to fix them. Tell them in your own words. You know what problems they are facing, so give them the solutions they need, not EVERY solution and nuance possible.

In our system when users view a list of their accessibility errors, along with that they get a brief description of the error that I wrote along with a link to a tutorial that I wrote that gets them exactly what they need. Many of the examples I use come straight out of the WCAG documentation, but I’ve streamlined the process.  As an example, when users see that they don’t have the language of the page defined, they get a link for Defining the Language of the Document

Many of these tutorials were written before the game began, but they were updated as new questions came in.

4. Different people come to the game with different skill levels, so you have to figure out how to meet people where they are

I would love to play basketball with Michael Jordan, but Michael Jordan might not like playing with me. How do you create a game space where people with varying skill levels can play?

When the game was first envisioned it was designed with Web developers in mind – people who were comfortable with viewing the source code of documents. I always knew I wanted to reach out to people beyond the traditional Web developer group, like our communications people and content creators. I thought one of my “ins” with these groups was I could also report to people how many broken links and misspelled words they had. While people might not make accessibility a top priority in their jobs, correcting misspelled words and broken links were a high priority for professionally produced content.

When I sent the communicators and content creators information about the game, I stated that they might want to forward much of this information to their Web developers. Then came the day when I taught a class on Interpreting your Accessibility Scan Results, and the only people that showed up were content creators. To them source code was a foreign language. So how do you teach about an accessibility report that talks in technical terms and gives line numbers of where errors occur? Or an even bigger problem, how do you speak to someone about an accessibility report who doesn’t even understand the concept of accessibility?

We spent the hour looking at their reports and starting to break out which errors were probably things their Web developers would have to fix and which were things that they as content creators would have to fix. Out of that discussion we were able to start generalizing probabilities of whether certain errors applied to them or applied to their developers. That information will soon make it’s way into everyone’s report, which leads us to the next lesson learned.

5. Don’t get too attached to your game design, because it probably could have been designed better and should have been designed better

Creating good games is hard and the best ones change when they need to. Did you know that in the original rules for basketball dribbling was not allowed?
original basketball rules, types on faded yellow paper

You might not get all of your rules right the first time either. Be open to suggestions that people give you for improvements. Also be very responsive with changes, especially when you have one of those moments when accessibility is getting their undivided attention.

Ever since the game went live, here are some of the suggestions that people gave that I implemented, usually within a day or two of receiving the request.

  1. ability to request rescans as often as you want them as opposed to once a quarter – this took a major overhaul of some of the back-end processing
  2. showing historical data for how a site has improved over time
  3. instead of showing line numbers where misspelled words are, show the actual misspelled words – this was not as easy as it seems given the tool we were using
  4. added distribution graphs to show where there site falls in terms of total errors

6. Automated scans miss some of the biggest accessibility problems

I knew this going in, but it was really obvious when I saw some of the results. One of our sites which did quite well in the contest still had significant accessibility problems with it that the scan didn’t pick up. There are certain aspects of accessibility that automated scans simply cannot accurately asses. For example, if a site uses a table-based layout, how do you determine if an actual data table embedded in the layout table is coded correctly? How do you even know if it’s a data table if there are no table headers, captions, or scope or summary attributes? Automated tests also fail at assessing user interaction with a Web page, like testing for true keyboard accessibility.

This automated scan doesn’t solve all of our problems, but it lets us take a step, which leads us to the next lesson.

7. Mario didn’t save the princess in world 1-1

Super Mario Brothers screen shot, with Mario standing in world 1-1

I think one of the things that often holds us back in the accessibility field is we want to make sure we say and do everything as perfectly as possible and that we don’t leave anything out. I think being accurate and complete is very important, however, if completeness becomes the thing which prevents us from making any progress then we aren’t helping anyone.

I think this problem impacts both people who are trying to create accessible content and those of us trying to help them do it. We will always find more accessibility problems to fix. We will always find a more accessible way to implement something. As teachers we will always find better ways to say something and more complete examples to give. But you have to get it out the door. I believe in release early, iterate often.

In fact one of the aspects of games is the ability to slowly improve yourself over time. When you are able to slowly yet meaningfully make progress on improving your Web site’s accessibility, that can be very rewarding. Being able to say, “two months ago I was here, but now I’m here” is powerful.

In game design I think this approach is important too. Like I said, the tool as it is now doesn’t solve all of our problems, but we’ve made meaningful steps. I can now add new features into the game to help address some of the remaining deficiencies we have. Here are some of the planned new features.

  1. There will soon be a set of manual tests that you can do and earn extra points for your score once you complete and pass the test. For example, if you do a test to see if the keyboard focus is visible at all times you will get some bonus points. If you actually make the keyboard focus visible at all times you will get even more points.
  2. I am looking at adding additional evaluation tools into the mix that are better at detecting certain errors than our current toolset is able to do.
  3. And as a teaser, I’m also looking to add in some artificial intelligence and statistical techniques to assess for some problems that there are no good ways to test for yet. Stay tuned for this one.

8. If something good comes out of the game, share it with the world

The final lesson for this round – if you had fun and something good came of the game, share it with others. We had two projects come out of our challenge that are now available to everyone.

First, we now have a new Drupal module that automatically looks for links that are coded to open in new windows and it appends some text to the link to alert the user to this. The link is hidden offscreen for screen reader users and comes into view when the link receives keyboard focus or a mouse hover.

Second, we now have a bookmarklet that lets you easily assess the reading level of published Web pages.

I’ve written a lot and could write more, but it will have to wait for the next post.