Posts

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. Interactions are tailor made to suit specific input controls, so a hover event may open up help text, while changing focus states by clicking away may trigger form validation. These specific mappings between input controls and actions add a layer of fine grained control to the overall user experience. While alternate input controls have access to similar interactions, they still have to rely on DOM updates since they is no way to directly access the accessibility tree. ...

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. JavaScript however, is also a notorious cause of many accessibility issues. For instance, client side routing while enabling navigation without a full page reload, doesn’t get picked up accurately by screen readers. In addition, click and hover only events make apps virtually unusable for keyboard only users. To better understand the role of JavaScript with regards to these accessibility issues, let’s more closely examine how assistive devices are used to navigate the web. ...

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. A user may also choose to use such assistive technologies purely out of personal preference because it allows them to navigate a site quickly and efficiently. It is therefore important for us as developers to build online experiences that don’t discriminate against how a website is accessed. ...

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. We understand that a hamburger icon is a menu item because of its placement in the top navigation bar, which we use to “navigate” a webpage. For visually impaired users, such clues may go completely unnoticed depending on how a screen reader interprets a webpage. This is especially the case when elements are given no additional meaning that can be deciphered and prioritized by a screen reader (i.e. a button is just a button to a screen reader even if it is styled to be a menu button). This is where ARIA comes in. ...

Being a better A11Y It’s almost impossible to think of the world without the web. Compared to other inventions of yore, the web is the single most powerful medium of communication. Through its promise of openness, freedom and independence, the web levelled the playing field. It gave everyone the chance to transcend the limitations of their physical condition regardless of their level of ability. In spite of this promise of inclusivity, the web’s potential as a “global community” was never truly realized. Most of the internet today is a maelstrom of inaccessible iframes, popups and captionless gifs that are near impossible to parse via a screen reader or the tab key. ...

This week, I focused on the many aspects of PWAs and their role in making the web experience more streamlined across browsers and devices. Inherent to PWAs is the concept of progressive enhancement. To the untrained eye, progressive enhancement might seem akin to the concept of “it works without JavaScript”. While this is kinda sorta true (a well built PWA should work with JS turned off 🤞🏾), progressive enhancement is more about using web technologies in a so-called “layered” fashion. This technique of building apps makes them adaptable and allows them to run seamlessly regardless of bandwidth, network connectivity or software. In short, Progressive Enhancement is the deliberate strategy of building apps on the foundation of making it usable everywhere. ...

In the latest stable build of Chrome, came support for desktop progressive web apps (PWAs). Similar to mobile PWAs, desktop PWAs allow users to install apps onto a device’s home screen for quick and easy access. In addition to this, they allow web apps leverage to the numerous capabilities of modern web APIs like authentication, payments and so on, without having to worry about potential security vulnerabilities. After all, a desktop PWA is basically a web browser running in its own app window context. ...

Push notifications are a simple way in which web applications can interact with users to provide them with timely updates and customized content. When integrated with service workers, push notifications allow web applications a more active and engaging experience that was previously reserved for mobile applications. Technically speaking, this feature is possible thanks to the Push API. The Push API is what allows web applications to receive messages from the server, regardless of whether an application or a user agent is active. This API effectively gives developers control over delivering asynchronous notifications and updates to users who have opted in. In theory—if done right—push notifications allow for higher engagement. However, most of the time push notifications are disruptive to user experience. In a sense, push notifications have come to represent the web equivalent of that annoying sales person who hovers over your shoulder as you browse. Even browsers—I see you firefox—have taken to rolling out user settings so you can disable push notifications completely. With this poor sentiment around push, how can we effectively leverage them without being an annoyance to users? ...

Service workers are an important player in the PWA game. Not only are they handy for keeping applications functional while offline, they are also instrumental when it comes to improving overall page load time. Working with a service worker however can be a little tricky. Because they are run in the background of a page (outside of a page’s render cycle) and are registered only once, service workers don’t always work as expected. Contrary to how we normally build and debug for the web, service workers don’t update when the file is updated and the page is refreshed. Depending on your use case, reflecting changes made to a service worker may require either closing the browser tab, refreshing the page or navigating to another page. The reason for this behavior is that the service workers are bound to a specific lifecycle that predetermines whether and how they gain control of the document. The lifecycle of a service worker can be one of the most confusing if not frustrating aspects of working with a service worker. Even so, understanding this lifecycle is the key to unlocking the possibilities that service workers provide. ...

Offline storage is the linchpin of progressive enhancement. Under a low or unreliable network connection, the app is not dependent on a successful response from the server to be operational. Instead, it reads and writes data from a local in browser database while in offline mode. There are several ways to serve data offline. Picking the right option for your PWA ultimately depends on the type of data you’re intending to store and how big it is. ...