Ethical Web Development ‑ Part II

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

When it comes to accessibility, there are some very comprehensive (and ‑ let's face it ‑ wordy) guidelines that have been compiled by the W3, called the Web Content Accessibility Guidelines. There are specific sections for development and design, as they face different challenges, but each section offers a full set of guidelines as to how you should approach elements of your project in a way that offers the most support for every user.

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.

It's easy to overlook these guidelines and it's tricky to abide by every single one of the principles every time in the real world. This is to be expected, and as a result, there are "levels" that set thresholds for how well and how closely you follow the WCAG.

For the most part, the majority of developers won't have to stick religiously to these guidelines (although they certainly should try to), but if you're developing for high‑profile or Government clients they may set thresholds that you do have to meet. For example, the UK Government includes meeting level AA of the WCAG 2.1 as part of their accessibility requirements, as did the BBC when I worked with them. This is also the level that's widely considered to be generally accessible by most people, so it is a worthy target to work towards.

Developers should care about accessibility because these guidelines help to keep your markup clean and semantic. This ensures your work is professional, and predictable (in terms of coding techniques), and provides a tangible boost for SEO by ensuring your code is clear for crawlers, laid out in a logical manner, and forces you to fill in alt tags, text titles, language tags and a number of other elements that all aid Google and other search engines in figuring out what your content is, and where to rank it.

Although John Mueller, a Search Advocate at Google, has confirmed that accessibility doesn't directly affect ranking (at least for now) he does mention that when a site has a bad UX, people tend to leave them and that "over time things like recommendations & other signals tend to drop away, resulting in the site being less visible in search".

Aside from the technical benefits of clear and semantic markup, a good developer should care about accessibility because it's the right thing to do. A lot of us are fortunate enough to not have to deal with some of the obstacles that others do, and we should make an effort to make sure we look out for others and work to make people with disabilities more visible and accommodated. A 2020 report on web accessibility showed that a shocking 98.1% of homepages that they tested failed to meet WCAG 2.1 AA standards.

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. One of the elements of the WCAG is text size and contrast ‑ any text has to be a minimum size, and there should be a minimum contrast ratio between elements that are on top of each other (for instance, no light grey text on white backgrounds).

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 while 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!