Ethical Web Development II: Accessibility and Inclusivity

In the previous part of this series on Ethical Web Development, we discussed your responsibilities as a developer in ensuring that you take appropriate care of your customers' personal information. We also took a look at how it was on you to make decisions about how the site or app you're building goes about collecting data, and why you need to be the gatekeeper between your client, their requirements, and their customers.

In this part, we'll take a look at something a little bit different: how to develop accessible sites or apps, why inclusivity is important (and how it's different from accessibility), and how you can do your part to make the internet a better place to work for other developers and the community at large.

The Web Content Accessibility Guidelines

The World Wide Web Consortium (W3C) publishes the Web Content Accessibility Guidelines, or WCAG. The guidelines are organised around making content perceivable, operable, understandable and robust, with testable success criteria that apply across design, content and development.

In practical terms for developers, these guidelines cover semantic coding and how each element should be put together, as well as how you should view development as a concept, touting approaches like progressive enhancement to make sure that essential functionality works across the widest variety of devices, and in the widest variety of situations.

You Should Care About Accessibility.

The conformance levels are cumulative, rather than grades for how hard we've tried. WCAG 2.1 Level AA requires every applicable Level A and Level AA success criterion to be met, alongside its other conformance requirements. Passing an automated scan alone cannot establish that.

Accessibility is not optional just because a client is outside government. UK service providers have duties to make reasonable adjustments under the Equality Act 2010, or the Disability Discrimination Act 1995 in Northern Ireland. Public‑sector websites have additional regulations; in June 2021, the government guidance points to WCAG 2.1 AA. The BBC also required Level AA when I worked with them, under the requirements in use at that time. Agree the applicable requirements early, then test the work against them.

Clear, semantic markup helps people use the page and can help search engines understand it. Descriptive headings, meaningful alternative text and properly labelled controls are useful work in their own right. They do not amount to a guaranteed ranking boost.

I'd make the case to a client in terms of people being able to read, navigate and complete the task. A promised search‑ranking increase is a much weaker reason to fix a form that someone cannot use.

Aside from the technical benefits, accessibility is part of looking after the people who use our work. The 2020 WebAIM Million report found automatically detectable WCAG failures on 98.1% of the homepages tested. That is a striking result, but it describes detected errors on those pages, not a complete manual conformance assessment of every website.

These guidelines are great, but it's easy to worry that following some of these will stifle creativity, putting too many restrictions on how you approach the project you're designing or developing and preventing you from creating something fresh and exciting. That's not the case, though; and that's because of inclusivity.

Inclusivity and Accessibility: Good for Everyone

When you're designing or developing a website, you should keep the WCAG in mind. WCAG does not set a universal minimum font size. It instead requires text to be resizable and sets minimum contrast ratios that vary with text size and weight (for instance, no light grey text on a white background).

This is actually a good thing for everybody. When was the last time you enjoyed trying to read text that wasn't clear against the background or had fun squinting trying to read the small print? Designing an inclusive and accessible website means designing a better website for everyone.

But how exactly are inclusivity and accessibility different? As with a lot of things online, these terms start to be used as buzzwords in the marketing offices of the world and then used interchangeably in the management offices, and then start to lose their meaning entirely ‑ see "synergy", or a long list of other entries to the literary graveyard.

So let's try to be clear: accessibility is about removing obstacles, and inclusivity is an approach to removing those obstacles. For example, let's say you want to meet AA compliance with WCAG 2.1. You have a slick, modern website with all kinds of moving parts and dodgy hacks in the back end, so you decide that the best way to achieve compliance is by developing a separate site on a subdomain that you allow users to reach via a link in the footer or header.

No matter how compliant your accessible version of the site is, it's not going to be inclusive. That's because you're not including people who will make use of that accessible site; you're siphoning them off and sending them elsewhere.

Inclusivity is an approach to accessibility, and accessibility is one outcome of inclusivity (to paraphrase Cameron Chapman) ‑ and this is the best way to build your apps or sites.

Accessibility is Not Just About Disabilities, Though.

Developing an accessible site is about much more than allowing keyboard‑only navigation and providing alt tags for screen readers. It's also about considering the situations that your visitors or users may be in.

Perhaps they're on their phone whilst they're out and about, and they want to find your phone number to call you. They open up your site and that big, beautiful homepage begins to load. You've got an uncompressed mp4 file as a background video, images that are not optimised at all, and all kinds of parallax/GPU‑intensive animation going on every time you scroll.

As soon as the user hits your website, you've eaten a portion of their data plan and when they scroll, the site jumps and jitters as their phone struggles to render the animations that you put together. Not a great impression.

And how about developing countries, or regions that have gone through power cuts? If a user visits from somewhere that doesn't have great infrastructure, it's likely that they'll have a slow, limited or expensive connection.

You should develop with these possible situations in mind. Just communicate what you need to communicate; you'll be providing a better UX to your users.

How About Other Developers?

Aside from making sure you cater to as many potential users as possible, you should also think about the people that will come after you. How many times have you picked up a site being migrated over from a different freelancer or agency, and found that looking into the back end of the code is like lifting up a rock to find all the bugs underneath?

When you're developing a site, write code that makes sense. That sounds like pretty common sense, but let's be honest; when it's half four on a Friday, and you've got to get this one piece done by the end of the day, things get rushed. When that happens multiple times, you end up with a site that you pretty much understand ‑ for the time that you're developing it.

But when that client comes back for maintenance or updates six months down the road and another developer in your team picks it up and has to ask you to explain how it works, are you going to be able to?

Another key element in being a good developer is commenting your code. It's easy to get stuck in and build a well‑put‑together function to handle some obscure or complex functionality, but if you don't comment it you'll definitely forget what it means ‑ and that's not even considering other developers.

Open Source Built the Internet.

As developers, our community thrives on open‑source and collaborative development. It always has, and we should strive to keep it that way if we can! Part of ethical development is fostering a community that works well together and helps each other out where we can. Stack Overflow is a tool that I'm sure we're all familiar with, and it's only there because of the development community working together to solve problems and help people.

In summary, ethical web development involves a lot of things. It can be hard, and it can feel restrictive at first. Your job as a developer is hard enough without all this additional mental load ‑ and communicating with designers to push back on sections that might need reworking is further work. But, it's important ‑ and if you develop sites ethically, you'll be a better, more helpful and more hireable developer. You might avoid a lawsuit or two, too!