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?