Intro to Digital Accessibility for Content Creators
Transcript
Winter 2021
Hello and welcome to this Introduction to Digital Accessibility for Content Creators.
In this video, we will cover some basic techniques that creators and editors can use to improve the accessibility of digital content, without specialized technical training.
My name is Emily Baker and I’m an Accessible Technology Specialist in the Center for Digital Accessibility at the University of Chicago.
The Center for Digital Accessibility, also called the CDA, was formed in January of 2020 as one part of a broad IT risk initiative at UChicago that includes network and device security, visual identity and branding, as well as digital accessibility.
We are a team of four digital accessibility professionals who provide consulting, assessment, and training in support of the University’s commitment to providing an inclusive environment and improving the digital experience for users of all backgrounds and abilities.
What is Digital Accessibility?
My colleagues and I are here to help you make your content accessible to everyone. But what does that really mean? It can be said that digital accessibility is the absence of barriers. It means that a web site, application or electronic document can be easily navigated and understood by a wide range of users, including users who have visual, auditory, motor or cognitive disabilities.
In addition to providing an inclusive digital environment, creating accessible content improves the digital experience for all users. An analog in the built environment would be installing curb cuts to remove barriers for people who use wheelchairs, which also benefits parents with strollers, travelers using wheelie bags, and so on. Making things accessible for people with disabilities makes things better for everyone.
WCAG Guidelines
The University uses the Web Content Accessibility Guidelines 2.1 Level AA, which are internationally recognized best practices for public facing web sites. The guidelines are pretty versatile, technology agnostic. Which means that they can be applied in a lot of different contexts.
The WCAG guidelines are organized according to four high level principles, and if any of these are not true, there will be users who will not be able to use your web site, application or document.
Digital content needs to be perceivable to the senses, and operable so that all users can successfully use any interactive elements or controls. Information and the operation of the user interface must be consistent and understandable, and robust, which means functional with a wide variety of technology, including assistive technologies like screen readers or mouse alternatives.
Many of the WCAG guidelines, especially under Operable and Robust, fall into the domain of web developers who build web sites and components and tinker with the code that sort of underlies everything. However, there are a lot of fundamental techniques that creators and editors can apply to produce content that is Perceivable and Understandable. And this is true whether we’re editing web pages or creating documents. Commonly used applications like Microsoft Word or PowerPoint, Adobe InDesign or web content systems on campus, like Canvas for online course content or Voices for web sites, have built in tools and functionality that are designed to help you produce more accessible content without a lot of extra effort.
We’re gonna go over some considerations for content creation in general terms in a way that could apply in a variety of contexts, and we’ll take a look at a few specific examples here and there.
Write Clearly
First, we’ll start by discussing clear writing. It’s important to write clearly across the board whether you’re editing a web page or creating a Word doc. Techniques like using simple language, employing illustrations to supplement text rather than replacing it, checking your spelling, grammar and readability, will all help your content be more readable and understandable.
Use abbreviations, acronyms and jargon carefully. Your audience might not actually understand what you’re talking about if you’re using terms of art that are unfamiliar.
Avoid all caps in your writing. It’s difficult for sighted users to read and screen reader technology can’t necessarily tell whether you’re trying to add emphasis or use an acronym.
Don’t underline anything that’s not a link. Underline is a widely understood convention for hyperlinks, and using it for other purposes can be confusing and frustrating for users who might expect to be able to click on underlined text. Obviously, there are maybe some specific instances where underlining regular text is indicated, but in general, only use underline for link text.
Also, use italics sparingly. This, again, goes to the readability of your text.
Use Good Semantic Structure
Use good semantic structure when you’re creating a web page or document. Break your content into more manageable chunks. For example, for longer documents use sections and organize your content in the manner of an outline using true headings. It doesn’t need to be complicated, but most applications will easily support up to six heading levels.
In the screenshot here, I’m formatting some text in a Microsoft Word document rather than configuring the text to look like a heading. I’m applying the “Heading 2” style from the formatting ribbon.
Avoid skipping heading levels. If you skip a heading level, it will register as an error in most accessibility evaluation tools. But it’s not catastrophic. This is more like slightly disorienting, but you should avoid skipping heading levels if possible.
The main purpose for creating the structure in your content is to provide useful information to screen reader technology. Without it, a screen reader will read all the content out loud from top to bottom, without making any distinctions between headings and paragraphs or other elements on the page.
With this structure, a user can command the screen reader to list all headings without reading the other content, much like a sighted user can visually scan a page for headings to find specific information without reading every word.
Use True List Markup
Use true bulleted or numbered lists. Bulleted lists highlight important points in no particular order, and numbered lists can guide readers through step by step instructions.
In this screenshot, I’m formatting a bulleted list in the content editing tool in Canvas.
True list formatting rather than just typing a “bullet character – space – text” makes it possible for screen reader technology to notify the user that they’re reading a list, how many items are on it, and when they have reached the end of it.
Provide a Descriptive Title
Provide a descriptive title for your Web page or document. Titles are not the same as file names. File names can be cryptic and confusing, so use plain language to create a title that makes it clear what your document is all about.
To add a title, configure the document properties. In this example, I’m adding a title to the document properties dialog box in Microsoft Word. You get there by selecting the Properties from the File Menu. You can add as much of the other metadata as you like. But for accessibility purposes, the title and author fields are the most important.
Titles help users find content and orient themselves without needing to read or interpret all the content. Titles also appear in site maps or search results on web pages, and they enable all users to identify the content that they need. Also, document properties carry over when files are converted to other formats such as PDFs.
Consider Users with Visual Disabilities
A lot of technical specifications are crucial for users who are blind and rely on screen readers, but there are some things that content editors can do to improve the experience for users with other common visual impairments like low vision, color blindness, blurred vision, light sensitivity, etc.
Do not use color alone to convey meaning. For example, in addition to color, you can vary the shapes to help users distinguish between icons or buttons and use patterns to help users distinguish between areas on a chart or a graph.
Be sure that there’s sufficient contrast between background and foreground colors. In this example I’m using a color contrast analyzer tool to examine some text on the CDA web site. The tool is letting me know that the maroon text on the white background meets contrast requirements at regular and large text sizes, according to the WCAG guidelines.
This is the color contrast analyzer by the Paciello Group, and it’s available for download at no cost for Windows and Mac OS. You can use it to examine color combinations for web pages or documents, and I recommend that you see the CDA web site for information about more tools just like this.
For text size, it’s recommended that you use at least ten point type.
Also, avoid using descriptions or instructions that rely only on sight. “Make your selection from the options drop down” is more helpful than “Click on the menu on the left side.”
Write Descriptive Link Text
Descriptive link text lets the user know where a link is going and is understandable in context and out of context.
Avoid using URLs themselves as link text. I’ve got a real world example here from the World Wide Web Consortium site, which makes it apparent that descriptive link text is easier to read and more understandable than most URLs.
It’s especially tedious to hear when URLs are read by a screen reader, which often speaks out URLs letter by letter.
If you’re creating a document that’s intended for print, include the URL, possibly in parentheses, but not configured as a link.
And avoid using the words “click here” and “read more.” This is another affordance for screen reader users, who can browse lists of links on a page. A bunch of “click here’s” listed out of context, are not at all useful.
Provide Appropriate Alternative Text
Include information about the content and function of images in your documents, not necessarily visual descriptions. Consider what you intend the viewer to understand about the image.
The appropriateness of any given alternative text is completely dependent on context. The same image might be described differently when used in multiple locations.
I recommend the WebAIM article on Alt Text, which uses this likeness of George Washington as an example. The purpose of the image, and therefore the alternative text, will vary depending on whether the image is being used to illustrate an article about art history or maybe the painter who created it, versus a biography of George Washington or a list of U.S. presidents. I will provide a link to this article later in this video.
For decorative images with no relevant content or function, use null text. Sometimes that’s a checkbox in the configuration, or sometimes you can use double quotation marks with no text in between in order to specify that an image has no content-related purpose. You do not need to use words like “picture of” or “link to” or “image of” in your alt text.
And be succinct. If the picture really needs a thousand words to describe it, you should probably consider writing more text for the page itself rather than trying to contain everything in a brief snippet of alternative text.
Data Tables
Construct your data tables properly. Format header rows and columns and use the simplest table structure possible. It’s really difficult to make a table understandable when there are cells that span across columns or there are blank cells floating around.
Avoid using tables for visual layout if possible. For example, format your documents to use columns instead.
In this example, I’m using the table design feature in the Microsoft Word ribbon to format a simple data table. There are lots of visible styling options like colors and striping. But the crucial thing is to designate the header row and or header column. Similar functionality exists in most other content editing tools. And the purpose is to allow a screen reader to navigate around a table without losing track of what each data cell represents.
Media Content
Here’s what you need to know if you’re sharing multimedia content on your web page. Videos and live audio must have captions and transcript. If you have recorded audio only, a text transcript is an appropriate alternative. Your captions need to be accurate, and that means you may need to correct automatically generated captions after the fact.
And I keep plugging the CDA web site, but we are able to go into a lot more detail there. We have an entire section dedicated to audio, video and slide shows, including technical guidance, and a list of vendors who can provide captioning and transcribing services.
If you’re creating or editing your own video content, there is support for captioning built into the platforms that are commonly used on campus.
For example, Zoom supports professional real-time captioning by third party providers. It can also perform automatic speech recognition for live virtual meetings. It performs ASR transcribing after the fact for Zoom cloud recordings. And it also has an interface that you can use to log back in to your recordings to correct the captions.
Panopto is another video platform on campus, and it also performs ASR transcribing after the fact for videos that you either create or upload. And it also has an interface that you can use to correct your captions.
Check Your Work
Once you’ve created and formatted your content, you should check for accessibility issues. Most authoring applications have built in tools to help you. In this example, I’m using the accessibility checker in Microsoft Word. You can find it from the Review tab on the ribbon and also from the Tools menu.
For web content, there are multitudes of browser extensions that will perform a similar kind of task on a single web page. I’ve listed a few here, but again, I’ll just mention that we have a section on that … on the CDA web site.
Accessible PDFs
When pressed about accessible PDFs, I usually try to advocate for using a different digital format. It is very, very easy to create an inaccessible PDF and it can be extremely tricky and time consuming to remediate one. If it’s possible to distribute the information in another format, do it. Publish a web page, share a Word, document et cetera.
But if it absolutely, positively has to be a PDF, build it accessibly from the beginning. Unfortunately, this is easier said than done.
Each of these three deceptively simple steps to create accessible PDFs is complicated enough to merit entire webinars on their own, and we obviously don’t have enough time to cover all of that here.
In general, though, this is the process. Create an accessible source document in the original format. Use all the tips we’ve discussed here and then run the accessibility checker in your application to find and fix any issues.
Then when your source document is ready, export it properly to the PDF format. Do not print to PDF. This creates an image based PDF, no better than a totally inaccessible picture of the document. And a screen reader cannot read or interact with it.
If everything goes to plan, all you need to do is apply a few finishing touches in Adobe Acrobat.
Take a Deeper Dive
On this slide, I’m sharing a variety of resources that can help you kind of examine all of these topics in greater depth.
Again, I’ve mentioned this numerous times, but the CDA web site is a terrific resource. We have an entire section dedicated to accessibility for content creators.
There is a really great reference called How to Meet WCAG Quick Reference. It is a customizable web based reference that you can filter for the specific web standards and conformance level that you’re interested in. Remember, at UChicago, we use WCAG 2.1 Level AA. And you can further filter out the guidelines that fall outside of your area of focus, whether that’s developing or interaction design, content creation or visual design.
Also, some articles on text alternatives, I’ve said … I’ve listed several references here that address text alternatives in depth. A lot of WCAG guidelines are pretty cut and dried. But providing good text alternatives for visual content requires human judgment, and as we discussed before, can vary depending on context.
The DIAGRAM Center specializes in making visual content accessible and has a wealth of resources for describing complex images like charts, diagrams, maps and other data visualizations.
The WebAIM site (for Web Accessibility in Mind) covers web accessibility topics, including this great article on an alternative text that I mentioned earlier in the video.
And finally, LinkedIn Learning is a free service for the UChicago community, and their online video courses are a great way to work through technical topics in detail at your own pace. For content accessibility, I highly recommend starting with their courses on Creating Accessible Documents in Microsoft Office and Creating Accessible PDFs. You can work through both of these courses from beginning to end, using the example files to practice on, or just view the chapters that are most relevant.
And finally, if you have any questions, the CDA is here to help.
Check out our web site at digitalaccessibility.uchicago.edu, send email to digitalaccessibility@uchicago.edu, or leave us a message at 773.702.1609.
Thank you for watching. And thank you for your commitment to digital accessibility.