The Role of Accessibility

Accessibility in web design is often an afterthought, at most a designer will care about color contrast, text sizing and other elements meeting the visual part of the Web Content Accessibility Guidelines. While this is something to encourage, it doesn't even scratch the surface of what's needed for the end product to be actually accessible.

For a website to really be accessible, it's up to the developer as well to code with that in mind. From adding alt attributes, using WAI-ARIA or not using <div> for all content, all these approaches and everything else outlined in the WCAG are what can really help create more accessible websites.

So why are we talking about designs if it's a developer's problem to implement the accessible parts? Because a developer can only build what was designed correctly in the first place. If a designer is tasked with creating a design for a site, they have the first say in what parts will be accessible.

Accessible vs Aesthetically Pleasing

When you visit an accessible site, it could look ugly. In fact, it may look old and outdated in many different ways compared to the trends you can find on Dribbble or Behance.

Any accessibility aware designer or developer who inspects such a site and discovers that it's accessible would then sympathize with whomever designed or developed the site. I mean, they had a different goal than making it look good, right?

This is the problem with accessible markup on the web, the belief that an accessible site built for everyone can't have good aesthetics as a goal too, because it's difficult to build a website that looks good and also works for everyone.

In a sense, these simultaneously beautiful and accessible websites would be accessible despite the design, not in conformance to it. Someone explicitly chose to build a custom card component that tries to be accessible or to use pages instead of modals when possible to avoid the common pitfalls of hijacking the page.

These choices weren't enforced by the languages involved, or the technologies powering the web, they weren't enforced by the programs used to design the site or the frameworks used to build it. They were enforced by people who care about others and wanted to design and build something for everyone.

Running away from the problem

The tools we use to build the web may not enforce accessibility best practices, but it's common for companies based in the US afraid of violating the ADA to look for workarounds, shortcuts and ways to sidestep the man hours it takes to build an inclusive product.

They don't want to tell their developers to write accessible markup or to tell their designers to care about designing accessible interfaces because these initiatives could mean hiring more skilled employees or training their existing staff. They just want the equivalent of a normalizer or build tool to do the work for them.

Such tools exist in droves, not linked in this post but easy to find with a web search for "accessibility widget". They all parrot the same promise, pay a small monthly fee and import it and suddenly your whole site is accessible to all and lawsuit-free, does it sound too good to be true?

That's because it is. There's no shortcut to making an accessible website. These websites aren't accessible because the people building them chose to be inclusive, they're accessible (if at all), because they're trying to sidestep legal obligations.

Maybe one day we'll have build tools and external scripts that can truly make our sites accessible. Maybe even further in the future we'll have these tools for free because that's exactly what an open web should cost. Today, some tools exist that achieve the goal some of the time. I'm sure if you're paying a premium for accessibility on your websites, you don't want it to only work sometimes. You wouldn't want it to go away when you stop paying the monthly fee; because under the hood, your website isn't inclusive or accessible. The widget didn't change the problems with your code and designs, it hid them.

So what if you're building or designing a project for yourself or you're a company who wants to build something inclusive but you can't get an accessibility professional to manually audit your designs and test your application?

Learning to build differently

There's no end to the references online for writing accessible markup. I don't want to outline some reference or principle as an absolute because, as it turns out, making inclusive interfaces is not easy and thus is open to a lot of subjective views.

A good starting point that I've been following is the Web Content Accessibility Guidelines Quick Reference, this shows you where to start in terms of making your content accessible. In essence, this is really all you need but a cursory read will reveal that it's not the easiest resource to parse. If you're a designer or a developer, I recommend you start here; I'll also include other more approachable resources below.

For designers

Countless plugins exist for tools like Figma, Sketch and Adobe XD that allow you to check contrast, make sure that font sizes are appropriate and make sure that your content is approachable.

I use Figma, so I can't speak for other tools, but I use the Able and Focus Orderer plugins to both check that my colors are approachable and my designs are keyboard ready.

For developers

the W3C have also created a draft of how to use ARIA when building websites, this is an essential read if you're a developer who wants to build more inclusive websites.

For those who prefer to approach this with developer documentation rather than reference documents, the Mozilla Developer Network has a wonderful set of guides on Accessibility. These include HTML guidelines, CSS and JavaScript best practices and the basics of using ARIA as linked above. What they also offer is a summary of how to work with mobile devices to be more accessible. So far in this post I've focused mostly on websites since I'm a web designer and developer, but mobile is an equally large if not bigger part of this equation to consider as well.

For a while now, I've been a huge advocate of the principles of inclusive design. Case in point, I think everyone should check out Inclusive Components. It's a set of docs outlining how to make common component patterns more inclusive and accessible, the author also wrote a book as well as a post on inclusive design that I highly recommend you give a look.

Bringing it all together

In addition to these resources, I'd like to share some tips from my learning journey that I think can accelerate the process of building inclusive sites. This is by no means a summary or absolute reference, but simply guidelines I picked up along the way that I think can help ease the learning curve a bit.

Semantic HTML is here to help

HTML is made for everyone and just using semantic HTML elements for their purpose already goes a long way. For example: if you need to make a list, there's no reason to make a custom <mylist> component in your framework of choice if <ul> and <ol> exist. More on this is covered in how to use ARIA and on the Inclusive Components site.

You can still use tools

Earlier, I mentioned that you shouldn't use a widget that automatically modifies your site and makes it accessible in one go. While this is true, there are tools to augment the development process and help you stay within the Web Content guidelines without having to memorize or to always have the guidelines as shorthand. Examples include Eslint's JSX-A11y Plugin for React users that helps you write more inclusive markup, alternatives exist for Vue, Angular and probably whatever framework or library you're using as well.

Simple sites are not bad

I know that in the age of CSS frameworks being so prevalent and JavaScript frameworks allowing us to create feature-rich and content-rich websites it's easy to scoff at such a remark, but making your website simpler in terms of its markup and navigation can go a long way. A simpler website requires less markup, less JavaScript and probably less CSS as well. It's a lot easier to audit such a site yourself to see if your elements are accessible or not.

Develop with understanding

When keeping non-sighted users in mind while developing your site, it can be difficult to know the impact of adding an ARIA label or role or the impact of using a link tag to build a card. Installing or enabling a screen reader on your operating system can fix this, use it to audit your own website and see if it's truly easy to navigate using the keyboard and if all the content is there. Bonus points if you do it blindfolded for the extra immersion.

Know your demographic

If you're building a site assuming your content is not going to be useful for a non-sighted user or a user with motor problems or visual/auditory requirements, research your audience and see if your website is indeed only used by people outside those demographics. Chances are if your website is big enough and frequented by enough visitors, this isn't the case.

In short

The Internet exists for all of us, not just users who don't have accessibility concerns. It may be difficult to spend the time learning and developing with accessibility in mind, but your pages shouldn't be yet another walled garden that's only accessible to your perceived demographic. The steps you take to make your websites open to everyone may seem thankless; but every time someone who needs those changes visits your site, I guarantee you they'll be grateful that they're enjoying a website that's built with accessibility in mind.