On March 20, 2014, the W3C finally published the WAI-ARIA standard version 1.0. After many years of development, refinement and testing, it is now a web standard.

But I am often asked again and again: What is it exactly? What can it do for me as a web developer? And what can it not do?

I often find that there are assumptions made about WAI-ARIA that are not correct, and the use of it with such wrong assumptions often lead to sites that are less accessible than when ARIA is not being used at all.

In addition, Jared W Smith of WebAIM just yesterday wrote a very good blog post titled Accessibility Lipstick on a Usability Pig, highlighting another related problem: Even though a website may suck usability-wise, pouring WAI-ARIA sugar on it somehow forces it into compliance, but it still sucks big time.

So with all these combined, and after receiving encouragement by Jason Kiss on Twitter, I decided to write this post about what WAI-ARIA is, what it can do for you as a web developer, and what it cannot do. Or rather: When should you use it, and more importantly, when not.

I realize such articles have been written before, and these facts have also all been stressed time and again in talks by various good people in the field of web accessibility. But it is such an important topic that it is finally time for this blog to have such an all-encompassing article as well.

So without further due, let’s jump in!

What is it?

WAI-ARIA stands for “Web Accessibility Initiative – Accessible Rich Internet Applications”. It is a set of attributes to help enhance the semantics of a web site or web application to help assistive technologies, such as screen readers for the blind, make sense of certain things that are not native to HTML. The information exposed can range from something as simple as telling a screen reader that activating a link or button just showed or hid more items, to widgets as complex as whole menu systems or hierarchical tree views.

This is achieved by applying roles and state attributes to HTML 4.01 or later markup that has no bearing on layout or browser functionality, but provides additional information for assistive technologies.

One corner stone of WAI-ARIA is the role attribute. It tells the browser to tell the assistive technology that the HTML element used is not actually what the element name suggests, but something else. While it originally is only a div element, this div element may be the container to a list of auto-complete items, in which case a role of “listbox” would be appropriate to use. Likewise, another div that is a child of that container div, and which contains a single option item, should then get a role of “option”. Two divs, but through the roles, totally different meaning. The roles are modeled after commonly used desktop application counterparts.

An exception to this are document landmark roles, which don’t change the actual meaning of the element in question, but provide information about this particular place in a document. You can read more about landmarks in my WAI-ARIA tip #4. Also, if you’re using HTML5, there are equivalent elements you might want to use as well.

The second corner stone are WAI-ARIA states and properties. They define the state of certain native or WAI-ARIA elements such as if something is collapsed or expanded, a form element is required, something has a popup menu attached to it or the like. These are often dynamic and change their values throughout the lifecycle of a web application, and are usually manipulated via JavaScript.

What is it not?

WAI-ARIA is not intended to influence browser behavior. Unlike a real button element, for example, a div which you pour the role of “button” onto does not give you keyboard focusability, an automatic click handler when Space or Enter are being pressed on it, and other properties that are indiginous to a button. The browser itself does not know that a div with role of “button” is a button, only its accessibility API portion does.

As a consequence, this means that you absolutely have to implement keyboard navigation, focusability and other behavioural patterns known from desktop applications yourself. A good example can be read about in my Advanced ARIA tip about tabs, where I clearly define the need to add expected keyboard behavior.

When should I not use it?

Yes, that’s correct, this section comes first! Because the first rule of using WAI-ARIA is: Don’t use it unless you absolutely have to! The less WAI-ARIA you have, and the more you can count on using native HTML widgets, the better! There are some more rules to follow, you can check them out here.

I already mentioned the example with buttons versus clickable divs and spans with a role of “button”. This theme continues throughout native roles vs. ARIA roles and also extends to states and properties. An HTML5 required attribute has an automatic evaluation attached to it that you have to do manually if you’re using aria-required. The HTML5 invalid attribute, combined with the pattern attribute or an appropriate input type attribute will give you entry verification by the browser, and the browser will adjust the attribute for you. All of these things have to be done manually if you were using aria-invalid only. A full example on the different techniques for form validation can be found in a blog post I wrote after giving a talk on the subject in 2011.

Fortunately, this message seems to finally take hold even with big companies. For example, the newest version of Google Maps is using button elements where they used to use clickable divs and spans. Thanks to Chris Heilmann for finding this and pointing it out during an accessibility panel at Edge Conf (link to Youtube video) in March 2014!

Here’s a quick list of widget roles that have equivalents in HTML where the HTML element should be preferred whenever possible:

WAI-ARIA role Native element Notes
button button use type=”button” if it should not act as a submit button
checkbox input type=”checkbox”
radiogroup and radio fieldset/legend and input type=”radio” fieldset is the container, legend the prompt for which the radio buttons are the answer for, and the input with type of “radio” are the actual radio buttons
combobox select size=”1″ Only exception is if you need to create a very rich compound widget. But even then, combobox is a real mess which warrants its own blog post.
listbox select with a size greater than 1 Only exception is if you create a rich auto/complete widget
option option As children of select elements or combobox or listbox role elements
list ul or ol Not to be confused with listbox! list is a non-interactive list such as an unordered or ordered list. Those should always be preferred. Screen readers generally also supporting nesting them and get the level right automatically.
spinbutton input type=”number” If the browser supports it.
link a with href attribute Should, in my humble opinion, never ever ever be used in an HTML document!
form form Nobody I know from the accessibility community can actually explain to me why this one is even in the spec. I suspect it has to do primarily with SVG, and maybe EPUB.

The reason all these roles to native elements mappings are in there at all are because of the fact that WAI-ARIA can also be applied to other markup such as EPUB 3 and SVG 2. Also, some elements such as spin buttons and others are new in HTML5, but because WAI-ARIA was originally meant to complement HTML 4.01 and XHTML 1.x, and HTML5 was developed in parallel, roles, states and properties were bound to overlap, but got more defined behaviors in browsers for HTML5.

Likewise, you should prefer states such as disabled and required over the WAI-ARIA equivalents aria-disabled and aria-required if you’re writing HTML5. If you write HTML 4.01 still, this rule does not apply. If you’re specifically targetting HTML5, though, there is not really a need for the aria-required, aria-disabled and aria-invalid states, since the browsers take care of that for you. And yes, I know that I am in disagreement with some other accessibility experts, who advise to use both the HTML5 and WAI-ARIA attributes in parallel. Problem with that is, in my opinion, that it is then extra work to keep the WAI-ARIA attributes in sync. Especially with the aria-invalid attribute, this means that you’ll still have to put in some JavaScript that responds to the state of the HTML5 form validation state.

Why this duplication? Why can’t the browser just also react to the WAI-ARIA attributes as it does to the HTML ones?

This is a question I am getting a lot. The simple answer is: Because WAI-ARIA was never meant to change browser behavior, only expose extra information to assistive technologies. The more complex answer is: WAI-ARIA can be applied to XHTML 1.0 and 1.1, HTML 4.01, and HTML5. The HTML5 attributes can only be applied to HTML5 capable browsers, including mobile, but will give you all kinds of extra features defined in the standard for these attributes. If the WAI-ARIA attributes were suddenly made to influence actual browser behavior, the level of inconsistency would be enormous. To keep WAI-ARIA clean and on a single purpose, it was therefore decided to not make WAI-ARIA attributes influence browser behavior ever.

When should I use it?

Whenever you create a widget that is not indiginous to your host language, e. g. HTML. Examples of such widgets include:

  • tree with treeview children: When creating something the user should be navigating in a hierarchical fashion. Examples can be seen in the folder tree in Windows Explorer or the list of topics and books in the Windows HTML help viewer.
  • menu with menuitem, menuitemcheckbox, and menuitemradio children: A real menu system as can be seen in Windows or OS X apps.
  • grid or treegrid, with gridrow, columnheader, rowheader, and gridcell children: An editable grid similar to a spreadsheet. Not to be confused with data tables which use native HTML table, tr, th, and td elements with proper scope and other attributes.
  • toolbar container with actual buttons or other interactive elements as children.
  • dialog as container for a message or input prompt that needs to be acknowledged or dismissed in a modal fashion, e. g. no other part of the web page or app can be interacted with at the moment. The role alertdialog is related, although I recommend not using it since its support is inconsistent.
  • application, in which you control every single focus and keyboard interaction. For a detailed discussion, see my article on the use of the application role.

In all of the above cases, it is your responsibility to:

  1. Familiarize yourself with the expected user interaction with both mouse and keyboard.
  2. Make sure all elements can be reached via the tab key, and that focus is always visible. Use the tabindex with a value of 0 to put stuff in the tab order at their natural position within the document.
  3. Make sure some items are not necessarily reachable via the tab key. For example in a tool bar, items should be navigated via left and right arrows, and tab should jump straight to the next container (tool bar or other compound widget), and Escape should return to the main application area. Likewise, a tab list should be navigated with left and right arrows, too, and tab itself should jump into the tab panel that is active.
  4. You manage focus appropriate to the type of widget you are in. For example, when opening a dialog (role “dialog”), it is your responsibility to set keyboard focus to it or its first focusable child element, and to manage modality, meaning you must make sure tab does not wander outside the confines of the dialog as long as it is open. Escape should generally cancel, and a dedicated OK/Accept/Save button should close with changing. Make sure once you’re done with a dialog, you return focus to a defined position in your application/document, like the button that opened the dialog in the first place, or keyboard and screen reader users might get lost.

If you do not adhere to the common interaction patterns associated with certain of these roles, your WAI-ARIA sugar might very quickly turn into sour milk for users, because they get frustrated when their expected keyboard interaction patterns don’t work. I strongly recommend studying the WAI-ARIA 1.0 Authoring Practices and keeping them handy for reference because they provide a comprehensive list of attributes and roles associated to one another, as well as more tips on many of the things I just mentioned. Another very good resource is the afore mentioned Using WAI-ARIA in HTML document which provides an extensive technical, yet easy to understand, reference to best practices on how to apply WAI-ARIA code, and also, when not to do it.

Closing remarks

I realize that to someone just getting started with web accessibility, these topics may seem daunting. However, please remember that, like learning HTML, CSS and JavaScript, learning the intricacies of web accessibility means you’re learning a new skill. The more often you use these techniques, the more they become second nature. So don’t be discouraged if you at first feel overwhelmed! Don’t be shy to ask questions, or pull in people for testing! The accessibility community is generally a very friendly and helpful bunch.

One thing that may also help with motivation, and it’s been thankfully mentioned more and more often: Accessibility and usability go hand in hand. The more you improve the usability, the more it gets you there in terms of accessibility, too. And first and foremost, it’s about people! Not about some WCAG technique, not about a law that needs to be fulfilled, but about people actually using your web site or web application. Fulfilling legal requirements and WCAG techniques then come naturally.

So: Make WAI-ARIA one of your tools in your arsenal of tools for web development, but take its first rule to heart: Don’t use it unless you absolutely have to. Get the usability right for keyboard users, make sure stuff is properly visible to everyone even when they’re standing outside with the sun shining down on their shiny mobile phones or tablets (thanks to Eric Eggert for that tip!), and use WAI-ARIA where necessary to provide the extra semantic screen readers need to also make sense of the interactions. With people in mind first, you should be good to go!

Happy coding!

Today, on February 26, the TinyMCE team released version 4.17 of the JavaScript/HTML editor for the web. In the release notes, the first item mentioned is much improved accessibility support. For those of you not familiar with TinyMCE: It is the WYSIWYG (What You See Is What You Get), AKA visual or rich editor used in many popular content management systems such as the WordPress blogging software.

Over the past few weeks, I had the pleasure of testing the improved accessibility features and provide feedback to the developers. Here are a few hints to get you going, but for a full experience, I suggest you try it out yourself!

I tested with Firefox and NVDA and JAWS, but you should also get good results with Internet Explorer and other browser/screen reader combinations. Since the two mentioned work so well, it can be trusted that the implementation is very solid.

When you navigate or tab to the sample editor instance linked to above, you’ll land in the content area with some sample text. Arrowing up and down will give you paragraphs, headings and other items such as links. Note that NVDA and Firefox treat links as embedded characters, you have to actually navigate into them to read their texts, but they are accessible.

From the content, you can press Alt+F9 to open a menu bar. Left and Right arrow navigate through the top menu items like in your average desktop app, and Down Arrow will actually open a menu. Note that from there, you cannot go Right or Left through the various drop-down menus, you first have to press Escape once to go back to the top level. When on sub menus, Right Arrow will walk into them, escape will back up.

Alternatively, you can press Alt+F10 to go into the toolbars. You’ll land on the first tool bar and can tab or arrow through the items. Sub menu items will have the sub menus or panels opened via Down Arrow, and closed via Escape. When you reach the end of one toolbar, Right Arrow and LeftArrow wrap to the next and previous tool bars respectively. Escape will bring you back into the main content area.

From either the menus or toolbars, you can open dialogs such as Insert/Edit Image/Video. These are multi-page dialogs with at least two tabs at the top. When in the tab list, Right and Left arrow will move between the tabs, Space will make the current tab active. Tab moves into the panel and through the controls. OK will accept changes, Escape or Cancel will discard.

On the tool bars and in the formatting menu, you can insert emoticons or change the text and background colors. These are panels you open by pressing DownArrow or Enter on their respective menu/toolbar items, and then use the arrow keys to select the actual item you want applied/inserted. All of these items are also made to talk, so a blind person can change the text color as well and know what they’re doing.

All of this is due to the great use of the WAI-ARIA (Accessible Rich Internet Applications) markup. As soon as content management systems start integrating this new version, they’ll automatically benefit from these improvements. This opens the door for even more sites offering better than plain-text editing on the web in an accessible fashion. I cannot even start to count how often I was frustrated in the past because while composing a blog post in plain text, some single symbol missing or fat-fingered markup caused whole posts to fall apart. I personally favor rich editing over plain text editing because I do not have to worry about the markup any more and can concentrate on what I want to say instead. If I want to insert a link or change the formatting of something, I just select the text and apply the formatting I want.

I congratulate the TinyMCE team on this new release and am looking forward to even more good accessible features in the future!

Prompted by the recent Microsoft and GW Micro partnership announcement, I took a long overdue look at Microsoft’s Office 365 product offerings. The Home Premium edition not only gives you five installations of full Office Professional versions in your household, Windows and Mac combined, but also the apps for iOS and Android on up to five mobile devices, extra SkyDrive cloud storage space, and access to the Office in the browser offerings. Considering the cost of shelf Office products, the subscription prices are an amazing end user benefit!

Quick test: Office on the desktop and in mobile apps

I first tested the current desktop versions. Office 2013 for Windows is, of course, largely accessible to NVDA, JAWS, Window-Eyes and others. I heard that there seem to be some problems with Outlook, but I didn’t test that.

The Mac version of Office is, although superficially seeming accessible, not usable because in Word 2011 for Mac, for example, you don’t see the document content with VoiceOver.

The iOS version of Office Mobile has some major accessibility issues as well, primarily because of flaky document content and appearing and disappearing toolbars.

Firefox for Windows

I was hesitant to look at the Office in the Browser offerings at first, given the dismal situation of both Google Docs and Apple iWork in the browser. But boy, was I surprised! I brought up SkyDrive and created a new Word document from within Firefox on Windows and using NVDA.

The first thing I heard was the fact that I landed in the editing area, and that I could leave this by pressing control+f6. And if I wanted more help on the accessibility, I should press Alt+Shift+a. The latter brings you to this help page, which contains a lot of good information.

When I started typing into Word, I immediately noticed that my braille display was following along nicely. This can not be said for Google Docs which uses pure live region magic, which is completely speech-only, to convey information. I then also found out that NVDA was reporting to me font information. So when I bolded text and then asked NVDA to report to me the font and color, I heard the formatting information. Also when I formatted one paragraph as a heading, I was told the different font info.

I then pressed the above mentioned Control+F6 and cycled to the status bar. I saw the word count, language my document was in, and other info. I pressed the keystroke again and was taken to the Ribbon controls. NVDA immediately picked up all the info MS provides in their web app, that this is a ribbon toolbar, that I am on this and that tab of so many tabs, etc. The only means to navigate currently is by using the tab and shift+tab keystrokes, and Space or Enter to activate buttons. You first tab through all tabs, the Share button and the Minimize Ribbons button. Focus then moves into the ribons of the actually selected tab. While tabbing through, I noticed that all tabs were announced as selected. This seems to be a small bug still, in that the aria-selected=”true” should only be present on one of the tabs, meaning the tab whose content is shown below. All others should have aria-selected=”false”. Also, MS could optimize the keystrokes by allowing left and right arrows between the tabs, and the adjacent buttons which are always visible, and let the Tab key move straight into the active ribbon, like is done in the desktop version of Word.

Speaking of the ribbons: NVDA speaks the grouping information when passing through each ribbon. So you always hear when transitioning between different sub groups inside the ribbon. This helps immensely when you want to find the right group quickly.

Another press of Control+F6 brought me back to the document, and I could continue editing right away. Many of the shortcuts familiar from the desktop version of Word also work here, for example Control+B to bold text.

A slightly technical note: MS always feed the current paragraph only to the screen reader. This guarantees quite good performance. The fact that they’re doing this with all formatting intact means that they are using something more powerful than a simple textarea element. It is pretty amazing!

And all this time, I did not have to switch modes with NVDA. MS were mindful of the application role and used it wisely while developing this app. They provide all keyboard access to all controls, and since the document is in editing mode, there is also no problem reading the document content.

As described in the help document linked above, the best way to view your document is by going to Reading Mode from the View ribbon, clicking the “Accessible reading mode” link, and viewing the generated accessible PDF in Adobe Reader. Yup, that’s right, MS create a tagged PDF right out of the Word Web App for you! Note that if you’re using Firefox, you’ll probably first get a web view with pdf.js presenting the PDF. pdf.js does not yet use Accessibility tags, so the best is to click Tools, Download, and then save or open the PDF in Adobe Reader. This is the Tools item in the virtual buffer, not the Firefox menu item.

After I finished some testing with NVDA, I went back and did the same with JAWS and Window-Eyes. For both screen readers, it is recommended that you follow the hint given in the MS Office web app help document to turn off virtual mode. Both screen readers have some difficulty handling role “application” correctly, so they need to be forced into non-virtual mode for everything to work correctly.

The Window-Eyes experience was rather dismal despite of this, though. It barely picked up changes in the text content, navigation was slow and unpleasant. It spoke the ribbons OK, but not as fully fledged as NVDA did. Most importantly, it didn’t pick up changing group info.

JAWS did very well with Office web apps and Firefox. It even picked up the paragraph format used each time the paragraphs changed. Nice touch! It did, however, capture the Ctrl+F6 keys, so it would not allow Word to process them correctly. Navigation between the document and other elements was therefore quite cumbersome, since one needed to tab from the browser controls back to the document and into the ribbons. Since Control+F6 is no keystroke in Firefox, it is probably some funky scripting that is intercepting this keystroke and doing what would otherwise be done with F6 alone. I consider this a pretty annoying bug on Freedom Scientific’s part. JAWS also spoke the ribbon groups in a flattened manner, leaving out group transitioning mostly. Formatting information in the document was picked up just like by NVDA.

Internet Explorer

After I finished tests with Firefox, with those overwhelmingly pleasant experiences with NVDA in particular, I also went to see how Microsoft’s own browser and screen readers which, with the exception of NVDA, focus primarily on IE, would fare.

NVDA worked, but was very slow when navigating the document. Again, it handled role “application” best without the need to switch any modes. Formatting info was picked up.

JAWS worked OK once I turned off virtual mode. Here, it also didn’t capture Control+F6. Its speaking of the ribbons was rather flat, though, not picking up changes in ribbon groups. It also picked up formatting information.

Window-Eyes, again, left the most flaky impression, with document content not always being picked up, navigation being slow, and focus often being stuck or lost.

With the exception of the NVDA sluggishness I saw, which is probablz something that can be fixed in a timely manner, I would compare the results as almost equal between Firefox and IE, with a slight edge for Firefox.

Safari on OS X

After I completed my testing on Windows, I looked at OS X, where the most popular combination is Safari and VoiceOver. The result was rather disappointing. Both latest Safari on Mountain Lion and Mavericks only pick up the very first paragraph, and if you type something new. Everything else simply isn’t spoken when navigating through the document with up and down arrow. The ribbons are spoken rather flat, again, with grouping information not being picked up inside the individual ribbons. If you are looking to edit Word documents on Mac, I recommend you use Pages, Nisus Writer Pro or such. Especially the new Pages on Mavericks is much better in terms of accessibility than it was previously.

On mobile devices

In Firefox for Android, MS doesn’t render a full Word UI. Instead, one gets only the loosely formatted document and a page number indicator. Trying to request the desktop site from the menu brings you to the general Office.com web site instead. The document can be read, and the login process into your Microsoft Account works as expected.

QuickOffice, available on the Play Store, seems to be pretty accessible, from a quick test with my simple document opened from the MS SkyDrive app.

On an iPad using Safari and VoiceOver, you do get a full UI, and tabs and buttons, combo boxes etc., in the ribbons are spoken when touching or swiping, but grouping information is once again not available. Also, it is not possible to get into a consistent editing mode to work on a document. It is possible in theory, and outside of VoiceOver usage, may even work just fine, but once VoiceOver comes into play, support is not really available. Either the keyboard doesn’t come up, or if it does, the cursor cannot be tracked. Also, the shortcuts like Control+F6 don’t work with an attached keyboard.

If you want to use an iPad to do office document processing, I suggest you grab Pages, Numbers, and Keynote from the App Store and edit documents there. The new versions of these apps are amazing in terms of accessibility, in some points even surpassing their Mac counterparts.

Conclusion

Microsoft did an awesome job with the Office web apps. I only tried Word in this test, but according to the documentation, there is also support for PowerPoint, and at least some for Excel. The fact that Firefox and NVDA work so seamlessly with this web app shows that Microsoft did the coding right, and that their implementation of the WAI-ARIA standard is correct. I was particularly pleased that braille is also working. While it may not be important in some areas of the world, braille isn’t dead, and the fact that this works is very important to many users.

This is an excellent mainstream example of a well-implemented web app using WAI-ARIA! It should be an incentive to Google and Apple to also implement proper support into Docs and iWork respectively. While Docs has some live region magic, this leaves out braille users completely, and it doesn’t transport formatting information. I can edit Google Docs documents, yes, but I have no control over the formatting, unless I go into the tool bars, tab through to the various combo boxes and buttons and slowly gather the needed information that way. ChromeVox may or may not be able to gather some more information from Chrome than other screen readers do in all other browsers, but ChromeVox isn’t the only solution people are using to access documents, and the solution implemented by Google should be universal, not singling out any one browser/AT combo.

And Apple’s iWork in the browser isn’t accessible. Nuff said.

It is awesome to see how Microsoft has come along in accepting and implementing web standards. Office Web apps is one great example, and as someone who has worked on improving the WAI-ARIA support for Firefox and helped flesh out various user scenarios by providing testing, blog posts and such for years, it makes me extremely proud to see that Firefox and NVDA are the best to work with is at the time of this writing!