The end of my coding bootcamp is approaching and it really feels like we - my cohort mates and I - are scaling up: in skill development, in project scope, in preparing for career transitions. While we’ve still got a bit of work ahead of us before we finish our program, it does feel like we are in the clear from most of the Immersion madness. Now that we are regaining our free time & our mental energy and are able to be a bit more thoughtful and reflective on the software dev work we are doing and want to do, we must get in the habit of thinking about how other people - especially people who have wonderfully different perspectives - will interact with & be affected by our web apps. We’ve got to get in the habit of developing with inclusivity and accessibility in mind.

When people hear about making the web accessible for disabled people, maybe the most immediate thought is “ok, how can I make my site accessible to someone who is blind and cannot see it?” However, the spectrum of functional disability is vast. There are 61 million people in the United States living with a disability and those disabilities range from mobility to cognition to independent living and self care; sometimes these disabilities are temporary, sometimes they are lifelong. When developing our apps, we must shift our perspective to consider what issues disabled people might face when using these apps and we must strive to eliminate those barriers… if we don’t, we are effectively excluding 25% of the US population.

This has been recognized by the World Wide Web Consortium (W3C) since the mid 1990s. They are the main international standards organization for the Internet, and in 1999, W3C released the first edition of the Web Content Accessibility Guides (WCAG); in 2008, they expanded on those guidelines and released WCAG 2.0.

WCAG mandates that websites be POUR: that is, perceivable, operable, understandable, and robust to its users. Let’s touch briefly on these four principles.

To be perceivable, a website should:

• Provide text alternatives for any non-text content
• Provide alternatives for time based media like video and audio
• Create content that can be presented in different ways without losing its integrity ie its meaning or structure
• Make it easier for users to see and hear content

To be operable, a website should:

• Be fully operable via keyboard
• Give users ample time to read and use content
• Not be designed in a way that is known to trigger seizures
• Help users navigate, find content, and determine where they are

To be understandable, a website should:

• Make text easy to physically read and mentally comprehend
• Be predictable and both appearance and functionality
• Help users avoid mistakes and correct them if they occur

To be robust, a website should:

• Be as compatible as possible with various user agents, such as assistive technologies

There are three levels for complying with WCAG guidelines: A, AA, and AAA. If a website is Level A, congrats. They have done the absolute bare minimum in following federal guidelines and are providing the most basic web accessibility features. What everyone in the the professional software dev world should instead be striving for is at least Level AA, which addresses the most common barriers for disabled web users. Level AAA can be achieved by providing the most complex and comprehensive level of web accessibility. Being AAA compliant is no easy feat, but there are a couple of features that are easy to implement in an already AA compliant environment - here's a link to WCAG's overview where you can familiarize yourself with accessible features.

Get in the habit of thinking about these things. Take one for the team. Show some empathy. What we are designing and developing as software engineers has the potential to impact people’s lives in meaningful ways. Let’s leave this world better than we found it.