So, you want to build an app that has its data co-located with its UI? That works offline? That synchronizes between clients? And that lets its users own their data? Welcome to the world of local-first web development.

When you’re designing and developing for accessibility, performing manual testing using a screen reader is important to catch and fix accessibility issues that cannot be caught by automated accessibility testing tools. In this article, which is a modified, text-only excerpt from the Practical Accessibility course, we’re going to walk through the process of setting up your screen reader testing environment, from downloading virtualization software if you need it, to installing screen readers, and setting up keyboard configuration. We’ll also learn what screen reader and browser combinations are most relevant for your testing work.

My favorite feature of ES6 is Custom HTML Elements. Custom Elements allow us to extend HTML for React-Like components without the need for preprocessors or compilers. There are fewer things “out of the box” for these components, but that means they can be lighter and more readable than react.

gov.uk’s guidance on testing with assistive tech, what to use

Too often folks will grab ARIA first to provide an accessible name for a thing. Or they may sprinkle hidden content around a form. Sometimes this is to satisfy a (minimalist?) design, other times it is just part of the tooling. In most cases the impact of those decisions is unknown. The assumption that they do the same thing, give the same output to all users, is wrong.

Showing buttons as disabled until a form is complete might seem like a good idea. It is not. They usually create a lousy user experience and exclude many people with disabilities. Here’s why disabled buttons suck and what to do instead.

The problem with disabled buttons and what to do instead

The most surprising thing I learned was that, when screen readers process web pages, they very often inject their own code into the running web browser application process in order to extract information. Know what else does this? Malware. Know what else? Basically nothing.

Most introductions to accessibility APIs include a similar but shorter and simplified history lesson. This one collects details only found in one or the other, or none of them, throws in some trivia for fun, and cites what my ex-professor brain thinks of as primary sources. Grab your machete, because we’re heading into weeds so tall that a tiger couldn’t find its way home from an Indian buffet without GPS.

we’ll start from absolute scratch and recount the widely available basic story. It’s written for beginners, but the fact that I describe web accessibility in the broader context of software accessibility might offer a different twist for current practitioners as well.

To understand the role of an accessibility API in making Web applications accessible, it helps to know a bit about how assistive technologies provide access to applications and how that has evolved over time.

Building proper UI Web Components can be quite a task though, especially if you want them to be accessible. Here are some pointers on what to look out for.

This is about designing forms that everyone can use and complete as quickly as possible. Because nobody actually wants to use your form. They just want the outcome of having used it.

If you’re writing anything more complicated than a brief command-line script, reading this should help you write higher-performance, more-secure applications. This document is written with Node.js servers in mind, but the concepts apply to complex Node.js applications as well. Where OS-specific details vary, this document is Linux-centric.

Honestly? I’m saving this because it is a good bit of documentation writing more than it is useful to me as reference.

So, you want to build an app that has its data co-located with its UI? That works offline? That synchronizes between clients? And that lets its users own their data? Welcome to the world of local-first web development.