DEV Community: Ben Myers

What is your most complex focus interaction?

Ben Myers — Wed, 19 Aug 2020 01:11:21 +0000

Web accessibility folks, especially those working in web apps... what is the most complex focus interaction on your site? What makes it complex, and how do you address it?

I'm especially interested in cases where you have to programmatically move the user's focus. Additionally, I'd love to know your stack, and whether you feel that stack helps or hinder your focus management.

TIL About .bold(), .blink(), and More JavaScript String Methods

Ben Myers — Fri, 21 Feb 2020 02:48:13 +0000

While playing around in the Chrome DevTools, I noticed a string method I had never seen before: .bold(). Curiosity got the better of me, and I gave it a try.

let myString = 'Hello World!';
myString.bold(); // returns "<b>Hello World!</b>"

It's a method that returns the string wrapped in a <b> tag. It's very deprecated, but all major browsers still support it.

.bold() is not alone - I've found several other string methods that are in the same boat. Again, these are all deprecated, and should not be used in the wild.

.anchor(name): Returns the string wrapped in <a> tags with the name attribute set to the given name
.big(): Returns the string wrapped in <big> tags.
.fixed(): Returns the string wrapped in <tt> tags.
.fontcolor(color): Returns the string wrapped in <font> tags with the color attribute set to the given color
.fontsize(size): Returns the string wrapped in <font> tags with the size attribute set to the given size
.italics(): Returns the string wrapped in <i> tags.
.link(url): Returns the string wrapped in <a> tags with the href attribute set to the given URL
.small(): Returns the string wrapped in <small> tags.
.strike(): Returns the string wrapped in <strike> tags.
.sub(): Returns the string wrapped in <sub> tags.
.sup(): Returns the string wrapped in <sup> tags.

... and, of course, my personal favorite: .blink(), which returns your string wrapped in a <blink>.

As with .bold(), these methods are all officially deprecated. Several of them even wrap your strings in tags that have long since been deprecated. These methods remain in browsers for the sake of backwards compatibility, an artifact of development past.

CSS Influences Screenreaders

Ben Myers — Fri, 14 Feb 2020 02:23:19 +0000

This was originally posted on my blog, where I've included inline examples.

Introduction

Let's say we're building a shopping list app. As we build out the app, we decide to style the list, stripping out the bullets that the browser gives us by default.

Being dutiful accessibility testers, let's run our screenreaders over the two lists. Pause for a moment and ask yourself: do you expect any difference between how the two lists are announced? Why or why not?

I was able to test the two lists with NVDA for Windows and VoiceOver for macOS. I ran NVDA against the lists on Chrome, Firefox, and even Internet Explorer. I ran VoiceOver against Chrome and Safari. Here's what I found:

When I tested against the first, bulleted list, the screenreaders always told me how many items were in the list and preluded each list item with "bullet."
When I tested against the second, bulletless list, the screenreaders never said "bullet."
Most surprisingly, Safari with VoiceOver didn't treat the bulletless list as a list at all, omitting any announcements about how many items were in the list.

... Huh.

As we keep building our hypothetical shopping list app, we implement a feature to let users add new items, complete with a shiny new "Add" button. We'll even set it to be all uppercase with CSS.

Upon testing the page with screenreaders, our screenreader's readout confirms that it is receiving the "ADD" text in all caps. Usually, it's totally fine for a screenreader to receive a word in all caps—they're usually smart enough to realize it's just a capitalized word. If you navigate to the above button with VoiceOver, however, you'll learn that VoiceOver has confused the capitalized "ADD" button for the acronym A.D.D.—something it definitely wouldn't have done if we hadn't changed the CSS.

These cases of CSS messing with our screenreader announcements are initially shocking, perplexing, and maybe even appalling. After all, they seem to conflict with our mental model of CSS, one that's likely been instilled in us since we started learning web development: HTML is for content, and CSS is for visual appearance. It's the separation of content and presentation. Here, by changing what screenreaders announce, it feels like CSS is encroaching on content territory.

What is happening here? Do we need to worry about every CSS rule changing screenreader announcements?

Smart Browsers

Screenreaders aren't actually looking at the CSS.

Browsers package up an alternate version of the DOM, called the accessibility tree, which it passes to the user's operating system for screenreaders and other assistive technology to consume. Every element in the tree is defined as a set of properties that describe the element's purpose and functionality. Screenreaders peruse the tree to know what to announce. Thanks to the hard work of browser engineers, browsers have gotten really smart about building the tree. They can account for web developers' tricks—whether best practices or bad habits—and curate a more usable accessibility tree.

As much as the web development community talks about the separation of content and presentation, the truth is that it's not that easy. Between using pseudo-elements and toggling display: none; on elements to show or hide them, it's clear there can be a bit of a gray area between content and its presentation. This gray area provides a key space for browsers to optimize their accessibility trees, giving all screenreader users the same experience of the content as sighted users.

CSS's Potential Influences on Screenreaders

What kinds of CSS-based optimizations or modifications do browsers make to the accessibility tree? Below, I've listed a few kinds that I know of. I'm sure it's not exhaustive. More importantly, these impacts will depend heavily on the user's choice of operating system, browser, and assistive technology. On the WebAIM blog, John Northup cautions us,

"It’s tempting to assert that if you do x, 'the screen reader' will announce y. Sometimes it really is just that simple, but in a surprising number of situations, it just isn’t that absolute."

Be sure to test each of the following on many different browsers and with many different screenreaders.

CSS-Generated Content

The clearest instance of CSS-as-content is pseudo-elements, which can inject content into the page without adding it to the DOM. For instance, Firefox and Safari both support the ::marker pseudo-element, which injects a bullet point, number, or other indicator before a list item.

We can also use the ::before and ::after pseudo-elements to inject content.

If you navigate to the above button with a screenreader, you'll likely hear something like "button, pencil, Edit," assuming your screenreader supports emojis. Lately, browsers interpret the content defined in pseudo-elements as... content. It impacts how sighted users experience the page (and users don't really care whether their content is real content or pseudo content), so browsers judge that they need to expose it to screenreaders.

This judgment call comes from the W3C specs for determining an element's accessible name, i.e. how it's announced by screenreaders:

Check for CSS generated textual content associated with the current node and include it in the accumulated text. The CSS :before and :after pseudo elements can provide textual content for elements that have a content model.

For :before pseudo elements, User agents MUST prepend CSS textual content, without a space, to the textual content of the current node.

For :after pseudo elements, User agents MUST append CSS textual content, without a space, to the textual content of the current node.

—Accessible Name and Description Computation 1.1, Step 2(F)(ii)

Hidden Content

Sometimes, we find ourselves wanting to hide something visually, but still expose it to screenreaders, usually to provide a hint for context that would be obvious visually. In these cases, it's tempting to specify display: none;. That would hide the contents, but still leave them in the DOM. Mission accomplished, right?

However, display: none; is generally used as a toggle, to save the trouble of recreating and reinserting content on command. For instance, you could use display: none; for inactive tab panels or for whichever slides the carousel is not showing at the moment. When display: none; is applied to an element, the assumption is generally that users will not be able to experience that element, and often that it would be confusing or misleading for them to.

Browsers take display: none;, as well as similar rules such as visibility: hidden; and width: 0px; height: 0px;, as cues that the elements aren't meant to be read by anyone, and will remove the relevant elements from the accessibility tree accordingly. This is why we resort to tricks such as placing the elements far off screen or clipping the elements to be really small to expose information to screenreader users only.

Nullifying Semantics

When a user reaches a list in Safari, VoiceOver will usually say something like "list, 2 items." When the user navigates between items, VoiceOver tells them where they are in the list, e.g. "1 of 2." However, as we saw earlier, applying list-style: none; to the list changed the user's experience entirely. VoiceOver no longer said "list, 2 items," nor did it tell the user how far into the list they were. Instead, it just treated every item as a plain text node. It seems as though Safari's engineers decided lists without bullets or other markers aren't listy enough, and decided to instead nullify the list's semantics. Alternatively, it could be a bug.

Tables are another area where CSS can lead to changed semantics. Even though tables are supposed to represent tabular data, developers used to (and still sometimes do) put pieces of the page into a table in order to define the layout in terms of rows and columns. In these cases, table semantics are inaccurate.

Browsers like Chrome and Firefox will make an educated guess at whether a table is used for layout. One factor they consider is tablelike styling such as zebra striping. On the other hand, specifying display: block|flex|grid on a table element seems to be an instant disqualifier for tablehood, and causes browsers to blow away the table's semantics.

Apparently, display loves changing if and how elements are announced by screenreaders...

An Obligatory Mention of the CSS Speech Module

It doesn't quite fit into this post's theme of browsers optimizing accessibility trees, but a post about how CSS can influence screenreaders would be remiss without a mention of CSS Speech.

CSS2 contained specs for aural stylesheets, which could define speech synthesis properties for screenreaders and any other device that would read a webpage aloud. These properties included volume, pitch, family (i.e. which voice was even used), audio cues that could be announced before and after elements, and more. This was replaced by the speech media type in CSS 2.1, which had no defined properties or values. It was just a reserved keyword.

In 2012, W3C released the CSS Speech Module for CSS3 as a Candidate Recommendation to get implementation experience and feedback before formally recommending it. The module was fairly similar to the old aural stylesheets of CSS2, with some additions. For instance, the new speak-as property dictated how verbose speech synthesizers would be when reading out an element—e.g. spelling out every letter, reading digits individually, or announcing every punctuation mark. Additionally, we could distinguish regular content and live alerts with different voices. However, the module received limited support, and was retired in 2018.

As of February 2020, it seems like the CSS Speech Module might be making a comeback with a new Candidate Recommendation. If this recommendation sees a more widespread adoption, we can expect to use CSS to influence screenreaders even more.

Conclusion

With CSS, there is a gray area, for better or for worse, between content and its presentation. When CSS bleeds into content, it can convey important information that might be lost to screenreader users. Browsers have gotten really smart about how they expose that information to screenreaders, but that means that our styles can change screenreader users' experience in unexpected ways. As always, be sure to test with many screenreaders on many browsers and many platforms.

New Year, New Terminal: Alias Your Directories the Windows Way

Ben Myers — Thu, 02 Jan 2020 02:15:32 +0000

This article covers how to alias your directories on Windows, and was originally published on my blog. Additionally, you may be interested in the Unix way.

Introduction

I admit it. I'm a sucker for creating little shortcuts and scripts to speed up work in my terminal. There's just something oddly thrilling about typing a few characters and kicking off several commands. I recently read Chiamaka Ikeanyi's Avoiding Shell Hell: Aliases to the Rescue, and I was inspired to share some alias tricks I use on a daily basis.

My team at work manages six projects. Each project has its own repository. Additionally, we have repositories for developer tools made by the team. Combine that with any other directories we use on a daily basis, and cd quickly becomes our most frequent command.

My favorite terminal trick, for both my home and work computers, is creating short, memorable aliases to cd to my most frequent directories. If I want to write a new post, I just type blog and I'm in my Gatsby codebase. If I need to tweak the response from a mock server, I type mock, and I can start poking around my Express.js code. I rarely have to worry about long, complex relative paths. The terminal feels snappier, more intuitive, and—best of all—more fun.

Creating Aliases with Doskey

You'll want to pick a frequently used directory and a memorable command you'll use to hop to that directory. In my case, I want to run the blog command to go to C:\Ben\blog.

In Windows, you can use the doskey command to create aliases to use in Command Prompt. Open up Command Prompt and run the following:

C:\> doskey  blog=cd  C:\Ben\blog
C:\> blog
C:\Ben\blog>

It works like a charm! However, if you close and reopen Command Prompt, you'll run into a bit of a problem:

C:\> blog
'blog' is not recognized as an internal or external command,
operable program or batch file.

doskey aliases don't persist between sessions. Instead, we have to put them in a persistent batch file.

Persisting Doskey Aliases

Whereas Unix has .bashrc that runs with every new terminal session, Windows has no such files. We'll need to create our own.

Create a .bat file. You can call it whatever—aliases.bat, scripts.bat, doskey.bat…—so long as it works for you. I'll call mine aliases.bat and place it in the home directory.

Inside this batch file, I'll put:

@echo off
doskey blog=cd C:\Ben\blog\

(That @echo off is to make sure the terminal doesn't vomit out the whole aliases.bat file whenever you start a new session.)

The next step is making sure Command Prompt knows to run your batch file whenever you start a new terminal session. To do this, we need to make a change to the Windows Registry—your Windows machine's operating system-level configurations. We'll add a configuration that specifies that whenever Command Prompt starts a new session, it should automatically run aliases.bat.

Open the Registry Editor. Open up the Start menu, and search for regedit. Click the Registry Editor result.
Navigate to the Command Processor settings. This can be found at HKEY_CURRENT_USER → Software → Microsoft → Command Processor.
Add an AutoRun value. Right-click inside Command Processor and choose New → String Value. Give the new property the name AutoRun. Make the value the absolute path to your batch file of aliases.

Open a new session of Command Prompt, and try out your new aliases!

C:\> blog
C:\Ben\blog>

You're good to go!

Adding Persistent Doskey Aliases on the Fly

I like having an alias for just about any directory or workspace I might come back to. Manually modifying aliases.bat and restarting my terminal every time I create a directory would interrupt my flow, however. Instead, I have a batch script that automatically creates a persistent doskey alias to the current working directory whenever I use the ad command.

Create a folder to store your scripts in. I called my folder C:\Ben\Batch, but you can call it Scripts or Commands or any other meaningful name.
Add your scripts folder to your PATH. If you haven't done this before, check out Ryan Hoffman's quick guide. When you run an unfamiliar command, the terminal checks all directories listed in the PATH to see whether any of them have a script or executable file with the same name. For instance, if you run ad, the terminal checks all directories in the PATH for an executable file called ad.
Create an ad.bat inside your scripts folder. By calling this file ad.bat, you ensure that the file is executed whenever you run the command ad. If you'd prefer to use a different command, you can choose a different name. Paste the following into your new batch file:

@echo off
SETLOCAL

REM Verify exactly one argument was passed
if "%~1"=="" goto usage
if not "%~2"=="" goto usage

REM Verify alias doesn't already exist
for /f "tokens=*" %%a in ('doskey /macros:all ^| findstr %1=') do set foundAlias=%%a
if not "%foundAlias%"=="" goto alias_exists

goto add_alias

:usage
echo USAGE: ad ^<alias^>
exit /b 1

:alias_exists
echo Alias already exists!
exit /b 1

:add_alias
echo.doskey %1=cd %cd% >>"C:\Ben\aliases.bat"
call "C:\Ben\aliases.bat"
echo Alias was added successfully!
exit /b 0

Replace the paths in lines 23 and 24 with the absolute path to your aliases.bat.
Make sure your aliases.bat file ends in a trailing newline. You'll only need to do this once, unless you manually add stuff to your aliases.bat later, but this tripped me up for an embarassingly long time.
Open a new session of Command Prompt and alias a directory.

C:\> cd Ben\Advent_Of_Code_2019
C:\Ben\Advent_Of_Code_2019> ad advent
Alias was added successfully!
C:\Ben\Advent_Of_Code_2019> cd ../..
C:\> advent
C:\Ben\Advent_Of_Code_2019>

I'm still very new to batch scripting, so if you find a problem with this script or a way to improve it, please reach out!

Conclusion

Tweaking my terminal makes programming a more delightful experience for me, and it can for you, too. By aliasing cd commands to your most frequently used directories, you cut down on having to juggle potentially long absolute or relative paths. Using the terminal becomes faster, more intuitive, and personal. What's not to love?

New Year, New Terminal: Alias Your Directories the Unix Way

Ben Myers — Thu, 02 Jan 2020 02:15:14 +0000

This article covers how to alias your directories on Unix, and was originally published on my blog. Additionally, you may be interested in the Windows way.

Introduction

Creating Aliases

Pick a directory you use often, and a memorable alias you'll use to hop to that directory instantly. In my case, I want to go to my ~/blog directory whenever I use my blog alias.

Let's give it a shot! In your terminal, run the following commands:

~$ alias blog="cd ~/blog"
~$ cd some/other/directory/
~/some/other/directory$ blog
~/blog$

No matter which working directory we're in, issuing the blog command now takes us directly to ~/blog. Mission accomplished! We can close our terminal and call it a day.

Next time, we can just open up our terminal and...

~$ blog
-bash: blog: command not found
~$

... oh.

Aliases only last as long as the terminal session. Since manually reestablishing our aliases every time we open the terminal would be a bit of a hassle, let's find a way to make our aliases persist.

Persisting Bash Aliases

When you start a new interactive shell, your terminal runs a file called .bashrc, found in your root directory. Open ~/.bashrc in your editor of choice. I'm using VS Code, but you could also use vi, emacs, nano, Atom, or whatever other editor floats your boat:

~$ code ~/.bashrc
~$

(If .bashrc doesn't exist, go ahead and create it!)

We can drop our new alias in and save:

alias blog="cd ~/blog"

Back in our terminal, we tell our terminal to rerun .bashrc and receive our new aliases:

~$ source ~/.bashrc
~$ blog
~/blog$

In future terminal sessions, you won't even have to run source, since the terminal takes care of that for you. You'll be able to just run blog to your heart's content.

But Wait! I Have a Mac!

The default macOS Terminal inexplicably treats every terminal session as a login session. This means that instead of running ~/.bashrc on every session, the macOS Terminal runs ~/.bash_profile. Cue facepalm.

You can account for this by just stuffing your aliases in .bash_profile. However, if you think you might want to use a different terminal at some point, the more resilient approach would be to have your .bash_profile source .bashrc on every login:

if [ -r ~/.bashrc ]; then
    source ~/.bashrc
fi

For more information, read this handy Scripting OS X guide to .bash_profile and .bashrc.

Adding Bash Aliases on the Fly

We can use Bash scripting to be even cuter about aliasing our directories. I like having an alias for just about any directory or workspace I might come back to. Manually modifying .bashrc and re-sourcing every time I create a directory would interrupt my flow, however. Instead, I have a quick script that automatically creates a persistent alias to the current working directory whenever I use the ad command.

Copy the following into your ~/.bashrc:

function ad() {
    if [[ "$#" -ne 1 ]]
    then
        echo "USAGE: ad <alias>"
        return 0
    elif [[ -n "$(alias $1 2>/dev/null)" ]]
    then
        echo "Alias already exists!"
        return 0
    fi

    echo -e "alias $1=\"cd $(pwd)\"" >> ~/.bashrc
    source ~/.bashrc
    echo "Alias was added successfully."
}

The interesting lines are 12 and 13 — the rest is just sanity checks.

Let's give our new ad command a whirl! If you're using an old terminal session, update your terminal's aliases with source ~/.bashrc. Then try using ad:

~$ cd ./codebase/Advent_Of_Code_2019
~/codebase/Advent_Of_Code_2019$ ad advent
Alias was added successfully.
~/codebase/Advent_Of_Code_2019$ cd ~
~$ advent
~/codebase/Advent_Of_Code_2019$

ad has so thoroughly integrated itself into my day-to-day development work that I don't often create a new directory without instantly creating an alias for it.

Conclusion

What Is ARIA?

Ben Myers — Sat, 07 Dec 2019 17:04:33 +0000

This post was originally published on my blog. I recommend reading it there, mainly because the examples are better embedded.

Introduction

It's no secret that today's websites are increasingly complex. Webpages now more closely resemble dynamic, living applications. Developers combine and style HTML elements to create new user experiences. However, it can be challenging for disabled users' assistive technologies to make sense of this new world.

One tool devised to solve this problem is ARIA. Short for Accessible Rich Internet Applications, ARIA is a subset of HTML attributes (generally prefixed with aria-) that modify how assistive technologies such as screenreaders navigate your page.

Unfortunately, developers often misunderstand ARIA and misapply it, which leads to worse experiences for disabled users. In 2017, the web accessibility resource WebAIM reported:

"When WebAIM evaluates a client’s website for accessibility, we often spend more time evaluating and reporting on ARIA use than any other issue. Almost every report we write includes a section cautioning against ARIA abuse and outlining ARIA uses that need to be corrected or, most often, removed."
—Jon Whiting, To ARIA! The Cause of, and Solution to, All Our Accessibility Problems

In their August 2019 analysis of the one million most popular homepages, WebAIM found that ARIA usage had increased sharply over the previous six months, and that the increased use of ARIA was strongly correlated with an increase in accessibility defects on the page.

Jared Smith

@jared_w_smith

I’m crunching data for the WebAIM Million re-analysis. The single strongest indicator that a page will have numerous accessibility errors is whether ARIA is present. Pages with ARIA have 65% more issues than those without. And it’s getting worse. This is VERY disturbing!

18:50 PM - 29 Aug 2019

The WebAIM report is quick to remind us that correlation does not imply causation. It suggests that more complex homepages and the use of libraries and frameworks could lead to both more situations requiring ARIA and more bugs. That said, it still seems like there's a lack of understanding around what ARIA is and how it should be used well.

This could be because there are a lot of ARIA attributes, each with their own (admittedly, sometimes niche) use cases. This can make ARIA seem unapproachable.

Additionally, ARIA isn't always included in web development resources. When it is, it's often handwaved away as just making the element ✨more accessible✨. A friend of mine admitted to copying ARIA from example code because the docs promised exactly that. Without the context of what ARIA does, it's totally reasonable for developers to assume that more ARIA means better accessibility, so you might as well go all in.

So, today: what ARIA is, what it does, why you should use it, and when you shouldn't.

Revisiting the Accessibility Tree

In my last post, I introduced the accessibility tree: an alternate DOM that browsers create specifically for assistive technologies. These accessibility trees describe the page in terms of accessible objects: data structures provided by the operating system that represent different kinds of UI elements and controls, such as text nodes, checkboxes, or buttons.

Accessible objects describe UI elements as sets of properties. For example, properties that could describe a checkbox include:

Whether it is checked or unchecked
Its label
The fact that it even is a checkbox, as opposed to other elements
Whether it is enabled or disabled
Whether it can be focused with the keyboard
Whether it is currently focused with the keyboard

We can break these attributes into four types:

Role: What kind of UI element is this? Is it text, a button, a checkbox, or something else? This lays out expectations for what this element is doing here, how to interact with this element, and what will happen if you do interact with it.
Name: A label or identifier for this element. Names are used by screenreaders to announce an element, and speech recognition users can use names in their voice commands to target specific elements.
State: What attributes about this element are subject to change? If this element is part of a field, does it have a value? Is the current value invalid? Does this field have a disabled state?
Properties: Functional aspects of an element that would be relevant to a user or an assistive technology, but aren't as subject to change as state. Is this element focusable with the keyboard? Does it have a longer-form description? Is this element connected to other elements in some way?

These qualities encompass everything a user might want to know about the function of an element, while omitting everything about the element's appearance or presentation.

Good Markup Means Happy Trees

Semantic markup refers to using the native HTML elements that best reflect the desired experience. For instance, if you want an element that, when clicked, submits a form or performs some action on the page, it's usually best to use a <button> tag. When we write semantic HTML, the browser has a much easier time picking out the right accessible objects. Additionally, the browser can do the heavy lifting to make sure the accessible objects have all of the necessary properties, without any extra effort on our part.

However, semantics can only get us so far. Sometimes we want newer, more complex experiences that semantic elements just don't support yet, such as:

Messaging that is subject to change, including error messages
Tabs, tablists, and tabpanels
Tooltips
Toggle switches

What do we do in these cases? It's still important to engineer these experiences in ways that assistive technologies can understand. First, we get as far as we possibly can with semantic markup. Then, we use HTML's ARIA attributes to tweak the accessibility tree.

ARIA doesn't modify the DOM or add new functionality to elements. It won't change elements' behavior in any way. ARIA exclusively manipulates elements' representation in the accessibility tree. In other words, ARIA is used to modify an element's role, name, state, and properties for assistive technologies.

That's great in theory, but how does it work in practice?

Introducing the Toggle

Take a look at this toggle switch:

If you click the toggle, you'll trigger dark mode. Click it again and you'll go back to light mode. The toggle is even keyboard-navigable—you can tab to it and trigger it by pressing Space.

It does have a bit of a problem, though. If you navigate to it with a screenreader, you'll hear something like this:

This is... underwhelming.

Screenreader users will have no idea what this element is, or what it's for, or even that it's clickable. Users of other assistive technologies will be similarly frustrated. This is what we in the business call A Problem™. Fortunately, we can try to fix this with ARIA. We'll explore how ARIA modifies names, roles, states, and properties by adding ARIA attributes to this dark mode toggle.

If you'd like to pull the code locally to follow along, you can clone it from GitHub. If you don't have a screenreader to follow along with, follow these steps to view your browser's accessibility tree.

First up, how do we make sure assistive technologies know that our element is a toggle instead of a group?

Role

The browser doesn't really know what to make of our toggle, or how best to expose it to assistive technology. Because our toggle is just a <span> with another <span> inside of it, the browser's best guess is that this is a generic group of elements. Unfortunately, this doesn't help users of assistive technologies understand what this element is or how they should interact with it.

We can help the browser along by providing our toggle with a role attribute. role can take many possible values such as button, link, slider, or table. Some of these values have corresponding semantic HTML elements, but some do not.

We want to pick the role that best describes our toggle element. In our case, there are two roles that describe elements that alternate between two opposite states: checkbox and switch. These roles are functionally very similar, except that checkbox's states are checked and unchecked, and switch uses on and off. The switch role also has weaker support than checkbox. We'll go ahead and use switch, but you're free to use checkbox on your own.

When we navigate to our toggle with a screenreader now, we get a more accurate description of this element:

When I lingered on this element for a bit with VoiceOver active, VoiceOver told me how I could interact with the element using the Space key:

Assistive technologies can now use these roles to provide extra functionalities that make navigating the page easier for disabled users. For instance, when a user issues a "click button" voice command, the Dragon NaturallySpeaking speech recognition software will light up all of the buttons on the page. Screenreaders often provide shortcuts for navigating between different elements of the same role—JAWS provides hotkeys and VoiceOver provides the Rotor for this purpose.

Importantly, a role is a promise. You're promising to users that they can interact with elements in a certain way and that they will behave predictably. For instance, users will expect the following from switches:

They can be clicked
They can be focused on with the keyboard
When the switch is focused, it can be triggered by clicking Space
Triggering the switch will cause something to toggle

Specifying an element's role will not auto-magically add any of that expected functionality. It won't make our element focusable or add key events. It's up to the developer to follow through on that promise. In the case of our toggle, I've already handled this with tabindex and by adding a keydown event listener.

It's great that users and assistive technologies know our element is a toggle switch. Now, though, they might be asking themselves... a toggle switch for what?

Name

An element's accessible name is its label or identifier. Screenreaders announce an element's name when the user navigates to that element. Speech recognition users may also use an element's name to target that element in a voice command. Images' names come from their alt text, and form fields will get their names from their associated <label> elements. Most elements get their names from their text contents.

Sometimes, the default accessible name isn't good enough. Some cases where manually setting the accessible name would be justified include:

Short, repeated links like "Read more" whose context is made clear to sighted users, but which need more context to make them distinct to assistive technologies
Icon buttons that have no meaningful text contents
Regions of the page that should be labeled so that assistive technologies can build a skimmable page outline

ARIA offers two attributes for modifying an element's name: aria-label and aria-labelledby.

When you specify aria-label on an element, you override any name that element had, and you replace it with the contents of that aria-label attribute. Take a button that just has a magnifying glass icon. We could use aria-label to have screenreaders override the button's contents and announce "Search":

<button aria-label="Search">
    <svg viewBox="0 0 22 22">
        <!-- Some magnifying glass SVG icon -->
    </svg>
</button>

Let's add aria-label to our toggle:

If you navigate to the switch with a screenreader now, you'll hear something like this:

Adding a label has gone a long way towards making this element understandable.

aria-label is best used when there isn't already some visible text label on the page. Alternatively, if we already have a label on the page, we could use aria-labelledby. aria-labelledby takes a text label's id, and uses that label's contents as an accessible name.

For instance, we could use aria-labelledby to use a header as a label for a table of contents section. The <section> uses the heading's id to specify which element should serve as its label. As a result, the whole table of contents section is named "Table of Contents."

<section aria-labelledby="toc-heading">
    <h1 id="toc-heading">
        Table of Contents
    </h1>
    <ol>
        <!-- List items here -->
    </ol>
</section>

This approach is very similar to using a <label> element's for attribute, except it works for all elements, not just form fields.

Here's what our toggle example would look like if we used aria-labelledby instead of aria-label:

Note: While writing this article, I learned that screenreaders may disregard aria-label and aria-labelledby for static elements. If your labels aren't working, make sure your element has either a landmark role or a role that implies interactivity.

State

When I navigate to our toggle with my screenreader, it tells me that it's in an "off" state. However, when I trigger the toggle... it still says it's off. We need a way to let assistive technologies know when the toggle's state has changed.

ARIA state attributes describe properties of an element that are subject to change in ways that are relevant for the user. They're dynamic. For instance, collapsible sections let users click a button to expand or collapse the contents. When a screenreader user is focused on that button, it would probably be helpful if they knew whether the contents were currently expanded or collapsed. We could set aria-expanded="false" on the button and then dynamically change the value whenever the button is clicked.

Another ARIA state attribute worth mentioning is aria-hidden. Whenever an element has aria-hidden="true", it and any of its children are immediately removed from the accessibility tree. Assistive technologies that use the tree will have no idea that this element exists. This is useful for presentational elements that decorate the page but would create a cluttered screenreader experience. aria-hidden can also be dynamically toggled, e.g. to obscure page contents from screenreaders when a modal overlay is open.

Returning to our toggle, elements that have specified role="checkbox" or role="switch" expect that the element will have the aria-checked state attribute, and that it will alternate between "true" and "false" whenever the toggle is triggered.

The following example demonstrates how we can use JavaScript to change aria-checked:

Try navigating to the toggle with your screenreader. Flip the switch to turn dark mode on. Now, the toggle actually announces when it's on:

Properties

ARIA properties are attributes that describes extra context about an element that would be useful for a user to know, but aren't subject to change like state. Some examples include:

Marking up form fields with aria-required or aria-readonly
Using aria-haspopup to indicate that a button will open a dropdown menu
Designating an element as a modal with aria-modal

Some ARIA properties establish relationships between elements. For instance, you can use aria-describedby to link an element to another element that provides a longer-form description:

<form>
    <label for="pass">
        Enter a password:
    </label>
    <input
        id="pass"
        type="password"
        aria-describedby="pass-requirements"
    />
    <p id="pass-requirements">
        Your password must be at least 8 characters long.
    </p>
</form>

In this example, the screenreader would announce "Your password must be at least 8 characters long" as a part of the <input> announcement.

Use Less ARIA.

The World Wide Web Consortium's ARIA specs provide five rules for ARIA use. The first rule isn't quite "Don't use ARIA," as some have quipped, but it's pretty close:

If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.

In other words, ARIA should be a tool in your arsenal, but it shouldn't be the first one you reach for. Instead, your first instinct should be to use semantic elements where possible. In the case of our toggle, that might look like this, which uses a native checkbox and no ARIA at all:

Why should we default to semantic markup over ARIA? Some reasons include:

Semantic elements provide functionality and expose properties to the accessibility for free, out of the box. This ensures users have a robust and familiar experience across the web. With our semantic toggle, for instance, we didn't have to add tabbing or key events.
Semantic markup enables progressive enhancement, which means your page is moderately functional, even if CSS or JavaScript resources fail. If either the CSS or the JavaScript were unable to load, our ARIA-only toggle would be toast. Our semantic toggle would at least provide a checkbox with default styles.
Some assistive technologies maintain off-screen models instead of consuming the accessibility tree, so these tools may not support ARIA.

I really like how Kathleen McMahon put it. If web development is like cooking, then semantic elements are your high-quality ingredients. ARIA attributes, then, are your seasonings. Cook with them, by all means, but you'll only need a touch.

Surprises.

Ben Myers — Fri, 22 Nov 2019 17:01:18 +0000

I mentor and train my employer's college hires in front-end development. At the end of the 12-week program, the college hires present what they've learned to their managers and their leads.

I have one question I like to ask them, to help them prep for their demos:

"What surprised you?"

I get lots of responses to this. Maybe they were surprised by collaboration tooling, or they learned how to ask questions, or they struggled with Git. All surprises, big or small, are valid here.

I think this a great question to ask for self-reflection, for two reasons:

A surprise is a thing learned. Why did something surprise you? You had expectations that things were one way. A surprise disrupts your expectations and forces you to learn something new.
Surprises require reaction. Learning something is only half of the puzzle. You can learn many things and never act on them. What's the point of that? Surprises require you to adjust your status quo and adapt.

How do you use your surprises to grow and be better?

Have you set up or been involved in an accessibility community of practice?

Ben Myers — Fri, 15 Nov 2019 02:28:03 +0000

I'm embarking on a journey to set up a community of practice for accessible web and mobile development for my organization at work. Specifically, I'm trying to get representatives from seven teams together on a regular basis to discuss accessibility practices, with the ultimate goal of making each team more informed about accessibility. I've never organized anything like this, so it's very new to me.

Have you set up or been involved in an accessibility community of practice, accessibility users group, or anything similiar? If so, what was your experience?

The Accessibility Tree

Ben Myers — Thu, 14 Nov 2019 04:04:14 +0000

You can also read this post on my blog.

Disabled users can and do use your page with a variety of assistive technologies. They use screenreaders, magnifiers, eye tracking, voice commands, and more. All of these assistive technologies share a common need: they all need to be able to access your page's contents.

The flow of page contents from browser to assistive technology isn't often talked about, but it's a vital aspect of enabling many disabled users' access to the internet. It's taken a lot of experimentation and innovation to get to where we are now: the accessibility tree. This tree shapes how disabled users understand and interact with your page, and it can mean the difference between access and exclusion. As web developers, it's our job to be aware of how the code we write shapes the tree.

Let's take a journey through browser internals, operating systems, and assistive technologies. Our first stop: a crucial lesson learned from earlier screenreaders about information flow.

The Ghost of Screenreaders Past

The earliest screenreaders were built for text-only DOS operating systems, and they were pretty straightforward. The text was all there in the device's screen buffer, so screenreaders just needed to send the buffer's contents to speech synthesis hardware and call it a day.¹

Graphical user interfaces proved trickier for screenreaders, however, since GUIs don't have any intrinsic text representations. Instead, screenreaders like Berkeley Systems' outSPOKEN had to resort to intercepting low-level graphics instructions sent to the device's graphics engine.² Screenreaders then attempted to interpret these instructions. This rectangle with some text inside is probably a button. That text over there is highlighted, so it's probably selected. These assumptions about what was on the screen were then stored in the screenreader's own database, called an off-screen model.

Off-screen models posed many problems. Accounting for the alignment and placement of UI elements was tricky, and errors in calculations could snowball into bigger errors. The heuristics that off-screen models relied on could be flimsy — assuming they've even been implemented for the UI elements you want in the first place!³

Guessing at what graphics instructions mean is clearly messy, but could something like an off-screen model work for webpages? Could screenreaders scrape HTML or traverse the DOM, and insert the page contents into the model?

Screenreaders such as JAWS tried this approach, but it, too, had its problems. Screenreaders and other assistive technologies usually strive to be general purpose and work no matter which application the user is running, but that's hampered by including a lot of web-parsing logic. Also, it left users high and dry whenever new HTML elements were introduced. For instance, when sites started using HTML5's new tags such as <header> and <footer>, JAWS omitted key page contents until an (expensive) update could be pushed out.⁴

What did we learn from off-screen models? Assistive technologies that build their own off-screen models of webpages or applications can be error-prone and susceptible to new, unfamiliar elements and controls. These issues are symptoms of a bigger problem with the approach: when we try to reverse engineer meaning, we end up swimming upstream against the flow of information.

Let's go back to the drawing board. Instead of having assistive technologies make guesses about screen contents, let's have applications tell assistive technologies exactly what they're trying to convey.

Accessibility APIs and Building Blocks

If you want applications such as browsers to be able to expose information to assistive technologies, you'll need them to speak the same language. Since no developer wants to have to support exposing their application's contents to each screenreader and speech recognition software and eye tracker and every other assistive technology individually, we'll need assistive technologies to share a common language. That way, those who are developing browsers or other applications need only expose their contents once and any assistive technology can use it.

This lingua franca is provided by the user's operating system. Specifically, operating systems have interfaces—accessibility APIs—that help translate between programs and assistive technologies. These accessibility APIs have exciting names such as Microsoft Active Accessibility, IAccessible2, and macOS Accessibility Protocol.

How do these accessibility APIs help? They give programs the building blocks they need to describe their contents, and they serve as a convenient middleman between a program and an assistive technology.

Building Blocks

Accessibility APIs provide the building blocks for applications to describe their contents. These building blocks are data structures called accessible objects. They're bundles of properties that represent the functionality of a UI element, without any of the presentational or aesthetic information.

One of these building blocks could be a Checkbox object, for instance.

You could also have a Button object:

These building blocks enable all applications to describe themselves in a similar way. As a result, a checkbox is a checkbox, as far as assistive technology is concerned, regardless of whether it appears in a Microsoft Word dialog box or on a web form.

These building blocks, by the way, contain three kinds of information about a UI element:

Role: What kind of element is this? Is it text, a button, a checkbox, or something else? This information matters because it lays out expectations for what this element is doing here, how to interact with this element, and what will happen if you do interact with it.
Name: A label or identifier, called an accessible name, for this element. Buttons will generally use their text contents to determine their name, so <button>Submit</button> will have the name "Submit." HTML form fields often get their name from associated <label> elements. Names are used by screenreaders to announce an element, and speech recognition users can use names in their voice commands to target specific elements.
State and other properties: Other functional aspects of an element that would be relevant for a user or an assistive technology to be aware of. Is this checkbox checked or unchecked? Is this expandable section currently hidden? Will clicking this button open a dropdown menu? These properties tend to be much more subject to change than an element's role or name.

You can see all three of these in just about any screenreader announcement:

Accessibility APIs As a Middleman

An application assembles these building blocks into an assistive technology-friendly representation of all of its contents. This representation is the accessibility tree. The application then sends this new tree to the operating system's accessibility APIs. Assistive technologies poll the accessibility APIs regularly. They get information such as the active window, programs' contents, and the currently focused element.

They can use this information in different ways. Screenreaders use this information to decide what to announce, or to enable shortcuts that allow the user to jump between different elements of the same type. Speech recognition software uses this information to determine which elements the user can target with their voice commands and how. Screen magnifiers use this information to judge where the user's cursor is, in case they need to focus elsewhere.

This middleman relationship works both ways. Accessibility APIs enable assistive technologies to interact with programs, giving their users more flexibility. For instance, eye-tracking technology can interpret a user's gaze dwelling on an element as a click. The eye tracker can then send that event back through the accessibility API so that the browser treats it like a mouse click.

Putting all of these pieces together, the flow of information from application to assistive technology goes:

The operating system provides accessible objects for each kind of UI element.
The application uses these objects as building blocks to assemble an accessibility tree.
The application sends this tree to the operating system's accessibility API.
Assistive technologies poll the accessibility API for updates, and receive the application's contents.
The assistive technology exposes this information to the user.
The assistive technology receives commands from the user, such as special hotkeys, voice commands, switch flips, or the user's gaze dwelling on an element.
The assistive technology sends those commands through the accessibility API, where they're translated into interactions with the application.
As the application changes, it provides a new accessibility tree to the accessibility API, and the cycle begins anew.

Or, for a much more TL;DR version:

From the DOM to the Accessibility Tree

We've taken a pretty sharp detour into operating system internals. Let's bring this back to the web. At this point, we can figure that your browser is, behind the scenes, converting your page's HTML elements into an accessibility tree.⁵ Whenever the page updates, so, too, does its accessibility tree.

How do browsers know how to convert HTML elements into an accessibility tree? As with everything for the web, there's a standard for that. To that end, the World Wide Web Consortium's Web Accessibility Initiative publishes the Core Accessibility API Mappings, or Core-AAM for short. Core-AAM provides guidance for choosing which building blocks the browser should use when. Additionally, it advises on how to calculate those blocks' properties such as their name, as well as how to manage state changes or keyboard navigation.

The relationship between DOM nodes and accessibility tree nodes isn't quite one-to-one. Some nodes might be flattened, such as <div>s or <span>s that are only being used for styling. Other elements, such as <video> elements, might be expanded into several nodes of the accessibility tree. This is because video players are complex, and need to expose several controls like the Play/Pause button, the progress bar, and the Full Screen button.⁶

Some browsers let you view the accessibility tree in their developer tools. Try it now! If you're using Chrome, right-click on a page element and click Inspect. In the pane that opened up with tabs such as Styles and Computed, click the Accessibility tab. This might be hidden. Congrats! You can now see that element in the accessibility tree! If you're using other browsers, you can instead follow Firefox's Accessibility Inspector instructions or Microsoft Edge's instructions.

Poke around on different sites and see what kinds of nodes you can find and which properties they have.

But Why Do We Care?

Why should web developers care about the accessibility tree? Is it any more than just some interesting trivia about browser internals?

Understanding the flow of a webpage's contents from browser to assistive technology changed the way I view the web apps I work on. I think there are three key ways that this flow impacts web developers:

It explains discrepancies between different assistive technologies on different platforms.
Browsers can use accessibility trees to optimize how pages are exposed to assistive technologies.
Web developers have a responsibility to be good stewards of the accessibility tree.

Explaining Discrepancies

We know that there are three key players in the flow of web contents to assistive technologies: the browser, the operating system accessibility API, and the assistive technology itself. This gives us three possible places to introduce discrepancies:

Operating system accessibility APIs could provide different building blocks.
Browsers could use assemble their accessibility trees differently.
Assistive technologies could interpret those building blocks in different ways.

These differences are, honestly, minute most of the time. However, bugs that affect certain combinations of browsers and assistive technologies are prevalent enough that you should be testing your sites on many different combinations.

Browser Optimizations

When constructing accessibility trees, many browsers employ heuristics to improve the user experience. For instance, many developers use the CSS rules display: none; or visibility: hidden; to remove content from the page. However, since the content is still in the HTML, those using assistive technologies would still be able to get to it, which could have undesirable consequences. Browsers instead use these CSS rules as flags that they should remove those elements from the accessibility tree, too. This is why we have to resort to other tricks to create screenreader-only text.

Additionally, browsers use tricks to protect users from developers' bad habits. For instance, to counter the problems that can be caused by layout tables, both Google Chrome⁷ and Mozilla Firefox⁸ will guess at whether a <table> element is being used for layout or for tabular data and adjust the accessibility tree accordingly.

Tree Stewardship

Being aware of the accessibility tree and how it impacts your users' experience should make one thing clear: to build quality web applications, we must be responsible stewards of our applications' accessibility trees. After all, it's the only way many assistive technology users will be able to navigate and interface with our page. If our tree is rotten, there's not really anything these users can do to make our page usable. Fortunately, we have two tools for tree stewardship at our disposal: semantic markup and ARIA.

When we use semantic markup, we make it much, much easier for browsers to determine the most appropriate building blocks. When we write <input type="checkbox" />, for instance, the browser knows it can put a Checkbox object in the tree with all of the properties that that entails. The browser can trust that that's an accurate representation of the UI element. The same goes for buttons and any other kind of UI element you might want on your page.

Semantic markup will work for the majority of our needs, but there are times when we need to make tweaks here and there to our application's accessibility tree. This is what ARIA is for! In my next post, I'll explore how ARIA's whole purpose is to modify elements' representation in the accessibility tree.

Conclusion

Decades of trial and error in building screenreaders and a wide variety of other assistive technologies have taught us one big lesson: assistive technology will work much more reliably when information flows directly to it rather than be reverse engineered. Browsers do a lot of heavy lifting to make sure our pages play nicely with assistive technologies. However, they can't do their job well if we don't do our job well.

Footnotes

Please forgive the oversimplification.
Rich Schwerdtfeger, BYTE, Making the GUI Talk
Léonie Watson & Chaals McCathie Nevile, Smashing Magazine, Accessibility APIs: A Key To Web Accessibility
Marco Zehe, Why accessibility APIs matter
It probably comes as no surprise that the accessibility tree is built in parallel to the DOM. One of the things I realized as I was writing this post is that creating structured representations of a page that enable programmatic interfacing with the page is really browsers' bread and butter. Your browser does exactly this to manage page contents (via the DOM) and element styles (via the CSS Object Model), so why not throw in accessibility tree creation while you're at it?
Steve Faulkner, The Paciello Group, The Browser Accessibility Tree
Chromium source code
Firefox source code

How Domino's Could Topple the Accessible Web – Part 1: Public Accommodations

Ben Myers — Sat, 07 Sep 2019 13:54:27 +0000

This post is the first in a three-part series on web accessibility in American case law, and the impact Robles v. Domino's Pizza could have on that landscape. This first entry focuses on the ways courts interpret public accommodations.

You can also read this post on my blog.

What's Happening

Last year, 2,285 web accessibility cases were filed in the US. That's about six cases a day, and it's almost three times as many cases as 2017.^1 As the number of cases rises, so too does the media attention, and no case has quite stolen that spotlight like Robles v. Domino's Pizza has.

Guillermo Robles has had a storied three years. As a blind man who navigates the web using a screenreader, he found he was unable to order pizza from Domino's. He filed a suit against Domino's in September 2016, alleging that Domino's website and mobile app were incompatible with his screenreader. The Central District of California dismissed the case on the grounds that the law was not concrete enough to hold Domino's accountable. The Ninth Circuit Court of Appeals overturned that dismissal in January 2019, asserting that the law does, in fact, hold the pizza chain accountable for inaccessible websites and apps. Most recently, in July, Domino's petitioned to bring the case to the Supreme Court. They're backed by the U.S. Chamber of Commerce, the Restaurant Law Center, and the National Retail Federation.^2 Businesses really, really want to see this case go their way.

This case could have a lasting impact for many disabled users of the internet. The Supreme Court has not yet seen a web accessibility case, meaning lower courts have been left to figure this out for themselves. Specifically, courts have been grappling with two big questions:

Does American law require websites to be accessible?
If so, which standards of accessibility are websites held to?

The courts' many responses to those questions have led to a lot of confusion, ambiguity, and frustration. However, understanding where these courts are coming from is vital to understanding the future of disabled users' access to the internet.

Let's look at that first question:

Does the Law Require Web Accessibility?

No federal law mentions web accessibility. As a result, courts turn to the next best thing: the Americans with Disabilities Act. Title III of the ADA forbids public accommodations from discriminating against disabled Americans:

"No individual shall be discriminated against on the basis of disability in the full and equal enjoyment of the goods, services, facilities, privileges, advantages, or accommodations of any place of public accommodation by any person who owns, leases (or leases to), or operates a place of public accommodation."

Disabled plaintiffs argue that websites count as public accommodations and, as a result, cannot be inaccessible.

What is a Public Accommodation?

It's here that a definition of "public accommodation" would be really nice. Title III, however, does not provide one. Instead, it offers a long list of examples of public accommodations, including hotels, restaurants, banks, travel services, zoos, laundromats, and many more. This list is well understood to be nonexhaustive.^3 Crucially, however, it does not mention websites.

So, Are Websites Public Accommodations?

Courts are divided on this question, but their opinions can be roughly grouped into three categories:

Yes, websites are public accommodations.
No, websites are not public accommodations.
Websites are sometimes public accommodations.

These opinions conflict a lot, meaning there are many cases with inconsistent rulings.

Opinion #1: Yes, Websites Are Public Accommodations

Amongst courts, the opinion that websites are inherently public accommodations is the most fringe. These courts, namely the First and Seventh Circuit Courts of Appeals, maintain that websites are public accommodations just by virtue of providing a service.

The courts argue that there is precedent for nonphysical spaces counting as public accommodations. They wipe the dust off an old case, ADA-wise: the Carparts Distribution Center, Inc. v. Automotive Wholesaler's Association of New England case from 1994. In Carparts, the First Circuit ruled that the ADA covered phone-based services. They noted that Congress had included travel services in the list of example public accommodations. At the time, the travel services industry was largely telephone-based, so the First Circuit reasoned that obviously Congress intended to include nonphysical spaces such as telephone lines.

In their Carparts ruling, the First Circuit noted that:

"It would be irrational to conclude that persons who enter an office to purchase services are protected by the ADA, but persons who purchase the same services over the telephone or by mail are not. Congress could not have intended such an absurd result."

—First Circuit Court of Appeals, Carparts Distribution Ctr. v. Automotive Wholesaler's Ass'n.

The Seventh Circuit court has applied this reasoning to an insurance company that sold its services online:

"The defendant asks us to interpret 'public accommodation' literally, as denoting a physical site, such as a store or a hotel, but we have already rejected that interpretation. An insurance company can no more refuse to sell a policy to a disabled person over the Internet than a furniture store can refuse to sell furniture to a disabled person who enters the store."

—Seventh Circuit Court of Appeals, Morgan v. Joint Admin. Bd.

Netflix, Scribd, and Blue Apron have all found themselves at the receiving end of courts of this opinion.

Opinion #2: No, Websites Are Not Public Accommodations

If the First Circuit's Carparts ruling seems like a bit of a stretch to you, you're not alone.

Courts of this opinion, such as the Third, Fifth, and Sixth Circuit Courts, point to the ADA's full wording: "place of public accommodation." Nonphysical spaces such as websites, they argue, aren't places, and therefore they aren't covered by Title III. To claim that they are covered would be to vastly expand the scope of the law:

"Here, to fall within the scope of the ADA as presently drafted, a public accommodation must be a physical, concrete structure. To expand the ADA to cover 'virtual' spaces would be to create new rights without well-defined standards."

—District Court for the Southern District of Florida, Access Now, Inc. v. Southwest Airlines, Co.

Full disclosure: the Southern District of Florida actually sided with Opinion #3 in the Southwest Airlines case. This line just happens to be a very succinct explanation of Opinion #2.

These courts often explicitly reject the Carparts ruling as an overreach:

"In arriving at this conclusion, the First Circuit disregarded the statutory canon of construction, noscitur a sociis. [...] The doctrine of noscitur a sociis instructs that 'a ... term is interpreted within the context of the accompanying words 'to avoid the giving of unintended breadth to the Acts of Congress.'' [...] The clear connotation of the words in §12181(7) [the list of examples of public accommodations] is that a public accommodation is a physical place. Every term listed in §12181(7) and subsection (F) is a physical place open to public access."

—Sixth Circuit Court of Appeals, Parker v. Metropolitan Life Ins. Co., citations omitted

Other cases that have made similar arguments and have been used as precedents within these courts include Ford v. Schering-Plough Corp. and Weyer v. Twentieth Century Fox Film Corp..

Additionally, the ADA has been amended several times since the rise of the internet. If Congress really did intend for the ADA to cover nonphysical spaces such as websites, surely they would have included that in one of the amendments, right?^4

Opinion #3: Websites Are Sometimes Public Accommodations

The most frequent court opinion about websites as public accommodations kind of sidesteps the question altogether by claiming that websites can be extensions of public accommodations.

"While there is some disagreement amongst district courts on this question, it appears that the majority of courts agree that websites are not covered by the ADA unless some function on the website hinders the full use and enjoyment of a physical space."

—District Court for the Southern District of Florida, Gomez v. Bang & Olufsen Am., Inc.

This is the principle of nexus: if a website has a significant connection to the goods and services offered by a physical public accommodation, then the website is seen as an extension of the public accommodation. In that case, it would be subject to Title III. After all, Title III forbids obstructing access to the goods and services "of any place of public accommodation," not "in any place of public accommodation."

The first federal trial on web accessibility to be carried out in full was Gil v. Winn-Dixie in 2017. Winn-Dixie offered digital coupons on their website that were only redeemable in their brick-and-mortar stores. Additionally, Winn-Dixie gave customers the option to refill their prescriptions online, but the refills also had to be picked up in-store. The Southern District of Florida determined that the Winn-Dixie website therefore had a nexus to the brick-and-mortar franchises. Thus, the website's incompatibility with screenreaders was a violation of the ADA.^5

Nexus does go the other way. In Earll v. eBay, Inc., for instance, a deaf plaintiff sued eBay since she couldn't use the site's phone-based vendor verification service. The Ninth Circuit determined that, since eBay doesn't have any consumer-facing, brick-and-mortar locations, eBay is not a public accommodation and is not subject to Title III.^6 Netflix, Viacom, Facebook, and Southwest Airlines have also been defended with a similar argument.

Much like it did during the Winn-Dixie case, the Ninth Circuit applied the nexus argument to Domino's this January when overturning the district court's dismissal of Robles's case:

"Domino's website and app facilitate access to the goods and services of a place of public accommodation — Domino's physical restaurants. They are two of the primary (and heavily advertised) means of ordering Domino's products to be picked up at or delivered from Domino's restaurants. We agree with the district court in this case — and the many other district courts that have confronted this issue in similar contexts — that the ADA applies to Domino's website and app, which connect customers to the goods and services of Domino's physical restaurants."

—Ninth Circuit Court of Appeals, Robles v. Domino's Pizza

Takeaways

The Robles v. Domino's Pizza case is just one of many court cases centered around whether American law requires websites to be accessible. The number of web accessibility-related lawsuits is only going to go up from here as courts continue to give mixed opinions on the matter.

By appealing the Ninth Circuit's decision, Domino’s Pizza is giving the Supreme Court the opportunity to affirm, finally, whether websites are inherently public accommodations, whether they're inherently not public accommodations, or whether they count as public accommodations if a nexus is present.

However, while the question of whether the ADA covers websites is important, it's not the only question Domino's is contesting. Stick around for Part 2, where we'll cover magic checklists and due process.

Footnotes

^1 The National Law Review, When Good Sites Go Bad: The Growing Risk of Website Accessibility Litigation

^2 The Washington Post, Do protections for people with disabilities apply online? Domino’s asks high court.

^3 That is, to an extent. The twelve subcategories listed are pretty fixed, but enough of the subcategories include "or other X" clauses that this list is pretty open to interpretation.

^4 District Court for the Eastern District of Virginia, Carroll v. Northwest Federal Credit Union

^5 District Court for the Southern District of Florida, Gil v. Winn-Dixie

^6 Ninth Circuit Court of Appeals, Earll v. eBay, Inc.

DEV Community: Ben Myers

What is your most complex focus interaction?

TIL About .bold(), .blink(), and More JavaScript String Methods

CSS Influences Screenreaders

Introduction

Smart Browsers

CSS's Potential Influences on Screenreaders

CSS-Generated Content

Hidden Content

Nullifying Semantics

An Obligatory Mention of the CSS Speech Module

Conclusion

New Year, New Terminal: Alias Your Directories the Windows Way

Introduction

Creating Aliases with Doskey

Persisting Doskey Aliases

Adding Persistent Doskey Aliases on the Fly

Conclusion

New Year, New Terminal: Alias Your Directories the Unix Way

Introduction

Creating Aliases

Persisting Bash Aliases

But Wait! I Have a Mac!

Adding Bash Aliases on the Fly

Conclusion

What Is ARIA?

Introduction

Revisiting the Accessibility Tree

Good Markup Means Happy Trees

Introducing the Toggle

Role

Name

State

Properties

Use Less ARIA.

Further Reading

Surprises.

Have you set up or been involved in an accessibility community of practice?

The Accessibility Tree

The Ghost of Screenreaders Past

Accessibility APIs and Building Blocks

Building Blocks

Accessibility APIs As a Middleman

From the DOM to the Accessibility Tree

But Why Do We Care?

Explaining Discrepancies

Browser Optimizations

Tree Stewardship

Conclusion

Footnotes

How Domino's Could Topple the Accessible Web – Part 1: Public Accommodations

What's Happening

Does the Law Require Web Accessibility?

What is a Public Accommodation?

So, Are Websites Public Accommodations?

Opinion #1: Yes, Websites Are Public Accommodations

Opinion #2: No, Websites Are Not Public Accommodations

Opinion #3: Websites Are Sometimes Public Accommodations

Takeaways

Footnotes