Why is accessibility support so bad?

Warning - this is going to be a little bit of a rant. And it’s not really specific to Meteor, except that I’ve encountered all of these issues as a result of learning Meteor.

I recently left (unnamed big company) where I spent the last two years building a library of JavaScript widgets that was used internally in dozens of major apps. One of my goals was to build world-class WAI-ARIA support into the library from the ground up, on both mobile and desktop platforms. I worked closely with a lot of experts in this area, including blind engineers and users. My goal was to make it so that application programmers didn’t have to think very much about accessibility, they would get most of the ARIA goodness for free.

Now I find myself in a new environment, where I’m learning about all of the various frameworks and libraries in the open-source ecosystem such as Meteor and React. And one of the thing that I’m looking at is what’s the state of ARIA / accessibility support. And to say the least, I’m not at all impressed by what I see.

To give a couple of examples: the ARIA authoring guidelines talk about a technique called “tab trapping”, which basically means that when you have a modal dialog up, and you have keyboard focus on the last field or button, the TAB key should wrap around to the first focusable field - it should not navigate to some other random part of the document. This is typically accomplished by placing dummy invisible fields with a tabindex before and after the dialog content, combined with a focus event listener that moves the focus to the first or last field as appropriate. Not terribly hard to do, and ideally this behavior should just be built into the dialog widget so you don’t have to think about it.

And yet, when I look at the most popular widget libraries, not only do they not do this - most of them don’t even support keyboard-based navigation at all! The dialog buttons can’t be tab-navigated, or the keyboard focus indicator is invisible. This doesn’t just affect blind or mobility-impaired users, it affects any user that uses the keyboard instead of a mouse or touchpad.

Another example: when a modal dialog or popup menu is displayed, and the user hits the browser’s ‘back’ button (or the android ‘back arrow’ button which is equivalent), the expected behavior, at least the behavior that is consistent with native apps, is to dismiss or cancel the popup - not to navigate to the previous page. Again, this is fairly easy to implement by inserting a callback into the browser’s history stack when opening the popup. But I haven’t found a single widget library that does this.

I could give more examples but I won’t. I could file bugs but I’d have to file them for every project :smile:

So I guess my question is, 1) are there any JS widget libraries out there that have decent accessibility support (ideally with good Meteor integration), and 2) does anyone even care about this?


does anyone even care about this?

You care about this. Most of those modal libraries are open source, so you could submit PRs to them for WAI-ARIA support.

I think Foundation is a visual framework that cares about accessibility more than the other ones that I use.

You should definitely try out Polymer / have a look at the official paper elements. I know Google invests a LOT of time on accesibility with their library of elements, I’d be very interesting to hear your thoughts on how well they do accessibility and what’s lacking.

I actually have looked at Polymer quite a bit - it’s accessibility support is not terrible, but it could be improved significantly.

And Polymer seems like it would mesh better with the reactive style of coding more than other widget libraries I have seen, due to its use of declarative HTML, as opposed to having to construct the widgets in some JavaScript initialization callback. From a Meteor perspective, you’d treat the Polymer widgets exactly like you’d treat native HTML widgets.

However, one problem with using Polymer in a Meteor context is that the various packages that integrate Polymer with Meteor - at least the ones I’ve found so far - appear to be either very bleeding edge or abandonware.

Can you elaborate? What exactly are you trying to do? Maybe I can show or work on a solution if I know what’s not working for you.

1 Like

That’s generous of you to offer, although I should probably organize my thoughts and start a new thread about issues involved with getting Polymer to work. Stay tuned.


Just for the record, the Clinical track has been doing a lot of work with accessibility…

We have the clinical:keybindings package for hotkey, macro, and accessibility device support. It’s supported directly by our clinical:active-layout package, so all Clinical apps should have out-of-the-box support for keybindings. So, if you use the hello-healthcare app as a boilerplate, for instance, you’ll get basic keybinding already bundled in.

We also have the audio-click package for audio/tactile feedback for blind users. It’s not moved over to the clinical namespace yet, but it’s definately on the roadmap.

Lastly, there’s the leap-ui-progress-circle package for sign-language/gesture recognition systems, neural interfaces, and other low-resolution haptic devices. Both the leap-ui-progress-circle and kevohagan:leapmotion packages are on the roadmap to be migrated over to the clinical namespace for accessibility support and clean-room/surgical environments.

Well, the work I am most familiar with is simply getting web apps to play nicely with screen readers like ChromeVox or JAWS. This is mostly a matter of getting keyboard navigation to work well, which benefits all users, not just visually impaired people using screen readers.

Some other examples that I’ve seen:

  • using arrow keys to navigate through menu items and select items, and handling tab key presses correctly. The wrong way to do it (which I’ve seen examples of) is to have the tab key go to the next item in the list - which means that if you have a list of a hundred items, you have to press tab a hundred times to get to the next widget. The right way is to have tab go to the next widget, and have arrow keys navigate items within a widget.
  • skipping over disabled items in a list - a blind user can’t see items that are grayed out, which means that if the arrow key navigation skips over those items then they have no way to know that such items exist. The correct way is to allow disabled items to be navigated to but mark them as disabled - the screen reader is smart enough to say “list item 3 (title) disabled”.
  • similarly, using arrow keys / spacebar / enter to navigate through and toggle radio buttons.
  • allowing complex widgets like tabs or sliders to be keyboard-driven.
  • properly setting ARIA attributes when widgets change dynamic state, such as selected, disabled, etc.
  • focus rectangles - a lot of visual designers think that keyboard focus rectangles are ugly and hide them, but there’s a way to get the best of both worlds: you have a global CSS class on the body element called “.showFocus”, and then enable that whenever the user hits the tab key, or remove it when they click with the mouse or touch. Then write all your widgets to suppress focus indicators when that class is not present.
  • Letting the screen reader know to read the title of the dialog when it opens. This can be done either via focus changes or by setting various ARIA attributes. (In general, focus changes are the most reliable way to let the screen reader know that something has happened.)

Again, all of this stuff should be provided by the widget library, application developers shouldn’t have to even think about this stuff. App developers do have a responsibility to shun the “divs with click handlers” style of coding, and ensure that all user interactions go through either a native browser control or a 3rd party widget written by an expert in the field.

And of course, everything needs to be tested. At bare minimum, people should test their apps with the ChromeVox extension enabled. Apple’s VoiceOver has lots of quirks so you’ll want to test with that as well, and of course JAWS and the others.

1 Like

It’s definitely a style of programming that’s becoming popular as people chase the ‘native quality’ performance and ditch the various CSS and HTML subsystems. Lots of people not understanding what the tradeoffs are for that ‘slow performance’ that the CSS and HTML parsers impose (tradeoffs such as accessibility support). The one thing I’ll say in that style’s defense is that it works particularly well in test runners and mobile.

Clinical has been trying to use the native browser controls as much as possible, and has been actively shedding things like Bootstrap date/time pickers in favor of their HTML5 equivalents.

We don’t have any particular best-practice with regard to focus and keyboard navigation between elements; and would be happy to look into officially supporting ARIA. Do you have links to standards and specs?

We do have quite a few doctors asking about voice recognition, text parsing, and textual analysis. So we’ll be looking at VoiceOver before long also.

Well, the best place to start is the WAI-ARIA authoring practices document:


Admittedly this is quite a lot to digest, and some of the recommendations only apply to older browsers.

A lot of the techniques I’ve mentioned aren’t complex or expensive to implement, they just need to be done.

Also, VoiceOver is the text-to-speech screen reader used on iOS, which only supports a subset of ARIA. I think you may be thinking of a different product for voice recognition.

Ah, yeah. Good point. I was thinking Dragon Naturally Speaking. But we have general requests for supporting both. Voice-to-text, and text-to-voice. So, it’s on the roadmap. Just have to figure out how to get to all of it.

Thanks for the W3 link. Been awhile since I’ve been there, but now that you bring it up it’s jogging memories.

And interesting that an aria search on Atmosphere only brings up Angular packages. Certainly a reason to consider angular. Google does seem to be doing a better job with the W3 standards than React. I’ll give them that.