Don't be a pr*ck: Frontend Engineers and Accessibility

Basic Accessibility isn't hard and it often isn't even a choice. What's hard is your damn stubbornness.

---

The following code will upset you

You are a Frontend Developer. You start in a new company and you find code like this:

const data = await fetchData();
const a = [];

data.map( item => a.push({ t: item.subject, i: item._id })

Probably your first thought is: WTF is this 💣.

Let's make it nice:

const listOfTasks = await fetchTasks();
const idAndTitleList = listOfTasks
     .map(( { subject, _id } ) => ({ title: subject, id: _id }));

Did you feel the anger in the first sample?

You felt it! You felt it because it would've been so damn easy to make it clean and readable. Hence it doesn't matter "why it came to be there". It matters that obviously no one prevented this code to be merged (missing guidelines or what not) and that you suffer in a sense of Developer Experience.

Developer Experience to you is comparable to accessibility features to people that depend on it.

This is still a very much harmless example comparing how'd you feel if you were dependent on accessibility features because it wouldn't take much time on an atomic basis to improve the sites accessibility but you decided to not do it. And when the app/site is done it'd be a huge thing to adapt so you never do.

Accessibility is not hard

And often not a choice because:

If you do recommend to NOT implement proper accessibility in your application you are actually consulting for something that has legal impact in a lot of countries now. So that's, first and foremost, a very very good reason to inform yourself and your colleagues about accessibility even more.
Source: https://www.w3.org/WAI/policies/

So if you are not developing on / in / for a lonely island then there is a good chance there is legal rules for it.

I have heard this iffy saying so often. From Frontend Engineers, from Designers but especially from Product Owners and Managers trying to intrigue the engineers to "save time":

"We can do it later"

Technically I don't see a problem in "doing it later". But let me take a metaphor for it: A fork lies on your table. You can put it in the shelf right now and your room looks amazingly clean. A rush of endorphines hits your body as it comforts with the tidyness. Easygoing. Now imagine you leave everything laying around in your room for a year. Now start cleaning the room - start even finding anything. You get the point...

"People with disabilities are not the target group anyways"

This statement never holds true. Never. Not in any single case for any application that is used by more than 1 person.

I have heard this in an automotive sector often saying "blind people cannot drive so how would a11y help?".

Ehm well a blind person can still be controlling the digital sales part of the automotive sector. Just to have a very, very clear example. I could add thousands more if you want.

Also bad accessibility always impacts pro users because it often comes with bad keyboard usage.

"Okay I'll add an aria-label and some alt attributes"

Fk no. No no no. Don't just start adding random aria-* attributes or alt/title tags if you do not know the impact. Start with the basics of understanding. Understanding is the crucial point of effortlessly using it and implementing it whilst coding. I would recommend myself but the problem is that I don't have any public sources on my own so I would need to lend you my brain.

• There is an extremely good free udacity course from Google (I really, really can recommend this): https://www.udacity.com/course/web-accessibility--ud891
• Read this: https://developers.google.com/web/fundamentals/accessibility/semantics-builtin/the-accessibility-tree
• Also you can start off at Sara Soueidan. She also has published a new course which you will find a link on her Twitter account to.
• A good read is always MDN e.g. https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/heading_role

Let me prove how easy it can be to improve Accessibility

• Understand that CSS impacts a11y: If you do display: none on an element it is hidden both visually as well as in the Accessibility Tree so your <div style="display: none" aria-label="additional info only for screen readers">... is useless.
• Ensure good ratio on your designs (built-in in the chrome inspector; there is also a lot of Sketch plugins for Designers e.g.) ; https://webaim.org/resources/contrastchecker/
• Using a proper HTML structure is a very good start. HTML by definition (without adding CSS etc.) is perfectly accessible if correctly used. https://developer.mozilla.org/en-US/docs/Learn/Accessibility/HTML
• If you have fancy elements on your side that literally have no effect but looking cool (so content-wise not relevant) then simply hide em' semantically with aria-hidden="true"
• The alt attribute on a img tag is nothing that necessarily needs content. It needs content if the image shown is connected to the content. E.g.: You have a news article and you report about "More and more people visit the new shopping center". Now imagine there is an img tag with a photo showing a lot of people in the shopping center. Then a good alt tag would be alt="A lot of people standing in the new Shopping Center the city" . If however the image is just a random stock picture then it doesn't provide additional information and you should have alt="" (in this case the content lives for itself and the image is just a visual addendum).
• If you use modals, make sure to "Lock In". If you cannot click elements below the Modal with your mouse then you shouldn't be able to tab with your keyboard below it. But many modals do that and it's horrible for people working with screen readers because they often cannot get back to the modal once they left it. I also built one React Library to help with that: https://github.com/activenode/react-use-focus-trap

Now stop being a prick and at least inform yourself a little bit.

Providing a good semantic HTML structure, knowing how and when to properly set alt attributes (most FE Developers think they know this but in fact they don't) and the impact of using aria-* attributes can be a very good start for having basic a11y. That doesn't sound like a huge effort, does it?

Comments

[Exceed Team]

Thank you, this post is very important. Accessibility is something so easy to neglect when you personally don't depend on it.

But the truth is, most of us faced temporary disability at least once: tired eyes, broken arm, noisy place, hands full with packages, and more.

You made a very good point:
Understanding is the crucial point of effortlessly using it and implementing it whilst coding.

Today we shared some thoughts on accessibility too: dev.to/exceedgroup/accessibility-w...

[David Lorenz]

That's the point! Thanks a bunch.

[Adam Crockett 🌀]

In my country, all children are taught a form of sign language, my son here is autistic, he's learning this for a future without words. As a FrontEnd Dev I appreciate the passion for accessibility, the word comes in to our lives not just as information, but knowing what to avoid, walking through a crowd having no choice because the event is set up that way, that's not accessible. That sort of lack of thought is what causes indeed stress.

You are right to push for a more accessible world

[David Lorenz]

Lovely. Thank you for those wonderful insights! Very much appreciated.

[Billy Purvis]

Straight to the point and clear cut with great relatable examples. I really wish A11y was taken seriously a developers took an active interest rather than leaving it to other teams to test and report back.

[yoquiale]

If accessibility were to have a better documentation and had any reward then I'd take a more active approach.

[Billy Purvis]

There are nuances with accessibility and at times it can be very tricky, but I refute there isn't good documentation.

w3.org/WAI/tutorials/
w3.org/WAI/standards-guidelines/wcag/

The tutorials are great and you can inspect all the code. There's countless packages too that help with accessibility for different frameworks.

I really dislike the notion that there must be a reward for it to be worth it. It is morally the correct thing to do, as well as a legal (not that you care, apparently). Hundreds of thousands of people suffer with some form of disability and websites can be impossible for them to navigate. A competent developer should be able to implement basic accessible practices rather than being lazy. The web is for everyone, not just the able bodied - the more we move to a digital first approach for daily life, the harder it can be for people with disabilities if sites don't implement basic accessibility - don't exclude disabled people more than society already does. Be a good person, not a prick.

[David Lorenz]

Would it be a reward knowing it can be costful to be sued? Just to mention one :)

[yoquiale]

I'm from Spain, so I genuinely don't care about the suing part.

[Andrew McCallum]

Now start cleaning the room - start even finding anything

I couldn't agree more. If something's worth doing, it's worth doing now. I believe this is referred to as the the broken window theory

The idea behind this theory is to never let any window broken, every time you found a broken window in your code, just fix it, don’t let it spread in your code base.

[David Lorenz]

Didn't know about that Theory. I just love learning something new. Endorphines hitting. Thanks for sharing.