Global Accessibility Awareness Day: E Source and accessibility

Today we’re proud to be celebrating the 10th annual Global Accessibility Awareness Day (GAAD), which aims to spread awareness and start discussions around online accessibility. There are more than a million people in the US who have disabilities or impairments that affect their online experience. E Source is on a mission to support them by creating an accessible experience on our website, and we want to help you optimize your user experience (UX) by sharing some of how we do it.

What is accessibility?

In the website and software building world, we talk a lot about inclusive design, and accessibility is a big part of that discussion. When talking about accessibility, we mean that, in the words of the GAAD website:

Every user deserves a first-rate digital experience on the web. Someone with a disability must be able to experience web-based services, content and other digital products with the same successful outcome as those without disabilities.

Some of the common disabilities and impairments to be mindful of include:

• Visual. People who have challenges with their sight often use screen readers and need alternative text descriptions for images. These users tend to rely on a keyboard to interact, not a mouse.
• Hearing. Those who have trouble hearing or are deaf rely on captions in video presentations and visual indicators instead of audio cues.
• Motor. Individuals with motor impairments (that is, something that might prevent them from using a keyboard or mouse, such as hand tremors, a broken arm, or paralysis, just to name a few) may use assistive technologies such as alternative keyboards, eye control, or other hardware that helps them type and navigate web pages.
• Cognitive. Users with learning disabilities or anxiety disorders appreciate a clean design with clear and consistent navigation as well as plain language.

That said, accessible design helps every user, not just those with disabilities. Any user can be disabled, even temporarily—consider someone with an eye infection or someone holding a baby in one arm. The more inclusive your design is, the better it will serve all of your users.

How does E Source approach accessibility?

Making websites and software accessible can be a lot of work, but at E Source, we believe it’s important to do your best to be inclusive to all. We approach accessibility from two sides: software and website design and the language we use. To learn more about each, check out what Melissa Utomo and Sarah Thompson of our UX team and Logan Jacobson from the editorial team have to say.

Designing accessible software and websites

As Sarah and Melissa explain, inclusive design means thinking through how every aspect of a design could affect people with disabilities. Some things that seem simple, such as color or button size, really aren’t when you consider whether someone who’s color blind or whose hands shake can use them. Thankfully, there are experts who want to help lead the way. At E Source, we do our best to comply with the W3C’s Web Content Accessibility Guidelines (WCAG) version 2.1 in all of our software and website design.

Inclusive design means thinking through how every aspect of a design could affect people with disabilities.

WCAG’s purpose is to “make content more accessible to a wider range of people with disabilities,” and it has established three levels of success criteria: A (lowest), AA, and AAA (highest). We try to conform to AA level at minimum, and AAA level wherever possible. Melissa distilled the in-depth guidance from WCAG (and a select few other resources) into a Web accessibility standards checklist (XLSX) that we use to test our designs. WCAG has sectioned its guidance into four areas: perceivable, operable, robust, and understandable.

Perceivable. Many websites are only truly usable by people who can see. WCAG challenges designers to find ways for users with visual impairments to interact with the information on the site. At E Source, we recently changed our link and button color from our beloved E Source green to our secondary brand color, blue, because its contrast ratio is better—WCAG AA contrast ratio is 4.5:1 (standard 1.4.3), and our green didn’t meet the standard.

We also do our best to avoing letting color alone indicate functionality (standard 1.4.1). For example, we added an underline treatment to our links when users hover over them with a mouse or keyboard navigation.

Operable. Have you ever considered whether users of your website can interact with it without using a mouse? We improve usability for those with mobility issues by ensuring that any clickable target in our designs is a minimum of 44 by 44 pixels in size (standard 2.5.5). And since not all disabilities are physical, we don’t include time constraints in our designs (standard 2.2.3) because they can distress users with anxiety. In addition, we’re moving away from including animated images in our designs because they can trigger seizures or vertigo (standard 2.3). Instead we’re showing focus areas (in our case, a thin outline around a clickable area) for those using the keyboard to navigate (standard 2.4.7).

We make sure that every image on our site that isn’t just for decoration has alt text that will describe the images for people using screen readers.

Robust. This principle (standard 4.1) has the shortest definition, but don’t think that makes it the easiest! We test our content with screen-reading software and verify that the keyboard navigation works. And we make sure that every image on our site that isn’t just for decoration has alt text that will describe the images for people using screen readers.

Understandable. The work to meet this principle largely falls to our editorial team, as Logan will explain in the next section, but we also use plain language in the microcopy of our tools and website, such as labels, errors, instructions, and navigation. Sarah’s job is to focus on the UX of that microcopy to help our users move through our tools and our website as easily and consistently as possible.

Making language accessible

Making digital content accessible doesn’t stop at thoughtful website design. The language you use matters too. And making our content easier to read benefits everyone. To list a few examples, it makes our research more accessible to people who have difficulty reading, who read in distracting environments (#WFH), and who want to translate our content into other languages. (Nous pensons à vous, nos chers amis canadiens !)

Writing to a low reading level. A reading level is the grade of education that someone needs to read the content. And our editorial team makes sure the reading level of our content is as low as possible. That might sound counterintuitive. Why is the company paying a team of editors to turn PhD-level writing into something a 12th grader could read? The answer is that everyone wants to read at lower grade levels. In fact, one study found that the more education someone has, the stronger their preference for simpler writing is (check out The Public Speaks: An Empirical Study of Legal Communication for details).

The more education someone has, the stronger their preference for simpler writing is.

But it’s surprisingly hard to write at a low grade level, especially when we’re writing about things like court rulings on hydrofluorocarbon refrigerants or regulatory requirements for solar programs. Part of why it’s difficult to write at a lower grade level is because it isn’t about oversimplifying the material—it’s about making the writing simpler without stripping any of the meaning. So how do we do it? We keep things easy to read by:

• Removing jargon and defining terms. Common business jargon (like synergize) makes content harder to read even when readers are familiar with the lingo. Industry terms (like electric vehicle supply equipment) also make content harder to read, but it’s usually necessary for our material, so we define it for readers.
• Keeping sentences short. We aim to keep sentences under 25 words because the longer a sentence is, the harder it is to read.
• Writing in active voice. We use active voice because it’s easier for readers to process than passive voice. In active voice, the sentence follows a clear noun-verb structure. Learn more about it in Grammarly’s Active vs. Passive Voice: What’s the Difference?

Using inclusive language. Inclusive language involves choosing words and phrases that don’t alienate any readers. For example, to make sure we don’t exclude anyone based on gender, we use gender-neutral language like lineworker instead of lineman. Jargon is also an example of language that can alienate readers, which is why we’re careful about which specialized terms we use. We reference conscious style guides like Writer’s Need a diversity and inclusion messaging strategy? and the National Center on Disability and Journalism’s Disability Language Style Guide to make decisions about what language we use and don’t use.

How do you get started?

The bottom line is that it’s just the right thing to do, both for business and for society as a whole.

Accessibility feels like a brave new world, it’s true. It’s not something that everyone has considered yet, but the times, they are a-changin’. More and more, businesses will be expected to make sure that their websites and apps are accessible to all. It’s already becoming a recognized legal issue—see the CNBC article Supreme Court hands victory to blind man who sued Domino’s over site accessibility—and US government sites are required to comply with section 508 accessibility standards (check out the US Environmental Protection Agency’s What is Section 508?). But the bottom line is that it’s just the right thing to do, both for business and for society as a whole.

And the only way to get there is to start somewhere. So start small, like we did, by evaluating your color choices or the size of buttons or navigational elements. But make a start. No design is perfect—there will always be more we can do—but we believe that every company owes it to their users to make their websites and software products accessible to everyone.