Disclaimer: This is not going to tell you every single accessibility principle, but what you can start implementing or thinking about as soon as possible in terms of development.

You can read about W3C accessibility principles here.

Now to start off the article, I'm an accessibility lover! and I love to make all things accessible. This is the reason why I'm writing this article.

Let's define what accessibility is:

Accessibility is the practice of making your websites usable by as many people as possible according to MDN.

There is a ton of information about accessibility and I can make this article super super long, but I'm not going to do that to make a couple concepts more digestible.

Quick tips for your accessible website

Use semantic HTML

For example, let's say we need an element to open a modal, which one do you think is the most correct semantic element to use?

<a class="c-modal__open">Find out more</a>
<div class="c-modal__open">Find out more</div>
<button class="c-modal__open">Find out more</button>

The correct element would be a button, because of the following reasons:

1. A <button> tag is used to perform an action.
2. Buttons are keyboard accessible.

Why shouldn't you use an <a> tag or <div> tag

1. An <a> tag should be used for navigation.
2. A <div>tag is a generic container for flow content.

What if you need to navigate to another page, what would the correct element be?

You got it, an <a> tag because it should be used for navigation.

Keyboard Accessibility

People with motor function impairments use the keyboard (or other non-mouse features) to activate website functionality.

Let's go back to the modal example, I'm just going to mention one feature a modal should have:

• User should be able to close the modal through keyboard. Either be it by using the ESC button, tabbing through or clicking on a close button.

If a user only used a keyboard or device that mocks a keyboard, they will be unable to exit the modal if you only implement click events.

Also, here is an example of an accessible modal.

Text alternatives for non-text content

For example:

• Short equivalents for images, including icons, buttons, and graphics.
• Description of data represented on charts, diagrams, and illustrations.
• Brief descriptions of non-text content such as audio and video files.
• Labels for form controls, input, and other user interface components.

Font

• Size check more here
• Color contrast

Testing

How can you test if your website is accessible, there are many tools, but some I use are:

• Wave
• Axe
• Browser DevTools ( Chrome )
  • Right Click > Lighthouse > Generate Report
• Built in screen readers ( Mac Screen Reader )
• ChromeVox Screen Reader Extension
• Cross Browser testing, just to make sure same behavior is replicated everywhere
• Good old tabbing, enter, spacing and so on
• Color contrast checkers

Also, just a general tip, validate your markup and styles.

To validate HTML: https://validator.w3.org/
To validate CSS: http://jigsaw.w3.org/css-validator/

For code organization, make sure you lint your code by using a linter.

What is a linter? It is a static code analysis tool used to flag programming errors, bugs, stylistic errors and suspicious construct.

Popular linter: ESLINT.

Summary

• Use semantic HTML.
• Make sure your website is keyboard accessible.
• Add text alternatives.
• Question to ask: Is my font size readable for people with low vision or can this be adjusted?
• Test your website or other websites and check if it's accessible.
• Validate your HTML and CSS.
• Lint your code.
• There are so many resources (W3C, Google, MDN) and so on.