Five ways to include d/Deaf users in your designs

More than one in twenty people—an estimated 430 million people—experience disabling hearing loss according to the World Health Organization’s 2021 fact sheet on deafness and hearing loss. Some are functionally deaf, having little to no hearing. Others are culturally Deaf with a preference for communicating with sign language. A lack of public awareness and familiarity with d/Deaf people’s needs is still common, which can lead to oversights in the designs of smart devices, web content, mobile apps and communication styles. Let’s look at five ways that we can improve online experiences for d/Deaf users.

a small smart speaker lit up to indicate its listening

1. Include visual indicators of audio cues

If your presentation or device relies on sound alone, that isolates and potentially endangers functionally deaf users. Provide visual indicators in addition to audio cues to lessen any confusion for people who can’t hear errors or successes in a process. You also need to provide a visual indicator for each audio cue in the context of what triggered it. If you don’t, users might not know what the visual indicator refers to.

The Internet of things

Smart devices like talking speakers promise to make our lives easier, but their very nature excludes d/Deaf users who can’t hear those devices or communicate in ways that those devices understand. A talking speaker without a visual display poses an accessibility barrier. Some device makers offer add-on products that have screens, captioning, and access to common actions, but those don’t offer equivalent experiences yet. Researchers have identified several gaps in home automation for d/Deaf users [PDF] with appliances that rely on sounds.

2. Provide text equivalents of audio content

Any communication that contains sound, such as streaming video and audio materials, needs to include visual equivalents. That includes transcripts for podcasts and accurate subtitles for all videos. Beyond word-for-word captioning, you should also indicate who’s speaking as well as any important sounds, like a doorbell ringing or a window breaking. Tag your accessible videos with #captioned.

Video conferencing

The pandemic thrust us into endless video calls, a communication style that d/Deaf people can find challenging when there are many speakers. Enabling auto-captioning can make these conversations more accessible than they would be otherwise. Meryl Evans, who uses lipreading in combination with captions, recommends considering these features when selecting an auto-captioning tool:

  • Readability of captions: formatting size, color and scrolling
  • Caption placement
  • Accuracy of captions
  • Synchronization options
  • Caption flow and movement
  • Support for saving transcripts
Auto-captioning in use during a webinar. The presenter's slide is about a bird called a grackle and how it relates to some software. The speaker's words are not accuratley captured by the auro-captioning though.
Figure 1: Auto-captioning during a live webinar. It’s not always great.

Automatic captions are not perfect—do not rely on them when posting pre-recorded video—but they are a useful accessibility tool for video calls. If possible, clean up captions before posting webinar and conference recordings.

3. Provide sign language

Providing sign language interpretation and captions for content can help deaf sign language users—especially for online webinars and conferences. More and more people are consuming video content in sign languages and more people are creating their own signing videos to communicate online. Keep in mind that sign languages vary across the globe; know your audience and adapt which sign language is used in your videos.

'Let it Go' from Frozen performed with sign language
Figure 2: Screen shot from a video in which the music ‘Let it Go’ from Frozen is performed with sign language.

Video chat

Providing video options in chat apps is crucial for including deaf sign-language users. A Deaf American Sign Language instructor I had emphasized how video-phone technology on devices like smartphones has dramatically improved sign language users’ ability to communicate easily with each other, compared to using relay services and text-telephone devices.

4. Write with d/Deaf people in mind

If you’re interested in creating better written content for d/Deaf users, read Deafness and the User Experience by Lisa Herrod. Her guidelines when writing for the web include:

  • Use headings and subheadings
  • Use plain language whenever possible
  • Avoid unnecessary jargon and slang
  • Provide a glossary of specialized vocabulary
  • Write clearly and concisely to help readers avoid misinterpreting what you’ve written, which will help all people readers, not just those with disabilities

5. Test designs with d/Deaf people

There’s a saying in the disability rights movement: “Nothing about us without us”. In essence we cannot build systems for people with specific needs without involving them in the process. We might know all the right success criteria to meet, have confidence in our transcripts and captions, yet we are not our representative users. It’s essential to get feedback from d/Deaf people during usability testing of wireframes and prototypes, before going live with designs that might be excluding them.

Conclusion

Understanding d/Deaf users’ needs is crucial for creating systems that allow fair and equal access. When designers and developers consider these needs, it helps teams build systems that go beyond a reliance on sound to include d/Deaf people.

Global Accessibility Awareness Day 2021

The third Thursday in May is Global Accessibility Awareness Day (GAAD).

The purpose of GAAD is to get everyone talking, thinking and learning about digital access and inclusion, and the more than one billion people with disabilities/impairments.

GAAD homepage

Spring is all around here in Texas, with loads of beautiful blooms like these poppies—a flower often associated with war casualties in the West. It seems like a poignant symbol right now as we assess the loss of lives and survivor health issues of those affected by COVID-19, including millions of people with disabilities.

Beyond trying to avoid physical sickness, disabled people have faced enormous challenges in getting tested, treated and vaccinated. The US healthcare system and government social safety net programs are enormously difficult to navigate with numerous barriers for people trying to get information digitally. A few examples:

  • Coronavirus maps and data in unstructured formats
  • COVID-19 websites that don’t work with screen readers
  • Drive-through only testing and vaccination sites
  • Critical information missing text equivalents, like video captions
  • Vaccine-finder websites with poor mobile support

I spend dozens of hours every week evaluating digital experiences as an accessibility engineer. It’s my job to find weaknesses in the ways information is presented to people. Most of the time, I’m documenting code issues that by themselves are small barriers but combined across a website cause enough inaccessibility that people can’t do what they want to do. I wonder how many disabled people already struggling in a culture that sees us as lesser couldn’t get a test or can’t schedule a vaccination because the people who built these websites didn’t even consider our needs.

I think about my needs as an autistic person with ADHD and bipolar disorder. I’m easily distracted and easily nauseated by moving content. The media query prefers-reduced-motion was made for me. I want to rid the web of every auto-advancing carousel I see. But despite a lot of evidence carousels are ineffective, they are still ubiquitous.

Every day sees more research about why digital accessibility is necessary, and it comes with endless anecdotes from people using assistive technology about how the web and mobile landscapes are still wildly unusable. This problem has been framed as an empathy problem, a coding knowledge problem, even as just a cost problem. So, how do we get designers and developers to care about the needs of the disabled?

It’s clear that accessibility as a concept is not considered a core tenet of good design and development by the establishment. Focus remains largely on the normative desktop browser experience that centers sighted, hearing users without cognitive or mobility impairments. It’s hard to imagine that there is much more we can do in this fight for visibility and inclusion.

I hope this GAAD, you believe you have a right to access information and will demand that right be honored. The time has passed where anyone creating for the web can plausibly deny knowing about accessibility. Whether it’s pointing out missing captions and alt text on social media or contacting customer service about issues a site has supporting assistive technology, each of our small voices can combine into a collective clamor for inclusive design.

My Accessibility Journey

This post follows my path to discovering a passion for accessibility and landing my dream job as an accessibility engineer.

Starting out on rocky flats (2000-2007)

It took me several years to become a decent web developer. Self-taught, I learned HTML through view source on webpages; I used code snippets from online tutorials; I built nested tables for layout. As the browser wars raged, most people didn’t care if the code was good so long as the website looked pixel perfect.

a screenshot of a dated website with the graphical heading bienvenue, three columns with left navigation, text in the middle, and a right rail with a link to email address.
My personal website circa 2000

During university, my plan was to be a high school English teacher. My last semester, I realized I enjoyed coding more and would make a better wage building websites. Two months after graduating, I started my first full-time tech job. I got hired because I was the only candidate with any web experience. Acting as designer, developer and content author, I built the first website for a small manufacturing company in late 2000 as the dot com bubble burst.

screenshot of the Texas EIFS homepage circa 2000. There are several images without alt text.
Texas EIFS first website circa 2000

After a couple of months, life took me to California where I got my second web developer role, this time for a manufacturing software company. I distinctly remember coming in to interview and having to do a coding test to prove I knew HTML. In this job, I learned how to work on multiple projects and maintain several different websites. I helped them with their first website redesign, as well as create a separate website for user conferences.

screenshot of the QAD software website hoe page with a left rail and top tabbed navigation.
QAD homepage circa 2002

I spent most days fielding requests to update website content. Towards the end of my six years at QAD, I learned about portal and content management systems (CMS) as we went through a second redesign. This helped me get my next web developer job, which was at the CMS company, back in Texas.

Hiking through the forest (2007-2012)

It was 2007 and I needed to know CSS for the task of redesigning a website from a table-based layout and static HTML into a CSS-based layout with content in a CMS. I picked up a book that changed my life.

book cover for designing with web standards. it shows the top half of the author's head wearing his iconic blue beanie hat.

Designing with Web Standards

Jeffrey Zeldman

For a self-learner like me, Zeldman’s seminal book helped several pieces fall into place. I learned web standards were a thing and there were actual guidelines for creating semantic webpages. I learned CSS and how to keep design separate from content. I started reading two newsletters: A List Apart and Sitepoint. My world just opened up when I found all these people writing about the web standards way of doing things. I had my first introduction to accessibility in this 2007 article, JavaScript and Screen Readers.

screenshot of the vignette.com homepage circa 2009. it has top navigation, a hero banner, then a three column content area below.
Vignette website circa 2009

I learned from a co-worker that the University of Texas at Austin had a program with an “information architecture” (IA) track and in 2009 I started graduate work on a Master of Science in Information Studies degree (a.k.a. library school). The curriculum wasn’t as robust as I hoped, but it gave me a flexible framework to explore my interests around usability and accessibility. After 3.5 years of working full-time and going to school part-time, I graduated in 2012 with an endorsement of specialization in user experience design (UXD). This included two courses on making systems work for people with disabilities.

screenshot of my academic portfolio home page.
Academic Portfolio circa 2012

It was around this time that mobile browsing and responsive design were getting real attention from the development world, along with HTML5 and CSS3. I incorporated these technologies in my projects but my career desires were shifting left from developing to designing. I wanted to do user experience design work.

Switchback up the north face (2012-2020)

I tried for years to improve our user experience process at work. I advocated for creating prototypes and using those for low-fidelity usability testing of all our application changes. There was interest but no commitment. While I was able create more functional design documentation over time, we had only one project that included personas, wireframes and testing with end users.

wireframe of the agenda builder project.
Agenda Builder circa 2014

In 2015, I shifted my focus again, this time to accessibility. I performed the first accessibility audit of OpenText’s corporate website using the W3C’s Web Accessibility Initiative Easy Checks – A First Review of Web Accessibility. In retrospect, this was a transformative act because it started the accessibility conversation with Marketing and IT at OpenText. I also started my blog which let me explore usability and accessibility issues in the wild, improving my auditing skills.

I learned as much about accessibility as I could through webinars, online courses, Twitter and conferences. I’m very lucky to live in Austin where the AccessU accessibility conference is held each spring. In 2018, I learned about the International Association of Accessibility Professionals (IAAP) and certifications available. In 2019, I passed the exam for the Web Accessibility Specialist credential after years of checking websites and fixing accessibility issues.

IAAP WAS certificate for Rachele DiTullio awarded March 19, 2019.
Web Accessibility Specialist certification

Integrating accessibility at work was slow going with many struggles. In 2020, I started looking for a job with an accessibility-focus, somewhere that accessibility is valued and non-negotiable. Just after I took the next IAAP exam, Certified Professional in Accessibility Core Competencies, COVID-19 interrupted everything. I decided to halt my job search until 2021 to see whether OpenText would come into compliance with the Accessibility for Ontarians with Disabilities Act (AODA) by 1 January.

Reaching the summit

The new year came without any firm support for an accessibility program in IT, however Marketing pledged not to publish any new content that does not conform to WCAG 2.0 level AA, which I consider a huge win.

On the side, I picked up an accessibility contracting job and had my first exposure to a robust accessibility testing methodology. Another piece fell into place and I learned so much in six weeks about the process of testing as well as how to test native mobile applications. Soon after, I started interviewing for an accessibility engineer position at another accessibility firm.

I wanted a remote-only position after all this time working from home during the pandemic. I wanted a raise. I wanted to find meaningful work. And I got the job! I’m very excited to start this next chapter of my accessibility journey.

In my exit interview, I let my former employer know that I didn’t feel right working on websites that excluded disabled people. It felt good taking a stand and finding work that will improve information access for everyone.