The Accessible Editor: Part One – What is the Accessible Editor?

I really enjoy riding my bike.

I’m not the fastest, or the most powerful, though I will admit that I’ve gone six-sevenths of the way across Iowa on RAGBRAI (external page), and the last few years I’ve spent four days riding circles in Minnesota (external page). But I really like my bike. I really like being a bicyclist. I consider myself a fan.

This is notable, because Sioux Falls has been incredibly active in bike advocacy over the past decade. As we shift from a small- to medium-sized city, we’re spending a lot of time debating expansion of our public transport, and we’re slowly building the infrastructure needed to help maintain a healthy bike community, from expanding the bike trails to creating bike lanes and support along common routes.

I mention this because it shows a level of maturity that we as a city hadn’t really had in the decades before. We as a city understand that in order to grow, we can’t just keep slapping roads down everywhere. We have to diversify. We have to provide different options for different types of people.

But it’s not something that’s happening overnight. Because if you think we like cars as a country, you should see how much we like cars in the midwest, where the cities are hours apart and the closest IKEA is a full state away.

So you end up with bike lanes that look more like parking spots. You end up needing to remind people to open to their car doors carefully in case there’s a bicyclist rolling up. We’re very lucky to be in an age where the swell of sustainability and fitness are coalescing upon the bicycle groups in our communities, but some habits are hard to break.

The Balance of Intent and Interpretation

This brings us to a funny impasse. Because, while the idea of an updated bicycle infrastructure is generally celebrated and pushed forward under the guise of civic improvement, building a bike friendly infrastructure and maintaining a bike friendly community are two different things.

We see this when wheelchair ramps are built into a storefront, but upon entering the store the aisles are too narrow for anyone to get around. We see that when interpreters are brought in to sign a presentation but they’re placed in an area that not everyone can see.

We see this as being deliberate with our intent, but not following through on the action — the interpretation of our intent. So there’s a disconnect.

This is what happens to our websites. We do all we can to make sure the site is built to pass all of the technical accessibility tests, but we don’t give enough thought to how accessibility will be maintained on the editorial side.

There’s a reason for this. Once we’ve moved outside of fields and code and contrast ratios, we move into the purview of judgement. Editorial judgement, where language takes over. Where checking a box no longer cuts it.

And judgement calls are scary.

What Is Web Accessibility?

Before we can understand how to adjust our thinking on the editorial side, we first need to wrap our arms around what we mean by web accessibility.

On the web, accessibility is the practice of removing barriers for people with disabilities.

Much like new building construction must provide accessible entrances, and businesses must provide reasonable accommodations to employees with disabilities, websites must be created in a way that allow access to information despite any existing or future disability.

Accessibility as Inclusive Design

Sometimes, especially in articles like this one, you’ll see “accessibility” written as “a11y.” This is a clever little abbreviation, because it conveys two things:

• First, it represents the word “accessibility.” “Accessibility” is an A and a Y with 11 letters in between.
• More importantly, though it provides insight into the purpose of accessibility: that we are being an ally to those with differing needs, purposely making things better for those, for example, who cannot see, or those who are color blind, or those who are unable to use a mouse.

Accessibility is a small part of what we call inclusive design, which is the idea that sites are not built for just us, and are definitely not built within perfect conditions; instead, because the web’s audience is a wildly differing public, all of whom have unique needs and experiences, our sites need to be built for everyone.

Ultimately, it means providing options.

Accessibility: Who Is Affected

Because most websites rely on written and visual communication, accessibility issues are most often seen as visual issues, affecting those with temporary or permanent vision problems. These situations often require things like screen readers, which will read the content to you depending on how the site is structured.

But, it also affects those who have motor or mobility disabilities — such as those with cerebral palsy, or someone who has recently had a stroke. These are people who may not be able to use a mouse or perform fine movements with a track pad — they may use the tab button to more quickly move around the screen.

It affects those with auditory disabilities, such as deafness, who require captions and transcripts of audio content.

It even encompasses those who have cognitive disabilities or language barriers, who simply cannot understand your over-written page content.

Additionally, it’s worth noting that not every disability is life-changing. Not every disability is permanent. Not every disability is even a disability in the minds of those who classify disabilities.

But our websites don’t know that.

It’s true. While there’s an obvious difference between someone who has lost an arm, someone with a broken arm, and someone who is holding a child with one arm — to a website all three are nearly identical.

Accessibility: A Social Issue

Finally, there’s one additional grey area in accessibility: the simple need and promise of information and what we can do to provide it in less than optimal conditions.

According to the Pew Research Center, just over one-in-ten American adults are “smartphone-only” internet users (external page), and just over one-in-four lives without a broadband internet connection (external page), and it’s one-in-two for those 65 and over.

Additionally, over 4,000,000 people — roughly the size of the audience that watched the series finale of NBC’s Parks and Recreation (external page) — classify themselves as immigrants with a “less than good” grasp of the english language (external page).

These aren’t issues of whether or not an image has a certain contrast, or if a page can be tabbed through with a keyboard.

These are issues of needing sites that can load on slow speed connections.

Sites that can be easily read with an in-browser translator.

Sites that conform not just to those who have a visible disability, but those who cannot afford the best computers, the fastest connections, or who are underrepresented in other ways.

Where Editorial Accessibility Happens

So how do we make real change happen?

I believe it happens on a psychological level, and it happens when we understand two truths of accessibility.

FIRST:

“The potential audience of a website or app is anyone human.” – Hayden Pickering

This quote from the wonderful book Inclusive Design Patterns (external page) reminds us that we don’t know who might hit our sites, so we should at least make it welcoming when that stranger shows up.

SECOND:

“Websites are made of code, and that code is translated by robots.” – Corey Vilhauer

When I talk about robots, I obviously joke. What I’m talking about is the systems that have been created over the past decades to help read and translate code. They are not, like, real people. They’re programs. They do not understand nuance, or sarcasm, or anything that might be implied through language or color.

So we have to provide the context. And this comes in two forms.

The Content Model

First, it comes in the things that we can assign to a page template. This is stuff, and it is hopefully already baked into the CMS when an editor needs it. It effectively makes up what is called a “content model.”

Using Jeff Eaton’s description of a content model from his 2017 talk “Collaborative Content Modeling (external page),” this breaks down into three things:

• What kinds of things we make
• How they related to each other
• What bits of information they contain

In terms of accessibility, this allows us to create content that can be read by a screen reader, or can be tabbed through on a keyboard. It allows us to assign alternative text to images so they can be parsed into something readable.

It allows us to programmatically, within the page template, handle some of the issues that someone with a disability may encounter.

The WYSIWYG Field

Then, there’s the stuff that goes inside of that content model. This is tied to the writing conventions of the web.

What we write needs to be just as accessible as the navigation and design, and that is done through the grey areas of writing. Through clear heading structure. Links that are clear. Videos that are captioned.

This writing stuff has a lot of grey areas, but let’s start with the structure and “things” first.

Let’s start with the editorial structure.

Next: Part Two — The Structured Things: Alternative Text