Change the web for the better. Create things that work well. Create content and interfaces that work for as many users as possible. This is what web accessibility is all about. Before diving further into this blog post, here’s a brief glossary of critical terms that help make sense of the web accessibility landscape:

Web Accessibility Glossary

    • Web accessibility refers to the inclusive practice of removing barriers that prevent interaction with, or access to websites, by people with disabilities. When sites are correctly designed, developed and edited, all users have equal access to information and functionality. (Wikipedia)
    • Assistive Technologies: things that enable and assist users with web browsing e.g. screen readers, braille terminals, screen magnification, speech recognition, etc. (Wikipedia)
    • ARIA: [Accessible Rich Internet Applications] is a spec from the W3C and created to improve accessibility of applications by providing extra information to screen readers via HTML attributes. (a11yproject.com/posts/getting-started-aria)
  • A11Y: [The A11Y Project. A community driven effort to make web accessibility easier (a11yproject.com). How-tos, tips, basics, myths, more.
  • WCAG 2.0: Web Content Accessibility Guidelines as defined by the W3C (w3.org/WAI/intro/wcag)
  • ADA Compliance: The Department of Justice (DOJ) published the Americans with Disabilities Act Standards for Accessible Design in 2010. The ADA standards apply to commercial and public entities that have “places of public accommodation” which includes the internet. Organizations are encouraged to use WCAG 2.0 level AA guidelines to meet compliance standards. (interactiveaccessibility.com)
  • Inclusivity: refers to the idea of designing and developing content for the web that is available to and usable by all people whatever their abilities, age, economic situation, education, geographic location, language, etc. (w3.org/WAI/users)

Accessibility is a buzzword of the moment in the world of web creators. More publications, feeds and events are focused on accessibility than ever. There are increasingly more resources to learn from and tools to test with. Despite that traction, it’s become abundantly clear to me recently that one of the biggest hurdles in adoption of best-practices is familiarity with the topic.

Where do I start? How do I find out where to start? Good questions! My goal in writing this post is to provide some nuts, bolts and jump off points for readers that (hopefully) lead to continued exploration.

Different Ways To Think About Accessibility

In my estimation, accessibility isn’t so much about a finite list of specifics but rather an opportunity to continually expand upon skills sets and best-practices.

I try to approach inclusive design and development like a craft instead of a to-do list; checking things off a list might be the most immediate end-goal on any given day but not necessarily representative of the bigger picture. There are a variety of ways to approach learning new things and framing your own motivation for incorporating accessible design and development practices into your work. Try thinking about the following approaches:

  • It’s fun!: I find learning about and working on web accessibility really enjoyable. I’m not sure I’m able to fully articulate why, but I know I appreciate the challenge and find fulfillment in trying to publish better content to the web and help others out at the same time. Making some updates in my code, running an audit in Google Chrome DevTools and seeing more green (positive) results is an awesome feeling!
  • Problem Solving: I’m generalizing of course, but think it’s safe to say the web development community at large seems to really enjoy pastimes that are puzzle-and-game adjacent. Problem solving, execution, learning new things, collaborating, enjoying the process. Try approaching web accessibility while thinking of it as an extension of that realm.
  • What works for you: Reading content on w3.org and in WCAG specifications can feel ultra granular and a bit overwhelming for many people. Those resources, as examples, are comprehensive and educational – absolutely – but not necessarily engaging. Try to remind yourself to look around a bit more if any particular resource doesn’t feel like it’s working for you or encouraging you to dig deeper (see end of post).

Anticipating accessibility challenges

FYI for developers: you don’t need to officially or unofficially consider yourself a “designer” to appreciate, understand and analyze accessibility in web design. Being able to assess accessibility challenges ahead of build time is a great tool to have in your toolbelt.

Examples: Accessibility Tips 101 for Developers:

  • Always include a <label> element for all controls and inputs
  • Never reuse an id. Keep this in mind if you’re looping over content or generating components that might be used several places in your site/app.
  • Any time you use an <img> tag, make sure you include an ALT tag or ALT text.
  • Give your subheadings and ID so that other publishers for the web can link to individual sections (thanks Aaron Gustafson)

Online tools to test accessibility

Helpful online resources/posts:

Accessibility book recommendations:

Some of my favorite accessibility-related Twitter accounts:

In Summary

There’s not always a “right” way in web design/dev but there is most definitely a way to create and publish things for the web in a way that makes it available and digestible to as many people as possible.

I hope, at a minimum, this post has either helped you learn something new or cleared something up that was previously confusing about web accessibility. Please feel free to reach out directly on Twitter @sgput, I’d love to answer questions or point you in the right direction if you’re looking for additional resources.

Make sure to follow us on social media Twitter / Facebook / Instagram

 

Photo by Landon Martin.

No Comments