WAI-ARIA for screen reader users: An overview of things you can find in some mainstream web apps today

After my recent post about WAI-ARIA, which was mostly geared towards web developers, I was approached by more than one person on Twitter and elsewhere suggesting I’d do a blog post on what it means for screen reader users.

Well, I’ve got news for all my blind and visually impaired readers: You’re not getting one blog post, you’re getting a whole series instead! 🙂

This blog post will kick it off, and I will cover some general uses where you will find that WAI-ARIA improves your user experience. These examples are most useful when using modern screen reader/browser combinations, as is the case with most web stuff today anyway. So if you’re using NVDA or JAWS on Windows, Orca on Linux, or VoiceOver on the Mac, most, if not all, example uses below should work for you in one way or another. Browsers on Windows are Firefox and Internet Explorer, on Linux it’s also Firefox, and on OS X most likely Safari. Chrome and ChromeVox may or may not work in a similar way, but I’ll leave that to those using that combination to test it.

Some WAI-ARIA basics

WAI-ARIA stands for Web Accessibility Initiative – Accessible Rich Internet Applications. It is a World Wide Web Consortium (W3C) standard. It allows web authors to tell assistive technologies that certain constructs of HTML markup — the stuff that makes up web pages — mean something that is not actually available in normal HTML, but maps to some desktop control that users are probably familiar with.

WAI-ARIA has three pillars: Roles, States and Properties, and Live Regions. I will briefly cover each of them below, but not extensively, since this is mostly for end users.


Roles tell the screen reader that a particular element of a web page is actually meant to be something else. For example, if assigning a role of “button” to a fancy looking clickable element made up of one or more generic HTML elements, screen readers will simply read it as a button in virtual buffer. If the author did a good job of providing keyboard accessibility, you can even tab to it and press Space to activate. All examples below do that.

Roles are oriented along known control types from the desktop. Using WAI-ARIA, you can mark up even fancy stuff like whole tree views, similar to what the folder tree in Windows Explorer is. In a later article, we’ll see such a tree view in action.

States and Properties

States and Properties tell the screen reader something more about a particular control than normal HTML can. For example, even in older web pages, they can tell the screen reader that a field is required or invalid. They can tell whether a button opens a popup or sub menu, if something has an auto-complete, if a fancy checkbox is checked or not, etc. We’ll see a lot of these in action in this and other articles.

Live Regions

Live Regions allow the web author to make the screen reader tell the user about some dynamic updates. For example, a live region can be used to make the screen reader say information like “auto-complete results are available”, or “Your message has been sent successfully”. Status information that is good to know at a particular moment, but not important enough to stick around for long, or even be exposed in a dialog form.

Live regions can be either polite, meaning they speak once your screen reader has finished speaking what it’s currently speaking, or assertive, meaning they will interrupt whatever the screen reader is currently speaking, to immediately make you aware of a certain status change.

OK, now that we’ve got these pillars of WAI-ARIA laid out a bit, let’s get started looking at some examples! it is important that you have JavaScript in your browser turned on. Yes: On, not off! Modern web apps live only because of JavaScript, and turning it off nowadays is like cutting off an arm or foot, it will leave you mostly immobilized on most modern web sites. So throw away those old beliefs that javaScript is no good for accessibility, and turn it back on or uninstall that NoJS add-on you’ve been keeping around!

Each of the below examples will open in a new tab or window on purpose, so you can play around with them a bit and return to the article when you’re done.


Twitter got a huge accessibility boast over the last year to a year and a half. Twitter even has a dedicated accessibility team now making sure their web site and mobile apps are becoming more accessible, and stay that way.

When you open Twitter and log in — assuming you have an account –, you can do several things to try out its accessibility.

First, focus on the Tweet Text edit field and invoke focus or forms mode, or whatever that mode is called in your preferred screen reader. Even that alone will give you several bits of information. It will tell you that the edit field is collapsed, that it has a sub menu, that it has an auto-complete, and that it is multi-line. The bits about having a sub menu and being collapsed are coming from WAI-ARIA markup. The other info could be encountered in just any multi-line edit field on the web.

Next, start typing some text. Notice that on occasion, Twitter will speak numbers as the number of available characters that you have left in the tweet decreases. Twitter has a limit of 140 characters per tweet.

Now, let’s add a user name. Type the @ sign. My Twitter handle is MarcoInEnglish (in one word, capitalization is not important). So after the @ sign, type the letter m. If you’re following me, at least one result should come up. The first thing you’ll hear now is that the edit field changes state from “collapsed” to “expanded”. After a moment, depending on your internet connection, you will also hear something like “3 results available” (number may vary). This means that Twitter has found matching handles that start with, or contain, the letter m.

Now, press DownArrow. You will now hear that you are in a list, that a certain list item is selected and what it contains, and that it’s item 1 of 3 (or whichever number of results are being displayed). All this is WAI-ARIA magic. You can press Up and Down to select an entry, Tab or Enter to insert that into your tweet, or Escape to dismiss the AutoComplete and return focus to the edit field without inserting anything, and resume typing.

If you decided to press Enter or Tab, you’ll hear that focus returns to the edit field, and that it is now collapsed again. Your cursor is positioned after the Twitter handle you just inserted, and a space has been added for you so you can continue typing uninterrupted.

Next, let’s look at something else on the Twitter page. Press Escape or whichever hotkey gets you out of forms or focus mode back into browse mode/virtual cursor mode. Find the heading level 2 that says “Tweets”, then DownArrow to the first tweet. After the tweet text and possible links, you’ll find a list of 4 items. The first three items are normal buttons named Reply, Retweet and Favorite. The fourth, however, is a menu button that has a sub menu. Screen readers will announce it as such. Press it. Focus will now shift to a menu, and you have 3 items: Share via E-Mail, Embed, and Report. These are announced as menu items within a menu. Press Escape to dismiss this menu without selecting anything.

These are also WAI-ARIA menus. Menu items, or menu buttons with attached sub menus are normally not available in HTML. However, through WAI-ARIA markup and some focus/keyboard handling via JavaScript, these widgets can be made fully keyboard accessible and expose all relevant information to screen readers, including menus.

Want to get even more app-like? If you’re on Windows, which probably most of you are, turn off your virtual cursor. With NVDA, you do this by pressing NVDA+SpaceBar. JAWS’s shortcut is Insert+Z. You may have to press it twice to also prevent JAWS from reinvoking virtual PC cursor when a new page loads. Once you’ve turned off your browse mode or virtual cursor, start pressing J and K (yes, the letters) to move through tweets. You’re now moving the actual keyboard focus, and through WAI-ARIA labeling, and some live regions on occasion, you are getting a fully accessible experience. Press your Question Mark key to hear which other keyboard shortcuts you have available. You can reply, favorite, retweet tweets, expand conversations and jump to the new tweets that might, in the meantime, have been added while you were browsing your timeline. You can also quickly jump to the compose edit we were in earlier, to write a new fresh tweet. In essence, you might hardly ever need virtual cursor at all on Twitter, because the app-like experience is so good!

On Mac OS X, you don’t even have to worry about switching modes, because there is no virtual cursor, and you can use those Twitter shortcuts right away. In fact, this might be a much more efficient way to navigate the Twitter experience than the VoiceOver commands for web browsing.

All the while, keyboard focus will make sure that pressing Tab will actually move into the tweet you’re currently reading.


Facebook has made similar advancements in making their regular web presence more accessible in the last 18 to 24 months. If you log in with your Facebook account and start exploring from the top, you’ll immediately encounter a few menu buttons that have popups attached to them. These are the Friend Requests, Messages, and Notifications buttons. If you have the newest design, the Privacy and Account Settings buttons will also be there.

A bit further below, you will find the Search field. It is announced as a combo edit field, one of those edits that you can either type in or choose from a list. Focus it, and start typing, for example the name of the Facebook Accessibility page. You will automatically hear announcements as results become available. Like you would expect, you can arrow up and down through the results, and if you found the one you were looking for, press Enter to go to that page.

But let’s stay on the main page for now, and find the edit field that alllows you to post a status update. This is not only a normal edit field. It, too, has the possibility to auto-complete names or locations as you type them. If you start typing the name of a friend, a list will pop up that allows you to select from the available auto-complete results, and press Tab to insert that name into the text field, including tagging that person once you post the status update. Unlike we’ve seen on Twitter, the list comes up automatically, but you can continue typing without the danger of selecting something. You will only insert a search result via the Tab key.

Again, listen to what your screen reader tells you about the results, the list items, etc. Also, the widget to post a status update has a few buttons at the top that allow you to switch whether you’re posting a news item, a photo or video. These are called toggle buttons. They are a bit similar to radio buttons, but because they will immediately perform an action once you press them, they’re buttons. Radio buttons normally only change a selection, but don’t cause whole widget environments to change. You will hear the announcement that one, by default the Story item, is pressed, meaning this is the button that is currently active. An analogous construct could be in your word processing toolbar where you have Left, Center, Right, and Justified buttons. Only one of them can be active — or pressed — at a particular time. If one is pressed, the pressed state of another goes away. Same here in this Facebook widget.

All of this is, again, WAI-ARIA. In earlier years, you would not have known which item was the active one, or that these were toggle buttons at all. The auto-complete results would not have spoken as such, either.

There’s one more thing I would like you to try: Find a friend who will be your guineapig and send them a private message. After you send it, leave your focus in the edit field and wait for their reply. Ideally, you’d choose a friend who is currently showing as online. Once she or he replies, you should automatically hear the message and can start replying right away. This is again a live region at work. Once new messages come in, even those that you just sent, they’ll be read out aloud.

Microsoft OneDrive and Office Online

Microsoft also has made some great strides in making their online services more accessible. Their cloud storage is called OneDrive, and it is a web frontend to the files and folders you have stored in their cloud.

If you have an account at Microsoft OneDrive, log in and look at the list that is available on that page. It will list all your files and folders. Here, you can see a not yet fully complete implementation (as of this writing) of WAI-ARIA. For one, the list items are in multiple columns, so you can not only use up and down, but also left and right to move to items. Second, when pressing Enter, screen readers are not yet notified of changes. You have to press an arrow key again to hear that the contents has actually changed. Now, select a file, and press the context menu key. This is also called the windows key and is located to the left of the right control key on most keyboards. You should now hear a context menu open, and when you press up and down, you should hear the selected menu item. Yes, you should, but you won’t. 🙂 Because this is currently still a bug in the implementation. The context menu appears, you can move up and down, but the newly focused item is not yet being communicated to screen readers. Yup, it’s a bug, and I let Microsoft know about it when I found it just now. 🙂

As a workaround, you can turn virtual mode back on manually (NVDA+Space or for JAWS the NUMPAD PLUS key), move to the end of the virtual document, and find the menu items there. Arrow to the one you want and press Enter to select and activate it.

The Word document, if you selected one, will now open in Office Online. I wrote a more detailed review of Office Online already, so I strongly suggest you read that for an in-depth look at what Word in the browser has to offer! And it’s all done through a combination of modern web technologies, including WAI-ARIA. The tool bars and ribbons etc. are all rich internet application stuff.

More goodies are coming

The use of WAI-ARIA is spreading. Since many web sites use re-usable components such as jQueryUI and others nowadays, making these accessible will bring better accessibility to many web sites automatically. Other components, such as the TinyMCE and CKEditor rich web editors, have also made great strides in accessibility in the last year or two, and sites using these will get that accessibility for free. If you have a WordPress blog on version 3.9, try using the visual editor for a change, and from the edit area, press Alt+F10, for example! 🙂

Sometimes, as shown in the Microsoft OneDrive case above, things may not be fully implemented yet. Yes, these things can happen, and they happened on the desktop before, too. The best is to provide constructive feedback to the site owners and point out where the problems lie exactly. That way, they can be fixed most easily.

In the next few blog posts on this series, I will take an in-depth look at Google apps like GMail, Contacts and calendar, Google Drive, Docs, Sheets and Slides, etc. These have become more and more important in many work as well as educational environments, and Google has made great progress in the last 6 to 9 months alone making their offerings much more accessible than they were before. Their documentation is also generally pretty good, but I’d like to provide my own perspective nevertheless, and provide a few tips and tricks and point out possible caveats. So stay tuned!

I hope this article helped you get a bit of a glimpse into what WAI-ARIA is and what good it can do for you as a blind or visually impaired user when used properly. More and more web sites, components and companies are using it.

And if anyone tries to tell you that WAI-ARIA is not important or its importance is greatly overstated, ask them if they can do what you can do, without using WAI-ARIA, and without offering any 3rd party app, just the web browser and assistive technology. WAI-ARIA is important, and it is being enhanced to provide even richer and more accessible experiences in the future. More and more apps are moving to a web-based user interface for both desktop and mobile operating systems, and it is important to have a technology that can make these rich applications as accessible as their native counterparts or legacy offerings. The technology is there, it’s working, so let’s use it!

So keep your JavaScript turned on, fear not, and embrace the future of web apps!


17 thoughts on “WAI-ARIA for screen reader users: An overview of things you can find in some mainstream web apps today

  1. Hi Marco,
    Great article, regarding the Facebook search, did you test this using Voiceover on a personal FB account? When I attempt to search using my personal account, things do not work as you have described. I am having the following issues, that being not able to hear the search results spoken when arrowing through the choices. Thank you in advance for providing any answer on this. I do have my Javascript on. Have never turned it off.
    Interestingly, also on the FB subject, the search will work right if using Facebook as a page.

    1. Hi Christopher, I am not sure what you mean by “personal account” vs. “Facebook as a page”. I am always using the normal desktop site, not the mobile one. And last time I checked, search was working in Mavericks 10.9.2. That was one or two weeks ago. There *were* some problems on 10.8 (Mountain Lion) and Safari 6.1, but I have been off Mountain Lion for over half a year and no longer have that older system around to also test that.

  2. Hi,
    As an FYI about the Facebook ARIA menus, they are actually not coded properly or according to spec, so they don’t work reliably.

    For instance, if you activate Account Settings, you’ll notice that a button node has focus, not a menuItem node.

    This is why, if you arrow to Account Settings using JAWS and press Enter to activate it, it will enter Forms Mode, but using the arrow keys to navigate the menu then, does nothing at all. (Verified using JAWS15 in IE11 on Win7)

  3. To clarify, using JAWS15, arrow to Account Settings and press Enter to activate the menu; then use the arrow keys to navigate to “Log out”.

    It’s very important to ensure that the correct ARIA attributes are used with the correct ARIA widget construct, and that keyboard focus moves correctly within those particular nodes as specified by the spec.

  4. Christopher, we are aware of the graph search issues and looking into it. Please stay tuned to our public channels for updates. Bryan, the menu keyboard navigation, just for this use case, is intentional. We did not want to move focus to the first menu item because we wanted to keep the selected menu-item highlight and focus movement for mouse clicks and keyboard activations consistent.

    1. I understand, thanks, I know I’ve been bugging you guys about this particular issue for years.

      Nevertheless, though it may be intentional, that doesn’t mean that it is accessible or programmed according to spec.

      For example, if you are a keyboard user not using a screen reader, how do you activate “Log Out” from the Account Settings menu? I’m not able to do this on Win7 using IE11.

      Additionally, regarding programming the menu to the ARIA spec, an ARIA Menu is a specific widget type that maps to relevant control types in the platform API, which is directly reflected in the accessibility tree.

      This is why, when you build an ARIA Menu using the roles menu and menuitem, the elements that receive focus should be those that include role=menuitem if child node focusing is the method for switching selection instead of aria-activedescendant. When you do this, it is reflected as a “menu item” in the accessibility tree, and screen readers that support this will reflect the same.

      Instead, the way that the Facebook menus are constructed, the child node structure is as follows:

      link text

      button text

      This is why, when you have a menu open in JAWS and you press Insert+Tab to say the active element with focus, it identifies each of these as a “link” or “button” instead of a “menu item”.

      At the platform level, this is analygous to right clicking a web page, and when a context menu opens, expecting to find embedded links and buttons within each menu item.

  5. Marco, great post. I think this series will help a lot of people.

    BTW, when I am teaching accessible design to IBM designers and developers, I warn against the type of design used by Twitter web app. Using alpha keys like J and K and making it necessary to disable the virtual cursor manually is not good practice. It reduces usability, especially for new users, and makes the accessibility brittle. If you design with WAI-ARIA widget roles and support the standard keys for those roles, any screen reader, as well as other AT, can naturally respond in a manner that is predictable by the user without a bunch of non-standard keys and mode switching. In IBM, we do not allow our accessibility verification testers to touch esoteric JAWS commands like insert+z.

  6. heh, I know for a fact that even some blind ppl like the Twitter shortcuts, even under Windows. Under OS X, they are much more efficient than VoiceOver commands, even though they’re not standard for desktop apps. So this issue might actually be prone to a debate in the future.

    But I agree in principle that desktop paradigms should be used whereever they make sense. With the onset of touch screen devices, some things like tree views, for example, don’t always make sense to use for those devices even though they are great tools for desktops.

    I like the “esoteric JAWS commands”! 😉

  7. Thanks for tackling this. I’ll probably have to read it a dozen times to really get it, but it’s bookmarked, so I’m ready. Please tell us about Google+. Some marketing gurus think those who are ignoring its value are doing so at their own perile. I’m having trouble getting friends into circles, for instance, and I want to use it along with FB, Twitter, LinkedIn and my wordpress-hosted site to promote my novel The Heart of Applebutter Hill. Thanks again, looking forward to the next installment.

  8. Hello, Donna is not the only one who’ll have to read this many times. Nodes, perma-links, and more. Marco, I just found the February 14 response you sent. It doesn’t notify me via email and keeping up with this sort of active blog is confusing, alas, for me. I really feel my untechiness here. If you’d like, email me off blog. I suspect you can see my email address as it’s your blog. If not, it’s scopist65@gmail.com

  9. Thanks for this post, and the examples really help you get your head around how ARIA can be implemented to improve accessibility.

    One question:
    While testing Twitter with NVDA, the screen reader interrupted now and then to announce that there were new tweets waiting in the timeline (the aural equivalent of the ‘View X new tweets’ box that appears above the timeline for sighted users).

    My assumption is that this is done using ARIA live regions, but when looking at the source of the page I can’t see anything obvious to suggest how this was coded. It’s my naievety of how this stuff is actually put together – is this done with live regions or in some other way?

    1. Andy, yes, this is done via an ARIA live region. The item that contains the text or the container of that text has an aria-live=”assertive” attribute somewhere. Most likely coded via JS or such. I don’t know Twitter’s sources, but the mechanism is definitely that of a live region set to assertive, not polite.

  10. Hi Marco,
    Currently I’m working with some collegues at a major dutch bank, making things more accessible. Running into an issue with screenreaders trying to announce two live regions, which are updated at the same time when a user inputs data. The screenreader does not read those two regions one after the other, but sort of garbles them up, one interrupting the other. Chromevox makes the biggest mess of things, JAWS is better, but still not announcing in an orderly fashion. aria-live is set to polite for both regions.
    Is there any way to solve this?

    1. Hi Hans! Hm, no, I am afraid not. This stuff is all asynchronous, so depending on whichever of the two updates wins, it is announced first. polite should, however, not cancel out the other, but be queued up. But not all screen readers implement that correctly. The question is: Are these live regions absolutely necessary? Or would there be a better way to solve these? Live regions always have the disadvantage that they speak their data, and then are gone for good. And some stuff that is put in live regions actually shouldn’t, because it might cause over-talking when used for a prolonged period of time. I am a fan of very defensive, cautious use of live regions. You could otherwise quickly overload the user with information they don’t actually need at that given moment.

      1. In general I agree, live regions can be a mixed blessing. There are however instances where it’s important to have dynamic information announced in the correct order regardless how fast this information is being written to the screen.

        A dynamic web chat application is the most obvious usage for this, and may include more than just the message log that needs to be announced, such as typing status messages, user login or logoff announcements, and so on.

        I was able to achieve this using a JavaScript based timing mechanism that updates an offscreen live region with aria-live=polite, which calculates the number of words and punctuation in the message to be announced and then adjusts a millisecond timing delay before writing the next message to that element. This makes it possible to then cancel queued output strings later, such as when closing a chat window.

        Since this technique is entirely unobtrusive, it simply works by calling one Announce method and passing the string to be announced.

        Live demo:

        All the best,
        Bryan Garaventa

Leave a Reply to Marco Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.