Accessibility: Where to Start

About two years before I wrote my first line of code, I worked as a Lyft driver. I drove countless people to work, parties, or the airport. It wasn’t the best job, but it was a great opportunity to meet all sorts of people. One passenger in particular still stands out in my mind.

As I drove up to the sidewalk in front of her house, I could hear her phone declaring out-loud that I was arriving. It quickly became apparent that she was blind. I gave her and her elementary-aged son a ride, first to his school, and then to her office. Along the way, I intermittently heard her phone announce the road that I was turning on to. I listened as she checked the news, weather, and her social feeds. All of it was being delivered to her audibly through a tool called a screen reader.

She and I shared the same small talk I had with most of my passengers, but when I asked her about why she chooses to ride Lyft, she gave an answer that I still think about. She said that she chose Lyft over Uber because she was able to use it. At the time, there were several key features that she was unable to take advantage of on Uber because she couldn’t navigate the app as easily with her screen reader. She used Lyft because it was her only option.

It’s easy to overlook or even ignore the accessibility of a website as a software developer. In addition, developing for accessibility can be intimidating. To a new developer, the basics can be hard enough, but learning how to develop highly accessible interfaces can seem impossible. It’s for these reasons that companies often choose to ignore accessibility issues or developers decide that it “isn’t their job.” But here’s the thing:

As technologists, accessibility is not just part of our job, it is our entire job. Our goal is always to make technology accessible to users. Every line of code shares the same goal of making the software we’re developing accessible to our users.

By not following accessibility standards, we are arbitrarily deciding who should and shouldn’t be able to use what we build.

1 in 5 US citizens has a disability. If we are to assume that, in 2018, almost all Americans are using the internet, that means that 20% of people visiting any given website or web application has a disability. To put that into perspective, only 11% of desktop users are running Internet Explorer 11. On technology teams, supporting ie11 is often seen as a requirement, whereas developing for accessibility is almost completely ignored.

WebAIM, an organization dedicated to making web content accessible to people with disabilities, conducts regular surveys of their disabled readers. In their most recent survey, they found that 60% of people who responded believe that accessibility on the web is either not improving or getting worse. 85% of people responded that improving websites by making them more accessible would have the highest impact on accessibility on the web as a whole. That is the work of web developers.

Like most web developers, I’m not an expert on accessibility. There is a lot to know about what kinds of problems people with various disabilities face on the internet. Although I’m not able to give you a detailed checklist on how to make a website fully ADA compliant, I am able to show you where to start. Even a few small steps can go a long way in improving the access that 20% of our potential users have to our applications. Here’s where to start:

1. Build Empathy

The first and most important step is to take time to put yourself in the shoes of your users. The good thing is that you are probably already taking time to do this for some types of users, but probably not all of them.

One of the biggest concerns when building a fully accessible website is that it is easy to use with a screen reader. I think that every web developer should have a screen reader installed. The good news is that there are plenty of good, open source, and free options.

If you are like me and you spend most of your time in Google Chrome, ChromeVox is a great option. If you have never used a screen reader before, I would recommend trying to navigate a popular and accessible site like the bbc.co.uk, youtube.com, or whitehouse.gov to get your bearings before using it on your own project. This will help you learn navigation conventions that screen reader users expect and it will get you acquainted with the technology.

Another way you can build empathy for your users is by simulating color blindness. The color contrast on web pages is an easily overlooked accessibility issue. There are great browser extensions that will allow you to simulate this easily. I would recommend Colorblinding.

By trying to use your website in the same way that a person with a disability would, I can guarantee that you will find issues preventing people from using your website that a simple audit would miss.

2. Write Better Code

It turns out that many of the things you can do as a web developer to make your website “better” also make it more accessible. In large part, this is because accessibility is moving from being a feature to a requirement in many development processes.

The most important step is to use Semantic HTML. Although a webpage written with good markup isn’t inherently accessible, the markup serves as the basis for making it accessible. Using well written, semantic HTML also has the benefit of making your code easier to maintain and navigate.

It’s also important to make sure that your content is structured well before any styles are applied. Try viewing your webpage without any CSS and see if the flow makes sense. Are your headings in the correct order (i.e. do any h4 tags show up before your first h3)? is there a logical flow to it? If you were to ship it to production without any styling, would a person be able to understand it? These questions are a good place to start to help you see your content and page structure from a different perspective. To a person who is unable to see your webpage at all, they couldn’t care less if you used a cool flexbox or CSS grid layout. What they do care about is that the content makes sense when its read aloud in the order its presented.

Being diligent while building a website will payoff in the future. Taking your time to structure it well, using correct tags like <header>, <blockquote>, or <article> in the markup, and making sure the flow is appropriate will improve accessibility, and maintainability of any project.</article></blockquote></header>

3. Make It Part of Your Process

One of the best ways to create more accessible web experiences is by making accessibility a part of your normal process. Oftentimes accessibility becomes an afterthought or one of those things to do if you “have extra time.” The problem should be obvious: there’s never “extra time,” in a project.

One easy step to take towards making accessibility part of your process involves setting up linters for it. If you are working with a modern JavaScript stack, you’re in luck. There are plenty of eslint packages that you can add to your application in just a few simple steps. If you write as much jsx as we do at Foundry, the a11y eslint plugin is a great place to start. It takes just a few minutes to setup and will give you real time reminders to include alt tags on images, aria labels on relevant html tags, and write good focus management into your application.

The next way you can adjust your development workflow is by considering focus management as part of the UX process. At any point in time, only a single element on a webpage can be in focus. This is the element that the user is currently interacting with. Elements that are focusable by default include inputs, a tags, and select elements. If you are used to relying heavily on your mouse for interacting with web apps, you may not find focus particularly important. However, if you don’t have the ability to use a mouse, or if you navigate the internet non-visually, then you are acutely aware of how big of an impact managing focus can be. Modern browsers do a pretty good job at deciding where the focus should go if a web page is written with well-structured html. However, the shift towards JavaScript heavy applications can make this more difficult.

If you are writing layout rules that make elements appear in a different order than they do in html, for example, the browser will shift focus in unpredictable ways. Also, if you are using a declarative framework like React, elements may not even render until after focus has shifted. This can become a complicated mess to clean up if it isn’t a core part of your process.

Thinking about the user story as a linear experience can help improve the usability of a page for all users, not just those relying on screen readers. Decide on what path you expect a user to take, and make sure during development that people using screen readers are able to follow that path smoothly. If you have sections like fly-out menus or programmatically built forms, make sure that there are adequate shortcuts to and from those sections for users that cannot see them. A blog sidebar, for example, may not come into the focus until after a user has moved through all of the content on a given page. If a non-vision-impaired reader of that blog is able to interact with the sidebar before reading any of the content, make sure that a blind user can as well.

Perhaps the single most popular style rule in modern CSS is this:

*:focus {
 outline: none;
}

There is nothing wrong with overriding the default focus styles that browsers provide, but if you don’t replace them with anything, you’re ensuring that your website isn’t accessible to everyone. Thinking about focus styles on inputs can not only help guide disabled visitors to your website, but can also create a more intentional user experience for all visitors to your website. Consider focus management another tool for creativity and not just a chore that needs to be completed.

Along with linters and focus management, you can leverage the growing collection of accessibility audit tools. You probably already use tools for measuring page speed or performance. If you do, consider also periodically auditing your accessibility. There are many popular third-party tools that will check your website against WCAG standards for accessibility. One tool that I would highly recommend is SiteImprove. You can install it as a chrome extension and run it on any webpage. Chrome also recently added its suite of audit tools called Lighthouse to their DevTools. This includes a fairly comprehensive accessibility checker. It works similarly to SiteImprove. It can be a lot of fun to see how your web app can be improved to make it more accessible. However, audit tools can only do so much. For example, you could receive a 100% on Chrome’s audit, but have your main site navigation be completely inaccessible without a mouse. Audit tools can tell you if you are meeting standards, but they are no replacement for good-old user testing.

For many reasons, accessibility is overlooked. It can seem daunting to developers who don’t have experience with modern accessibility standards, or easily forgotten by teams who have never had to rely on accessibility tools in their day-to-day interactions with technology. When I think back to the woman I met while driving for Lyft, I can’t help but feel a sense of responsibility. Somewhere, teams of developers, designers, sales people, project managers, QA engineers, and business executives all overlooked the accessibility of a feature of their app. Maybe they decided that it was too hard or too expensive. Maybe they ran out of time and decided to revisit it in a future update. Either way, they all made a series of decisions about who should be able to use their software weather they know it or not.
   
In the industry, we all make those decisions every day. Deciding to make a piece of software accessible isn’t a question about profitability, it’s about equity. No matter what part you play in the software development process, you can advocate for better accessibility. You don’t need to overhaul your app tomorrow to make a difference to your users. Put yourself in their shoes, make accessibility a part of your process, and do your part to build a better, more accessible internet.

‍

‍