Why I care about accessibility as a Junior developer and why you should too.

Image source: blog.ai-media.tv/blog/what-does-a11y-mean

I first heard about accessibility when I decided to review HTML and CSS from scratch. I knew a couple of things, like how an img element needed an alt attribute in case something happened to the image and it didn't show up and href attribute for anchor elements. Apart from those two things, accessibility wasn't something I actively thought about while building my practice websites.

For convenience sake, we would shorten accessibility to a11y. I agree it isn't the most intuitive acronym but it does make sense. How? Just count the number of letters after the a and before they y. There are 11 of them so it does make sense.

These practice websites were to test if I was able to use the fundamentals I had learned to build meaningful web experiences - I use experience because that's ultimately what I think the web communicates.

Things were about to change though, I can't remember where and when things started to change but a tweet about a11y by Stephanie Eckles made me think about things differently. Since then, I not only consciously think about when building projects but also test when I encounter a website. I try using the tab key across the page to see If I can access the links, buttons, input fields. It's just one of the ways of checking if a website is accessible to users who might not have access to a mouse or have impairments in their limbs.

Why should you care about web a11y? I think because ultimate you care about a hassle-free experience. Have you ever gone to a website where things were unusually hard to understand, in the form of the text being low in contrast? This would mean the foreground text is hard to distinguish from the background it's on.

I'm definitely not the only one who has had a hard time navigating across a webpage because it is pretty resource heavy and wouldn't wasn't optimized for low-end devices - which I happen to use. This same pain could be seen with sites that aren't optimized for certain viewports - which in some cases, they are mobile devices, which then ruins the web page's experience.

All these pain points are pretty common if you pay attention to them and they are pretty inconvenient but those aren't the only inconvenience on the web. The web is inaccessible for people with disability - that is the way things have been but though slowly changing - which makes them experience those same points abled people get when things aren't working the way they should be. Pain points might make it seem less serious, but inaccessibility hurts people and prevents them from accessing resources. Let's take a use case:

Folake, a grandma in Lagos, Nigeria has a personal computer at home. Her grandson uses it to fill out certain information and updates it on the website. He'd shown her how to do it but because her vision has dwindled with time because of old age, she finds it hard to fill the form because of the low contrast of the texts. This low contrast makes it hard to fill out the required form. What we've done is prevent a user from accessing a product that could help her out. We shouldn't do that.

That's just one case but certainly not the limit of accessibility. In an HTML document, accessibility is pivotal. Visually impaired users depend on screen readers to make sense of what we create and this is why semantic elements are vital. Semantic elements give structure to our whole document so that when it is eventually readout, the user can make sense of it. So, something like this:

the … just indicate HTML elements left out of the document.

...
<header></header>
<main></main>
<footer></footer>
...

in contrast to:

...
<div class="header"></div>
<div class="main"></div>
<div class="footer"></div>
...

The first code block shows a structure for our content in a way that's not only more readable for other developers but also to screen readers.

We, therefore, need to intentionally create web experiences that shouldn't exclude anyone from accessing what the web has to offer. I see accessibility as extending the ease of use to everyone. The examples above are just some of the ways that markup can be made accessible but there are a plethora of resources on the web to help you get started on the basics. It certainly isn't everything but slowly it helps us build a conscious attitude of creating experiences that can be fully enjoyed and don't sacrifice visual appeal.

Another noteworthy point to mention was the wrong notion I held that building accessible products would inevitably sacrifice the supposed visual appeal and wow feeling I wanted to evoke from users. This isn't so. Accessibility and appeal aren't mutually exclusive. I'd even argue that they complement one another. This is because the most appealing experiences are where the interactions are hassle-free. So, the true wow feeling is evoked when interacting, navigating and accessing content on the web is as intuitive as possible.

I certainly acknowledge the fact that as a junior developer, there are a plethora of things to learn. Libraries and frameworks that seem vital to getting a chance at the job market. I certainly believe that even in these jobs, an eye for accessibility would be vital. Not only in the job we want to pursue but also in our building for the wider web.

Everyone deserves to access hassle-free web content. As junior developers, we can work towards creating that. It might look daunting at first but it really isn't. We want to make sure that anyone, no matter where they live, what device they are on or what disability they have can access the web. So, what do you say? Would you join me on this journey to making the web as accessible as possible?