<shortdiv />

With 2018 drawing to a close, I’d like to take a moment to review some of my personal highlights from the past year. Attended Recurse Center 2018 was by far the first time that I hit the ground running at the start of the year. I successfully matriculated(?) at the Recurse Center in their first ever mini retreat and spent a full week in January learning and building alongside a bunch of incredibly smart, talented recursers.

If you’ve been keeping up with the JavaScripts, chances are you’ve heard snatches of excitement about the latest and greatest in web technology, WebAssembly. WebAssembly is a binary executable for the web that promises near-native performance for web applications. This means that graphics heavy applications like Photoshop, and AutoCAD can now be run in the browser without the need for clunky third party plugins like Silverlight, Flash and Java Applets.

In the last few years, virtual reality (VR) and augmented reality (AR), also known as cross reality or XR, have developed far beyond the niche realms of the gaming industry. There are now compelling use cases for using XR for building applications focused on education (Aurasma, Math Alive), home improvement (Wayfair, Ikea Place) and even beauty (Meitu) that are accessible to the masses. Despite its growth in popularity, many XR applications today often require the installation of a separate mobile application.

One of the most memorable cinematic portrayals of a voice recognition system is Hal 9000, the seemingly omniscient computer from Stanley Kubrick’s 2001: A Space Odyssey. Hal captured our collective imaginations and opened our eyes to the possible future of a voice based human-computer interaction. Since the movie’s release in 1966, the landscape of voice recognition systems have changed drastically. According a study done by Adobe Analytics over 32% of US consumers own a smart speaker and that number is expected to increase nearly twofold by the end of the year.

The task of building for accessibility, while worthwhile, can be a rather daunting one. Strategies to incorporate it into a product frequently involve a fair amount of work, much of which tends to be manual and admittedly, tedious. The web accessibility community has made many strides to improving this by making accessibility more accessible for developers. In addition to the best practices and recommendations by WCAG, there are many automated tools that make implementing them a breeze.

For most of us, the web is a magical world of media rich content like images, gifs and most importantly, cat videos. Images, however humorous, are the primary means of maintaining user engagement online. Unfortunately, for many users with disabilities and/or other impairments, this rich visual heavy experience of the web remains inaccessible. Assistive devices like screen readers and refreshable braille displays can only interpret text and rely on developers adding alt-text or captions to make sense of images.

Earlier this week, we briefly examined the concept of an accessibility tree, which represents the information model—much like the DOM—that assistive devices use to parse and make sense of a webpage. Unlike the DOM tree which can be queried and modified after the fact via JavaScript APIs, the accessibility tree can only be queried but not modified by assistive technologies. In an increasingly JavaScript heavy web ecosystem, input events like click and hover drive interactivity.

With the rise in popularity of client side, JavaScript frameworks like React, Vue and Angular, it is undeniable that JavaScript is eating the web. This increased reliance on JavaScript isn’t necessarily a bad thing. JavaScript enables us to add interactivity to a page and thereby create more engaging user experiences online. It has also helped address many performance issues with its solutions relating to lazy load and client-side routing via the history API.

When building for the web and making considerations for accessibility, it is easy to fall into the trap of assuming that accessible features only benefit disabled users. While disabled users positively benefit from accessibly designed interfaces, there are many other reasons why a user may similarly leverage keyboard shortcuts or specialized software to navigate websites. For instance, an otherwise able-bodied user may be forced to use assistive technologies as a result of an injury or a recent surgery that make it difficult to navigate a website as they ordinarily would.

As a user without disabilities, I often take for granted the experience of using the web. Browsing and interacting with the web often involves reading visual cues to decipher the general purpose of a particular element. For one, sighted users of the web know that the (now infamous) hamburger icon that sits at the top left of the screen is representative of a clickable menu item. Such assumptions and relationships that we make between icons and their meaning are largely a result of context clues.