Accessibility Matters Part Two: Accessibility Best Practices

We heard you! When we reviewed our content survey results, one message came through clearly: there’s a growing need for more focus on accessibility. And you’re right—accessibility affects everyone! In the coming months, we will be sharing more stories that highlight why accessibility truly matters at UC.

Note: This is part two of a two-part series by Brian McNeilly. Read part one called Accessibility Matters: Top Five Common Accessibility Issues.

Accessibility can mean many different things to many different people. No matter what work you do, if you are crafting something for someone else to read, thinking about digital accessibility is important! This blog post includes some high-level accessibility best practices that anyone can apply in their daily work.

Plan with accessibility in mind

Often, accessibility is something people save for the end of a project – running a “final” check to ensure things are good before the project is complete. However, leaving accessibility to the end can set yourself up for failure. As accessibility touches almost all aspects of a project, it is much easier to build solutions into a design than to retrofit content afterward.

A classic example of this is around colors and color contrast. Typically, the “look and feel” of a document are chosen fairly early in the design, perhaps before a single word has been written. Colors have been approved, verified by as many stakeholders as possible, etc. If we leave contrast considerations until the end of a project, we may discover that major changes are needed after the document has been authored.

Considering accessibility at every stage of development will ensure that accessibility best practices are “baked in,” and any checks at the end are to make sure that nothing has slipped through the cracks. Tools like UC’s Quick Reference for Content Providers or the W3C’s Easy Checks for Web Accessibility can be handy references for common issues in digital accessibility. These checklists can ensure that you’re thinking about some of the most common accessibility barriers at any stage of your product.

Use built-in features when authoring content

No matter the format you’re working in – Word or Google docs, emails, websites – the systems that help you create content have built-in features to help generate content quicker and more effectively. When we use these features, not only can we save time and energy, but we will also gain several accessibility features automatically!

Using Word’s Heading Styles helps to ensure that every time we create a new section of a document it has the same font, size, color, and spacing. This feature also ensures that screen readers and other assistive technologies can announce these sections of content to users. Similarly, the built-in list features not only will automatically renumber items as we modify a list, but they will ensure that the screen reader can announce the number of items in a list and any structure created by nesting.

For developers, the built-in features of websites are choosing appropriate HTML elements. Semantic HTML is more accessible and makes code easier to read and maintain. As an example, using a native HTML <button> element will automatically ensure the button receives keyboard focus, has a click-based event handler, announces an appropriate role, and has an accessible name. While all of these things can be added manually, primarily through the use of WAI-ARIA, code will appear cleaner without these attributes that we “get for free” with standard HTML.

Think about your audience and message

Whenever we create content, we try to convey a message to someone. Exactly what that message is and who we are targeting will change a lot of the medium we present it in and the content itself that gets shared. When it comes to accessibility, these considerations are just as important as anywhere else.

Consider an introductory video for middle schoolers about biology vs a biochemistry lecture to graduate students – both might technically be about the same topic, but the tone and level of detail will be substantially different. Thinking about your audience relates to accessibility when we think about how we design alternative text for images or audio descriptions for video content. An audience like graduate students will have a greater understanding of the material and will likely require more detailed, precise descriptions so that learners don’t miss material contained within images. Similarly, an introductory video may be trying to engage learners with new material, so a more casual or exciting tone may be warranted.

Conclusion

While this blog post doesn’t cover every possible accessibility issue you may encounter, armed with the tool to fix these five issues, you should have documents that are significantly more accessible. As always, if you have questions, you can reach out to an accessibility subject matter expert at your location or visit the following accessibility resources: