Web Accessibility Lessons

Here’s a short list of resources and things I’m learning about accessibility and how to build accessible software. I am just starting to incorporate some of these lessons, so in some ways I am pulling the cart before the horse by sharing this list before fully mastering these lessons myself.

This piece is separated first into information about impairments followed by practical lessons for software engineers and designers about creating accessible software (mostly for visual impairments).

Impairments and How People Interact With Computers

In “What is Accesssibility for Web Apps and Why do I care?", John Willoughby writes that, “Is this site accessible?” is not a binary question! There are actually gradations of how accessible your site is. One reasons is because people have different disabilities (vision, hearing, motor, cognitive impairment, and combinations of these).

• So, to begin thinking about accessibility, you might ask: how would someone interact with your website/app in a noisy environment? a very bright environment outdoors? without a keyboard? without a visual monitor? without a speaker? with poor wifi? on a mobile phone? on an old browser? etc.

• And, accessible design doesn’t mean making your site ugly. It may even make the experience better for non-impaired users too!

Some of the most common impairments are vision-related impairments. If you imagine having no vision for just a moment, you may realize that one way you would be able to interact with a webpage would be through audio…

Screen Readers

Cue the screen reader! Screen readers are devices or programs that convert graphical text, images, software, and webpages into speech or braille.

Some common screen readers are JAWS, NVDA and Apple Voice Over.

If you pause to imagine how someone who is using a screenreader will receive information, it’s through a stream of audio. Given that information is coming in through a more linear stream of information, as an engineer and designer, it’s best to ask… how could I build something in a linear way? Kind of like turning your application into a story. First there is this information, then there is this next information, and then this third piece of information. Even if something is big and obvious further down on your webpage, someone with vision might see that and jump right to it, but someone with a screenreader may not get to that information or realize it is there until their screen reader reads it. That could take a while!

• To get a better sense of a webpage, it is common for screen reader users to navigate through headers and links first

• Some visually impaired people use screen readers, and some don’t.

• Some people who use screen readers do have some vision, but still rely on a screen reader as the main form of sensory processing.

• Blind people not only use speech dictation to input text on touch screens, but also by typing (with a screen reader, you can drag your finger across the screen to hear the key that your finger is above. And for more advanced typers, you can also do direct touch typing–where you just tap each key and listen to what is tapped. I learned this from Tamara, a blind YouTuber, with her video “How Blind People Use Technology (My Apple Products - An Introduction to Voice Over)".

• As a developer, one of the main things you can do to start dipping your toes into accessible design is to explore the screen reader on your device. I tried Apple’s Voice Over tutorial. Even with sight, it’s pretty tricky and takes some time to figure out! If you try it out too, make sure to test the VoiceOver rotor, which can be used to quickly navigate to important parts of a webpage.

For a short video on a screenreader being used in action, check out Brennan Carman’s web accessibility demo:

Web Accessibility for Software Engineers

On the topic of designing an app in a linear way, ask yourself… what would be the best text to hear first if someone first got to your web app. You might have a menu, lots of buttons, text… in what order should this information be presented?

Besides that, here are some other practical tips for software engineers for building websites and web apps that are more accessible!

1. Use Headers <h1>, <h2>, <h3>, ... to properly create a hierarchy of your webpage. Many people using screenreaders first explore a webpage by having a screenreader read out the list of headers on the webpage. Another common way screen reader users navigate is by exploring a list of links on the page.

2. When you use headers, make sure to write descriptive headings!

3. If using emojis, use them at the end of a message, and only a few, not too many! Never put a call to action after an emoji. Here is an example of what NOT to do: “So great to see you! 😸😸😸😸 do you want to get lunch at 2pm?” (Emojis and Accessibility)

4. For images, use alt tags to provide a text description of the image. For example: <img src=’cat.png’ alt=’An orange tabby cat wearing a tuxedo’>

5. Use ARIA roles when “function is unclear from tags alone”. For example, <div role="navigation"> helps denote that this div is the div containing information for navigation on the page. ARIA roles include main, form, navigation, and search and should only be used in <div> and <span> tags. Tags like <menu>, <nav>, <form>, and <main> are already well-defined, so ARIA roles are not needed. (How to Design Your Website for Screen Reader Accessibility)

6. Use HTML labels with input fields so that users have context for what an input field is for when they arrive there (mdn web docs). For an example:

<label for="username">Enter your username:</label>
<input id="username" name="username" type="text" />

7. If there is no text or accessible name for an element, like a button without any text, use aria-label to label that element with a string. Another example would be if you have links that are not very descriptive. For example, if the text for a link is “Read More”, it could be more descriptive to add aria-labels too like aria-label="Read More about Pineapples" and aria-label="Read More about Mugs" (w3 - Using aria-label for link purpose).

8. But also, if there is visible text on the page that describes what some HTML element does, use aria-describedby instead of aria-label (mdn web docs). For example,

<button aria-describedby="trash-desc">Move to trash</button>
…
<p id="trash-desc">
  Items in the trash will be permanently removed after 30 days.
</p>

9. “Always remember, you don’t need to target instructions to screen readers only; if instructions are needed, provide them to everyone (or, preferably, make your UI more intuitive)” (mdn web docs).

10. However, if there really are instructions that you think are only relevant for screen readers, you can use this class, which is a mashup of what I found on Enable and a11y-guidelines.orange.com.

 .screen-reader-only{
	position: absolute !important;
	width: 1px !important;
	height: 1px !important;
	padding: 0 !important;
	margin: -1px !important;
	overflow: hidden !important;
	clip: rect(0,0,0,0) !important;
	clip: rect(1px 1px 1px 1px); /* IE 7+ only support clip without commas */
 	clip-path: polygon(0px 0px, 0px 0px, 0px 0px);
 	-webkit-clip-path: polygon(0px 0px, 0px 0px, 0px 0px);
	white-space: nowrap !important;
	border: 0 !important;
}

For an example of using the screen-reader-only class, Oliver Langmo shares that the right approach is as follows:

<div class="screen-reader-only">These are screen reader user specific instructions.</div>
<div aria-hidden=”true”>These are instructions for everyone else.</div>

as opposed to this “wrong” technique:

<div aria-label="These are screen reader user specific instructions.">These are instructions for everyone else.</div>

which is less likely to work with screen readers and which doesn’t honor the true purpose of the aria-label.

One thing Langmo encourages you to keep in mind though if you do use the screen-reader-only class is that as a developer, “Since the text does not appear on the page, it runs the risk of being forgotten about or the element it applies to could get moved or changed, rendering the text useless, outdated, or confusing.”

Testing Your Applications

As you begin to focus on accessibility, learn how to use a screen reader to get a basic sense of how your website or app would appear for someone using a screen reader as the main way of interacting with your site!

There is also software to help with accessibility testing. Here are 21 Web Accessibility Testing Tools from Kristen Baker at Hubspot.

Other Relevant Info on Accessibility

• Haben Girma, who is the first Deafblind graduate of Harvard Law School, has a great talk at Apple WWDC 2016 on The Universal Benefits of Accessible Design.

• The official Web Content Accessibility Guidelines (WCAG) 2.0 is probably the gold standard resource on accessible web content.

• It’s not clear that accessibility overlays like AccessiBe are actually helpful for blind users. Haben Girma (see above) has put out a video criticizing them.

• In their 2021 Resolutions, the National Federation of the Blind “insist[s] that current and potential overlay customers recognize that complete and long-lasting accessibility requires more than a one-time installation of code; that accessibility should be a priority throughout the entire lifecycle of any product from design to full implementation;” (National Federation of the Blind)

• Dates are notoriously difficult for screen readers! Here’s a pretty great quote from Accessibility Oz explaining the confusion with getting dates and times to read correctly: “Now imagine that your meeting time is described as “s a t zero five zero nine nine ten” or “open to wed”. Confusing, right? The first example is ” SAT 05/09, 09:10″ read by a screen reader. The second one is “Open: Tue – Wed”.” One reason for this is because there are so many written date time formats people use around the world! I tried using MikesBarto/accessible-date javascript library to make screenreader-friendly date times and I think it’s pretty good.

• Text with many hyperlinks, like on Wikipedia, can be very hard to understand while using a screenreader (source).

• While exploring software with well-documented screenreader usage, I found these examples from major companies for calendar software:

  • Screen Reader for scheduling in Microsoft Outlook
  • Google Calendar with a Screen Reader
  • Accessibility Tips for Titanium Schedule