Web Accessibility Basics for Web Developers

All of us are making websites and we all should know about web accessibility to make them accessible for anyone who wants to come and use them.

What is accessibility?

Web accessibility means making your websites or apps work for everybody on every device.

Important Note: Web accessibility is important to know for every web developer. Everyone at some point will have some sort of temporary disability and we don’t want to exclude those people from our web experiences.

It’s important to know that you don’t have to be an expert in accessibility to start using the basic principles in your work.

I’m absolutely sure there’s going to be experts who know every nitty-gritty detail about it. This doesn’t mean that you should stay back from it and let experts do their job. This is our responsibility as web developers, to make things that we build accessible for others.

Now you may think “Great, more work to do”, but it doesn’t take a lot of your time and It’s pretty easy to implement. You don’t have to make your website or app 100% accessible. It doesn’t need to be perfect before you push it live, just try to make it more accessible than yesterday.

A lot of these things you can add incrementally, it’s not hard, it just takes some of your time.

Types of disabilities

It’s pretty common to have that first impression that accessibility is generally just visual impairment, but it’s not. People may have some mobility challenges, they may be deaf or hard of hearing, they’re maybe people who have cognitive disabilities.

According to statistics, 1 in 7 people have some kind of disability. This really amounts to roughly 15% of the population and the more you age, the more prevalent it becomes. There are several types of disabilities:

• Permanent. People who suffered the loss of an upper limb or are blind
• Temporary. A person with an arm injury or a cataract
• Situational. A new parent or a distracted driver

Whether it’s permanent, temporary or situational disability, this is something that needs to be paid attention to.

What things you can do today to implement accessibility?

The best way is to write a simple good code and use semantic elements and clean HTML. We get super excited about new technologies and new ways to do things and there’s nothing wrong with that, but preferencing something just because it’s a new hotness is not the best way to deliver accessible web content.

Here are a few key pointers that could help you to implement web accessibility:

Images

Use <img> tag. When you’re creating a document for the web, it’s important that you use <img> tag for the actual images. A lot of people like to use background images instead. But they should be used for patterns, design, decoration, etc.

If you use the image as a background, you can’t give it alt tag, and the alt tag is how screen readers let users know what the image is, and whether or not they should care about the content. If you need to use an actual image on the page, you should use an <img> tag.

Alt text. An accessibility 101 for images is having an alt tag on them. If you have a picture of an owl, your alt tag doesn’t need to say “Picture of an owl” it just needs to say owl. The screen reader knows that it’s a picture, so it’s unnecessary to put that in there. Also, keep in mind that if you have a heading that says “Owl superhero” and then an image directly under that with the alt text “Owl superhero” you may be forcing a screen reader to read this text twice, which can be really annoying for people.

Clean semantic HTML

Whenever you put some HTML on the page, you need to think to yourself, what is the most semantic elements that I can use to represent this content. Not only it will make it more accessible, but it’s also really good for SEO and going to make your job of writing CSS and style your content much better as well.

We have more semantic elements like article, section, header, footer, aside. They don’t do anything special for your HTML but they’re much more descriptive as to what the content is inside of them.

You should use the right elements at the right places. If all your buttons are buttons, and all your headings are headings, this will ensure that users can navigate your website.

Also, aim to respect the hierarchy of headings, because that hierarchy is directly translated via screen readers.

Inputs

Make sure that you’re using your HTML5 inputs, don’t just use a <div> on absolutely everything. We are now have a lot of different input types like email, password, phone and others.

Inputs are going to give more natural visual experience to people who aren’t disabled, but it’s also going to give a better experiences to anyone with disabilities because your operating system knows how to handle those inputs.

Order in CSS

Flexbox and CSS Grid allow you to rearrange elements on the page. Unfortunately, there is a problem with that. If you were to try selecting the text with your cursor, or to use a screen reader, the order may not be respected.

Only use Flexbox and CSS Grid order property when you want to visually change something and it doesn’t actually affect the actual source order of the content.

ARIA roles

The biggest problems begin when people try to create custom elements. Quite often they forget to make them accessible, which certainly can be done, but it’ll require some extra work.

The web community came up with the spec called ARIA, which stands for Accessible Rich Internet Applications to increase accessibility of the web applications. There’s aria states, aria roles, ARIA properties that can be used to tell the browser certain things about the web page.

Use ARIA roles to define elements when semantic HTML is not working. For example, if you’re building a navigation, and you want to show that this navigation is currently open, use the role aria-expanded.

By default the screen reader is just going to read the text inside the element, but sometimes you need to give a user more context of what’s actually going on. For that you can use aria attribute aria-label.

Another really common example would be a hamburger menu and it’s typically a button with the icon on it. Obviously having a label of menu on the hamburger is going to let the user know that it’s a menu button.

Here are some examples of other aria attributes:

• aria-label: What is this element?
• aria-expanded: Is this element open or closed?
• aria-describedby: What element describes this element?
• aria-live: Will this element be updated later?

Focus ring

The next one is the focus ring. It is an outline that appears on an item when it’s selected. If you open the page and press TAB several times, the good website is going to have that focus ring that’s going to take you place by place and show you what it’s selecting.

It works because of something called the TAB index, which allows you to specify the index of what is selected whenever you hit the TAB key and this is going to make your website usable for people who can’t use the mouse. Being able to TAB through the site is a great way of navigation even if you don’t have any disabilities.

By default all your links, buttons, inputs will automatically be tabbed to the order that they show up in the document. You can give something a TAB index so that you can order it yourself. Having those abilities to customize the TAB index is a big deal.

Skip to content

Next up is the “Skip to content” button. It’s just an anchor link at the very top of your website that links to an ID where the content lives. If you have a lot of items in your menu, you’ll be able to just skip past the menu. By default they’re invisible, you hide them with CSS unless they have a focus.

Color contrast

Aim for the contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. This will help people to read your content.

Valid HTML code

Valid code may sound old fashioned, but it’s true. When yo have a valid code if you can solve things with simple HTML, don’t reach for things that are fancy like JavaScript or ARIA because those things are meant to solve the specific problems whereas HTML works all the time.

Tools

There’s a whole bunch of tools that you can use for accessibility testing.

• ESLint rules. Super great thing is to use ESLint rules for accessibility if you’re using React or whatever. It just lets you know of any potential issues. It’s an easy win to turn those things on. It really makes it a lot easier if you have those ESLint rules.
• Lighthouse. You can run an audit on your website with this tool. An interesting thing about it that even if you get a score of a 100, it’ll still have some additional things for you to manually check. So, if you’re the person only beginning to dabble into accessibility, using a tool like Lighthouse is totally invaluable. Lighthouse is available in your DevTools already without you having to do anything.
• Axe chrome extension. This extension gives you syntax highlighting of where the problem is and also will tell you how to solve it.
• Screen readers. A large portion of people that have some kind of disability going to be using screen readers. If someone is blind, or they have a low vision or they’re in any kind of situation where they can’t read the text, they’re obviously using a screen reader. There’s a whole bunch of screen readers out there. iPhone and macOS have a really good one built in. There are some free ones available for Windows as well. NVAccess – open source screen reader from Australia. Android has Android Accessibility Suite. Chrome has it’s own called Chrome Vox.
• Color Contrast Checker You can use a tool to check color contrast by putting in a foreground and background colour.
• Color Palette Combination Contrast Tester This tool allows you to add your site’s color palette, compare it and show you accessible combinations.
• Who Can Use Shows how color contrast affects people with different visual impairments.
• Accessibility Insights You can discover a lot of accessibility issues with this extension from Microsoft. It’s available for Windows, Android, Web and can perform automated tests.

Resources

• a11y project This website contains just endless amount of resources and it’s a community effort to make web accessibility easier.
• Articles on a list apart Awesome compilation of articles on accessibility with web standards and best practices.
• Pa11y A great collection of open source tools to help web developers and designers fix accessibility issues on websites. Some of these tools have a command-line interface, which allows you to put it as a part of your continuous integration pipeline so it could fail the build if something isn’t accessible.
• Adobe accessibility page A collection of resources on accessibility from Adobe. Clean overview of the most important things that you need to know.
• The Bulb inclusive design audit report Great example of the accessibility audit performed on the website. It illustrates some of the common problems that developers need to keep in mind when building the interfaces.
• Deque YouTube channel Great YouTube channel with a whole bunch of things like talks from conferences, accessibility videos, interviews, presentations.
• web-a11y Slack If you have a quick question and don’t know where to ask, it’s a great place to go. This is a great community of designers and developers that are who are passionate about making the web inclusive and accessible for everyone.
• #a11y hashtag on Twitter Another great place to stay up to date on accessibility news.
• WebAIM community that helps people to make their web content accessible to people with disabilities.

A lot of these tools are free. Go install a screen reader and try to actually use your application yourself. You’re going to have a real feedback of whether or not these things feel ok.

What happens if my website is not accessible?

If you’re not focused on accessibility, people with disabilities are mainly going to be the people having trouble using your website. But you really don’t want to exclude anyone from your audience. You want everyone who wants to view your content to be able to view it and that is what important.

I’ve heard that in some countries you can get sued for not having well tested application or an accessible website, so it’s kind of a big deal.

In conclusion

I hope this article helps to draw attention to the main accessibility issues people often forget.

Accessibility is not like a huge thing that you need to undertake and spend weeks and sprints on. All of this stuff is free, takes minutes to implement, especially if you think about it beforehand. It should be extra couple of minutes here and there just to make sure that everything works.

You don’t have to be an expert. You already have 70% of the skills you need for accessibility, generally speaking. You already can do things in a more accessible way.

If you build things according to standards, more than likely they will be accessible. Doing things this way will make sure that your website or app is really accessible for everyone.

I hope you enjoyed this post.

Stay tuned for more!

I’ll go grab some coffee.