A brief intro for tech professionals on the topic of Web and digital accessibility -- designing, coding, and testing with users with disabilities in mind. Includes assistive technology demos, an overview of WCAG, and how to put accessibility into practice.
Jump to Resources | Jump to Transcript
Watch on YouTube or via the embedded player below.
Resources referenced in the video:
Welcome to this introduction to Web accessibility.
Hello, I'm Dr. Michele A. Williams, owner of M.A.W. Consulting, LLC, Making Accessibility Work.
Using my background in software engineering, UX Research, and as an accessibility specialist, my goal is to provide you a broad understanding of the topic of Web and digital accessibility, explain why it’s important to incorporate it into what you make, and provide resources for you to continue learning how to create accessible and inclusive technology going forward.
As a computing professional you are often, if not always, creating on behalf of others, sometimes known as “users” because they are using what you made. Users are going to be diverse on several dimensions which includes disability. This makes it imperative for you to understand that diversity and account for it in what you create, because a user's disability may impact how they interact with their computing device.
The overall category of devices and tools used by people with disabilities are known as "assistive technology", often shortened to "AT". Let's briefly learn more about AT by looking at them in 3 big categories.
First let’s explore “Operating System Settings”. This refers to the operating system display and interaction settings that users can change based on what makes their computing device easiest to use. I’ll bring up my iPad set to the iOS “Accessibility” settings.
[Cut away to iPad display]
Under these options are numerous adjustments categorized by Visual, Physical and Motor, Hearing, and General. The categories in these settings align with one way to categorize disabilities when thinking about design considerations. Under Visual are options to increase the size of objects on the screen, change the color of the content, or hear the content spoken aloud.
Here’s what happens when we activate “Zoom”. Something like a magnifying glass appears on the screen and we can move this around with our finger. This feature primarily helps people who have visual impairments known as “low vision” and benefit from a larger, magnified view of the screen.
Let’s now go into the “Display & Text Size” option and activate the option “Classic Invert”. This created a view with flipped, or inverted, colors where black is now white, white is now black, and other colors have a high neon contrast such as pink, orange, and blue. People with various disabilities including certain types of visual impairments and Dyslexia benefit from having less white on the screen. This may even seem like the Dark Mode feature; that feature is derived from these color invert features that have been in Operating Systems for many years.
One last feature we’ll explore for now is the tool called VoiceOver. This is what’s called a “screen reader” and it’s primarily used by people who are blind, low vision, or find its audio output easier to digest than reading the screen. The output of a screen reader can also be displayed in Braille using devices called refreshable Braille displays. Braille output can be a supplement or preference for blind users and is the only interaction option for users who are both deaf and blind, known as deaf-blind.
Let’s turn on VoiceOver now.
[VO] VoiceOver on, Landscape, Settings
[Michele] As I swipe right with one finger the system will read aloud what has the current focus and display a black ring around the object as well.
[VO] Notifications, button. Sounds, button. Do Not Disturb, button. Screen Time, button.
[Michele] Note that it announced that the object was a “button” as well as the name of it - this is needed information to announce when you can’t see the screen. We’ll navigate to the VoiceOver button then double-tap the screen to turn it off.
[VO] VoiceOver, on. VoiceOver, off.
[Michele, displaying iPad screen] The "Physical and Motor" section includes options to allow operating the iPad with outside equipment or one’s voice. We’ll return to this a bit later.
"Hearing" includes options to connect hearing aid devices and set caption preferences globally at the operating system level.
"General" includes an option to minimize the number of apps open at one time.
[Michele, on-screen] Every computing device has similar options, so I encourage you to search for “Access” or “Accessibility” in the settings of your personal devices.
Each option will have a description of what it does so exploring them is great way to begin understanding accessibility and assistive technology and, thus, the diverse ways your users are engaging with your content.
The next category to explore is “Software”. This refers to third party software users may install or use online to supplement their experience. People may be using third party software either in conjunction with the OS settings or in place of them.
For example, we saw the iPad offered an option called “Spoken Content”. This produces a “Speak” option when a user highlights text and speaks aloud the selected text as well as highlights the words as it reads.
[Cut away to iPad Notes app to select text]
[Text-to-Speech] “Demonstrating the spoken content feature.”
[Michele, on-screen] This is helpful for many people with reading difficulties including Dyslexia.bHowever, the iOS settings don’t have the exact visual treatment and other options as outside tools such as “read&write” from a company called “TextHelp”.
Here’s “read&write” in action.
[Cut away to TextHelp website using the read&write tool to read text on the site]
[Text-to-Speech] “read&write for work - Award-winning literacy software that gives all your people an instant literacy boost in the workplace.”
[Michele, on-screen] Third party software like this fills the gaps of what built-in settings offer. Thus, to learn what AT software is available, start with what the OS can do then go exploring tools that do the same. For example, there is software called “ZoomText” that is like the iOS “Zoom” feature, and other screen readers like VoiceOver such as one called “JAWS” which stands for “Job Access with Speech”.
The last category of assistive technology we’ll explore is “Hardware”. This refers to using equipment apart from a monitor, mouse, and keyboard, or at least using them in what is considered a traditional sense.
[Cut away to W3C video clip]
In this Web Accessibility video, there’s a power wheelchair user in front of a computer using a “mouth stick” to type on the keyboard. A mouth stick is a stylus but held in one’s mouth instead of one’s hand for people who have more mobility control in their head and neck area than their hands and arms.
[Back to slides]
This is similar to the image I have on the slide of a person using a mouth stick to manipulate their tablet screen.
There are several other electronic hardware devices that maximize mobility such as one called a switch - essentially a big button or set of buttons that can mimic a keyboard or mouse when paired via Bluetooth with the operating system.
In this Apple commercial, the main subject, Sady, uses switch devices attached to the headrest of her power wheelchair to edit a movie in iMovie.
[Cut away to Apple commercial clip showing Sady at computer]
[Text-to-Speech] When technology is designed for everyone, it let’s anyone do what they love. Including me.
[Michele, on-screen] Again, this is an example of maximizing the mobility a user has to operate their device. Notably, some users with mobility impairments use OS settings or software in place of hardware such as with the voice control option in the iOS settings which allow dictating commands and text, or utilizing eye tracking software which brings up options such as an on-screen keyboard.
Again, you can begin to learn more about this by simply exploring the settings of your device and even looking for videos of those settings in use.
Having explored assistive technology, let’s turn now to the definition of “accessibility”. It is the ability for users with disabilities to access and contribute to technology content with their accommodations. That is, people can use the OS Settings, Software, and/or Hardware needed to engage with their computing devices.
While this seems pretty straightforward, unfortunately a lot of Web technology is inaccessible. That is, people attempting to use their adjustments and AT cannot properly access and contribute to content.
Thinking back to the TextHelp website, the site was able to read aloud and highlight content that was text. If the content had been an image of text, the software would not have been able to read it. Yet we find that people often share large blocks of text as images, particularly in social media or when they want a certain visual presentation. This leaves out people who have difficulty reading and use the text-to-speech features like “read&write”, or need to make visual adjustments like the “invert colors” setting.
Making accessible technology requires the attention of the entire development team including designers, coders, and testers, but is often overlooked. In fact, an organization called WebAIM (Web Accessibility in Mind) posted their most recent automated analysis of the top one million Web home pages and found that 98% of them had fixable, preventable accessibility errors.
So what can be done to combat this?
Well one way to create accessible Web technology is to ensure all stakeholders, particularly designers, are familiar with W.C.A.G. (also pronounced “Wuh-cag”) - the Web Content Accessibility Guidelines. WCAG and other accessibility standards are part of the W3C’s Web Accessibility Initiative (WAI). W3C, of course, refers to the Worldwide Web Consortium, a group that proposes standards and protocols for the Web.
[Cut away to website]
Showing now the W3C-WAI homepage, you find their emphasis on the “W3C” Web standards, the “WAI” accessibility standards, and “you” as the technology professional taking everything into account as you work. From this site you will find a wealth of information broken down in the top menu by roles and interests such as “Design & Develop” and “Test & Evaluate”. Under “Standards/Guidelines” you will find information from introductory and overview to specific details about many areas including WCAG.
Navigating to the “WCAG 2.1 - At A Glance” page, it shows guidance is broken down into categories that spell out “POUR” - Perceivable, Operable, Understandable, and Robust. Under each section here you will find some of the actionable guidance contained in the full set of WCAG. Each item is linked to a more detailed page that further explains what to consider and how those considerations help make your technology inclusive of disabled users.
[Cut to WCAG guideline page]
One of WCAG’s items, for instance, is to avoid “images of text” (guideline 1.4.5).
[Michele, on-screen] Like we discussed earlier, large sections of text presented as an image don’t allow people who rely on text-to-speech, magnification, and recoloring to leverage this assistance, and the impact can range from making your page hard to use to making it impossible to use.
While primarily for Web, the WCAG standards are also useful for many other digital products and applications. For example, our “images of text” relates just as much to creating PDF’s and not scanning them to be images. If needed, you should instead leverage OCR (optical character recognition) to make sure the text comes through.
Because of its importance and detail, familiarity with WCAG is an imperative for computing professionals.
Another way to combat inaccessible technology is to ensure developers avoid inaccessible code. Native HTML and app components come with accessibility already built-in, such as inserting a “button” or a “select” dropdown. But many of the Web’s patterns deviate from these standards, particularly in the form of custom code. Reproducing all of the accessibility considerations for a custom element is often complex and thus not done correctly or at all.
Unfortunately, these custom, inaccessible code bases become copied trends and part of templates without intervention. On the slide I have an image I created to drive home the point that assistive technology is not looking at the rendered object on the page (such as the Submit button at the end of a form) but rather the underlying code (as in the HTML “button” element).
When users are making adjustments such as navigating with their voice or listening rather than viewing, the underlying code has to be to standard to be understood by the AT and thus conveyed correctly to the user. There’s even a developer named Ian Pouncey who had a great quote on social media that, “For users of assistive technology, the markup is the user experience”.
The same W3C-WAI site contains standards for code just as it does for design, such as the ARIA properties - Accessible Rich Internet Applications. Ultimately, however, using native elements coded to standard is the first and best line of defense.
A last major aspect of turning around inaccessible technology is to ensure testers are trained on how to use assistive technology while performing quality assurance. Notably, each AT can have different outcomes as in differing browsers. Nonetheless, there are some typical combinations that should be considered not only during testing but all throughout the creation process.
In the Resources I include a page that lists these combinations, such as testing in “high contrast mode” in Windows as is shown on the slide. This is very similar to the “invert colors” option we explored on the iPad.
Normalizing testing for accessibility just the same as designing and coding for it, is an additional major piece in providing access to users with disabilities.
As a final note regarding the typical roles in development lifecycles, I’ll point out a step usually coupled with design which is research. Whether doing foundational work that informs what you’re planning to make, or summative testing that gets feedback on what you have created, the participants recruited should include people with disabilities as well as those without disabilities. I have a more detailed talk about this listed in the Resources.
To be clear, people with disabilities are not coming in to test whether something is accessible - that is the team’s job. Research participants with disabilities should be coming in for the same purpose as participants without disabilities - such as to test usability or inform design decisions. Since disabled users will have a diverse and unique approach to using what you make, it is important to have that represented in your data.
As I wrap-up, I wanted to make sure I noted that while accessibility may be seen as a nice-to-have by some, it is actually the law and a requirement. Inaccessible technology excludes people with disabilities and exclusion simply based on disability was in many ways made illegal in 1990 with the signing of the Americans with Disabilities Act. Other nations have similar protections as well as a global United Nations protection for the rights of disabled citizens.
While the ADA was initially viewed as only protecting against inaccessible physical spaces, U.S. legal entities have consistently upheld that the law also applies to digital spaces because of how important and prevalent technology is to our lives. We must make sure everyone can participate.
So where do you go from here?
Well first is to keep learning. Use all available resources from trusted sources to learn about assistive technology and accessibility, including being mindful to follow people with disabilities and disability organizations on social media. I include a lot of starting points in the Resources of this video.
Then become an advocate and an ally. Constantly ask if the technology you’re using, or building, has considered accessibility.
Lastly, make it a habit to implement what you learn in everything you do. This could mean using WCAG in a large technical project or even just being mindful when creating a Microsoft Word document. For those, you should use the ribbon to create headings and bullets rather than only style the text to look like those elements because again the “markup is the user experience”. More on making accessible digital documents is also in the Resources and remember that every decision is important.
Thank you so much for watching, listening, or reading through this presentation, and I hope it was helpful.
Let’s connect online and keep the conversation going. You can start by writing a comment for this video on the various platforms where it’s posted. You can find me on LinkedIn as “Michele A. Williams, PhD” - note that Michele is spelled with one L. You may also find me on Twitter via my company name at “MAW Consulting LLC” but remove the “i” from Consulting. All the best to you. Bye bye!
Subscribe to my newsletter for digital accessibility tips, updates on webinars and speaking events, and more.
Easily opt-out at any time — no sneaky tricks, no hard feelings.
Ready to get started or want to learn more? Contact me
M.A.W. Consulting, LLC is based in Charlotte, North Carolina, USA
© 2020-2021 M.A.W. Consulting, LLC. All Rights Reserved.
Website created using LeadPages