NGL, I was a little overwhelmed when I sat down to write this article. There are so many things that immediately flooded my mind—take out any extra divs; use links for URLs, use buttons for events and actions; use semantic HTML instead of divs everywhere; use variable fonts… the list went on and on. But, I finally settled on a single, practical thing that people can do to make their website better:
However, when I’m talking about reach, I am not just talking about people who are blind and rely on assistive technology—such as screen readers—to do their banking or pay their utility bills. I’m not just talking about people who are deaf who need captions on videos. I’m not just talking about people who are colorblind, who need color contrast so they can see what is on the page. Sure, this is where our minds automatically go when we think about accessibility, but I want us to think beyond that.
It’s neither just about having a disability nor about having a disability
That’s an outdated way to think about it—and too reductionist for the complex landscape of the world today. Think about it: who only accesses a website when they are at their desk in a well-lit area, while wearing noise-cancelling headphones, and staring at a beautiful retina display? A very small group of people, and, ironically, usually only the people who are making websites for everyone else. Not a very realistic way to think about any of this when our intended audience is global, is it? Instead, let’s start thinking about the plethora of ways someone could interact with the websites we create.
Let’s think about the different kinds of devices they have, what their physical condition might be at that moment, and maybe even what their physical surroundings are. Let’s make sure we are reaching as many potential users as possible- no matter what device they are on, no matter where in the world they are. This is how we can break past our own mental barriers and really think about what we need to provide in order to increase the number of users we can reach.
Make things easier
If you’re a UX or visual designer, maybe this will inspire you to come up with some fresh perspectives for your existing user personas. Plus, it’s easier to get people on board if your persona examples include puppies. It’s not my rule; it’s just how it works. I’d personally lean toward kittens… maybe puppies and kittens? But I digress.
If you’re a developer, you might not think that any of these things are within your power to influence or control. As a developer myself, I don’t particularly agree with this mindset; but for the purpose of successfully writing this article, let’s pretend for a minute that I do. Let’s look at three things that developers can do to help increase the reach of the websites they work on.
Get all of your page content into landmark regions
From a practical perspective, this most commonly means header, main, aside and footer, but there are a few others as well—read up on them in the ARIA spec for the full list. What is the reason you want to do this? Well, one of the handy ways that screen reader users navigate around the page is by—you guessed it—landmark regions. The W3C’s WAI-ARIA website has a great example of the different kinds of screen readers using this feature, so be sure to check it out and see just how helpful it really is! If you’re working with page templates it can be easier than ever to make sure the primary template is set up correctly, too. This is definitely one place where developers can help make it easier for some users to successfully and easily use the sites they help build.
Add automated checks
We’re still pretty early in for the number of accessibility issues we can check for in an automated fashion, and you can still have a website that completely passes existing automated checks but is still inaccessible. That being said, it’s still worth getting it into your automated build process now. The bonus is that you can improve your codebase as new automated checks come out, which gives you time to get used to the existing checks. Use a template linter for static checks. Some IDE extensions can give you real-time feedback while you write your code! Automated tests can be used for dynamic code checks.
Add accessibility to your mental checklist
Heck, add it to a physical checklist until it’s ingrained in your mental checklist. Either way, get it in there. Here are some ideas to get you started:
Ask about accessibility if you don’t see any annotations on the designs or feature specs you receive.
Check the keyboard focus order when you’ve got the site up and running locally or in a container; TAB around and make sure you can get to all of the interactive elements.
Review PRs with accessibility in mind. If someone has used a link where they should have used a button—or worse, they’ve used a div with no keyboard support—then give that feedback. This might mean you have to go remind yourself (or learn if you were never taught) what native browser support already exists for interactive elements.
Stay compassionate and curious
No matter what your role is, be compassionate toward the users you already have. Be curious about the kind of users you might not have…yet. Be curious about the ways you can increase your reach by thinking outside the box of “everyone does it this way.” We are the ones who have created the web and the limits of what it can do, and we’re the ones who will take it to the places it can go next. Think outside of the machine you develop on, and be curious about the possibilities of a more inclusive experience that reaches more people.
Psst! Create a DigitalOcean account and get $200 in free credit for cloud-based hosting and services.
Great article Melanie. You hit the nail on the head when you mention “making things easier” for everyone in any given situation.
And thanks for the 3 simple tips for developers.
One automated testing tool I’ve found invaluable in my current job is Storybook for HTML components. I’ve built a UI without any front-end frameworks, but Storybook fully supports raw HTML components. This means it’s easy to test accessibility at the authoring stage with Storybook’s inbuilt Axecore checker.