JavaScript and Accessibility

There has been a lot of talk in the last couple of weeks about whether JavaScript is needed or not, mainly caused by Nolan Lawson's presentation Offline, progressive, and multithreaded:
A peek at webapps of the future at Fronteers 2016 and this recently released resource (alliteration, yes!) You Might Not Need JavaScript (YMNNJS). There have been many responses on both sides that make valid points. One specific response that caught my eye was in regards to the patterns presented at the YMNNJS site; while they did not require JS, they were lacking in accessibility and this is even more dangerous than not having JavaScript.

One thing I see often, and this comes in almost all things, is that arguments/ responses come from the extreme sides. JS experts vs a11y experts. In my experience, most people I know are either one or the other. Please don't be offended by that, it's just my experience. If that's not true about you, it's not true. It's the same with designers vs developers, most designers do not have an interest in development and most developers have no sense of design. This is not a 100%, there are always unique exceptions like the unicorns at Zurb who are uniquely designer/ developer hybrids. I am extremely jealous of these types.

Maybe it's left brain vs right brain? Or maybe it's just the fact that it takes a lot of time and effort to master these things and people just choose what they are most interested in. The web is a unique place where if you want to be successful working on the front end in this fast paced environment, where tools can make up for skills/ talent, you probably need a little working knowledge of everything.

You Don't Need JavaScript, But...

In bringing everything together, my initial reaction was the above tweet. The truth of the matter is that you don't need JS to be accessible, you don't even need JS to have a functioning site or application. However, as I mentioned, that would be a very boring, clunky experience on the web these days. JS has opened up a world of amazing interaction and dynamism. So here is where I need to start unpacking things.

You do NOT need JS to be accessible. You can meet WCAG guidelines without ever using a line of JS. HTML, in it's most raw and basic form, is very accessible and has been from the very beginning because of native semantics. But raw and basic is not exciting, you are short-changing the platform and all of it's glorious capabilities if that is where you stop. You DO need JS if you want any kind of dynamic, interactive experience, the kind that users like and expect and improves usability. I think this is what Nolan meant with his infamous statement that in 2016, it's ok to build something that requires JS.

The danger with JS is that you can make anything dynamic/ interactive. It is too easy to engineer anything you need in a clever way. Unfortunately, this leads to a lot of over-engineering. Take an arbitrary element and add a few event listeners, and you can create anything. This is where we start running into issues because accessibility usually get's dropped.

ARIA? Not So Fast...

For those that are over-engineering components and have a familiarity of accessibility, it's too easy to just throw in a bunch of ARIA. I can honestly appreciate the effort, but with JS you do NOT need ARIA to be accessible either. You can use JS to update native element properties and states. However, as with all things, there is a limit where you probably will need ARIA to fill in gaps, in either HTML or in assistive technologies. Some advanced components will require it.

The classic example is making your own custom button. You can completely engineer an accessible, fully functioning button component using JS with ARIA. Or, you can use a lot of code to engineer a toggle control, aka <input type="checkbox">, as demonstrated in this Polymer video Accessible Components: Keyboard access. You could also drive with your feet but it's not the smartest thing to do if you don't have to, unless you are just proving that you can.

This is why some people are very adamant in expressing "DON'T USE ARIA!" Just like JS, it's too easy to abuse in your quest to over-engineer and sometimes too much ARIA is worse than no ARIA at all. ARIA has it's place, especially if you are building interactive, dynamic functionality. I think the more complete statement would be "Don't use ARIA if you don't know what you are doing!"

But What's the Problem?

For me, I am overly critical when the solution becomes the problem. The main strength of progressive (/enhancement|web app/) is performance, and fastest time to interactivity and usability. They're means to getting (all) users what they need as quickly as possible. When our solution becomes the blocker, then we most likely will have to engineer our way out with a new solution putting you deeper in the hole. We pushed all responsibilities to the client with JS and then needed to come up with a way to load/ parse faster. We ripped out the native accessibility by creating our own frankenstein components and then added it back in with ARIA. That just sounds like insanity to me. We do it all the time though, and pat ourselves on the back for being geniuses.

So What's the Point?

In this fast paced environment "Don't" and "Always" never last long. There is a lot of nuance to what we do daily, and unfortunately sometimes it's just easier to say DON'T to avoid having to explain all the nuance or to prevent abuse. The easier thing to do is use the platform and its pieces for what they were made for. Everything has it's place. Maybe I am just lazy, but I would rather take what the platform gives me and then enhance for functionality, compatibility, or accessibility. Yes, maybe I am old school for still believing in clear separation of concerns: HTML for semantics, CSS for presentation, and JS for dynamism and interactivity. Sometimes you need to cross over and blur the lines a bit, but that should be an exception instead of rule. You have to learn the rules if you want to break them properly. I promise you, it's a lot easier to just learn HTML and CSS than it is to try to figure out how to do everything in JS. That is a lot of responsibility and you are just increasing your surface area for bugs.

The way we have pushed the web has been nothing short of unbelievable and astonishing. I am so happy to be a part of it but somehow it feels as though we are killing it and giving it life at the same time.

Recommendations

If you are a JS expert and want to learn more about accessibility, I suggest you start following people like Steve Faulkner and Karl Groves. Heydon Pickering is also a good person to follow as he is good mix of accessibility and usability with simple solutions. WebAIM is a good resource to read. I'd also have to recommend my courses on Pluralsight.

If you want to learn more about JS, you should definitely follow Eric Elliot and Kyle Simpson.

That is just short list of people you can learn from, for a more expanded list of my recommended follows, check out My Acceptance Speech.