Three Steps to More Inclusive Web Experiences

When the question “Is it fully accessible?” arises during the course of a project, lots of other questions pop into my head:

  • “Do I fully know and understand the legal requirements for accessibility?”
  • “Is anyone going to have trouble using this website?”
  • “What happens if I get it wrong?”

Very quickly, my worry about “getting it wrong” can keep me from knowing how to answer these questions at all.

Making resources and technologies more usable is an ongoing process, and having a starting line—and knowing why it’s important—are the keys to making it happen. Technical requirements do exist, and they are important to learn. But as with any field, we don’t have to memorize everything to start, and neither do the administrators or educators buying and using products or services. In my accessibility journey, I have found the following steps to be most valuable:

Step 1: Understand Why Accessibility Is Important and How It Relates to Your Mission

Twenty-six percent of adults in the United States have some form of disability, while 14% of students receive special education services. Accessibility is often framed as a legal issue, but it’s really about ensuring that all web content can be used by everyone; the legal requirements are merely a guide for making sure good intentions include follow-through. Any institution that receives federal funding is required by law to meet web accessibility standards. That means the curriculum, software, and tools purchased and used by any public education institution in the United States most likely need to meet accessibility standards as well.

It’s important to know why accessibility matters for you, your company, and your stakeholders (while also paying attention to your own biases) so people aren’t excluded. Bridging the gap between your mission—and making products that are accessible to all educators and students—will help motivate and sustain this work.

Step 2: Define Where Your Starting Point Is and Go from There

To move forward, it’s important to know where you’re starting from and where you’re going. Take your stakeholders on this journey with you. Celebrate learning together! Feeling comfortable with terms and the acronyms is a great place to begin.

WCAG 2.0 AA: The Web Content Accessibility Guidelines (WCAG) Version 2.0 is a set of standards for web content accessibility developed to meet the needs of individuals, organizations, and governments internationally. Level AA refers to a level of compliance described in the guidelines. When we talk about the legal requirements of accessibility, we are usually referring to WCAG 2.0 AA. It applies to any web content or online platform that students, educators, parents, or administrators need to use to learn or do their jobs. These guidelines give detailed instructions on everything from color contrast to HTML markup and line spacing.

VPAT: A Voluntary Product Accessibility Template (VPAT) is a structured approach to reviewing and documenting a product or website’s conformance to WCAG. It allows for details on what areas are being improved, and which areas aren’t applicable or accessible. This information is vital when districts or individuals decide whether a product will meet their needs.

Assistive Technology: Assistive technologies include a wide variety of hardware and software tools used to adapt the experience of using computers or the Internet to meet individual needs. This could include alternative keyboards and input devices, screen readers that narrate the text of the screen aloud, a Braille keyboard to translate onscreen text into Braille, or adjusting settings on your browser to increase text size and contrast for improved legibility.

Section 508: This is the US federal law that recently made the WCAG 2.0 AA the minimum acceptable standards for accessibility compliance.

Step 3: Use Empathy to Strengthen Ongoing Commitment

Web accessibility can often feel like an uphill battle. Approaching accessibility as a continuous learning process will help you build a team and a client base that is invested in accessibility as a standard practice. Making tools that all people can use isn’t an “add-on” or “bonus” feature; it’s the inherent goal of any product or service.

As you build your toolbox around usability and accessibility, bring everyone with you. For example, when you build out personas at the beginning of a project, include details about how they use technology. There is a huge breadth in how people navigate the web or consume media. Microsoft’s Inclusive Design Toolkit illustrates how different people benefit from designing with a particular disability in mind, as in this diagram:

Permanent, Temporary and Situational scenarios impact each form of human interaction. For touch, a person may have one arm (permanent), an arm injury (temporary), or be a new parent (situational.) In that same order for Sight: Blindness, Cataracts, or distraction while driving. Hearing: Deafness, an ear infection, or the loud ambient noise for a bartender. And Speech: Someone may be non-verbal, have laryngitis, or have a heavy accent.

Permanent, Temporary, and Situational scenarios impact each form of human interaction. For Touch, a person may have one arm (Permanent), an arm injury (Temporary), or be a new parent (Situational). For Sight, the scenarios could be blindness (Permanent), cataracts (Temporary), or distraction while driving (Situational); Hearing could be deafness (Permanent), an ear infection (Temporary), or loud ambient noise for a bartender (Situational), while Speech could involve someone who is non-verbal (Permanent), has laryngitis (Temporary), or has a heavy accent (Situational).

Adopting details on interaction style and disability into your personas will help you implement a more accessible design, regardless of the context of a user’s impairment.

As you incorporate accessibility practices into your work, bring stakeholders into the conversation to build shared empathy and investment in the process. For example, when announcing a new set of learning modules with captioned videos, you might highlight how the captions benefit users: “Videos for the upcoming unit all include closed captions and transcripts, making these tutorials easier to use on-the-go with a smartphone, without audio, or with assistive technology.” The details of users' needs may have started with personas, but they translate directly into how you develop and release features.

Finally, keep going and celebrate small wins! You don’t have to be an expert to share what you learn with your team. And you don’t need to have it all figured out before you start. Accessibility is a great field for iterative development because every change along the way makes products and resources better for users: all users.

Here are a few helpful inclusive design and technology resources for you and your team:
WebAIM monthly newsletter
Accessibility is more than a technical problem
Microsoft inclusive design