What is accessibility?

Accessibility is very often considered to be making software friendly for people with disabilities that heavily affects how they operate with a computer, like, for example, blind people. It’s true, but it’s not the whole truth. Accessibility is more about making software for everyone. Some people prefer using a keyboard over a mouse. Some, due to age, may have lower dexterity. Others may just have physical conditions that aren’t considered a disability but may make browsing some pages harder. Even using more straightforward language in texts can be considered an accessibility enhancement. That’s why you should always assume that accessibility is about everyone who uses the web. Everyone benefits from accessibility.

How people use your website

The first thing to consider when learning how to make your website accessible is to know which people are using your website, how they do so, and how they would like to. When thinking about accessibility connected to disabilities, you may want to take a look at how software and hardware help people use the computer. 

Some basics you should consider:

  • People with poor vision may zoom in on the page. But you should remember that not all visual impairments work like that. For example, people with tunnel vision prefer to zoom out due to the smaller field of view. Remember that people who can still see, even barely, always want to use their eyesight when it’s possible.
  • Blind people, or those with very bad vision, may use your website with screen readers or braille displays. However, remember that they’re not the only people who benefit from screen readers. Some with cognitive disabilities may also use them, even when they see just fine.  
  • If you have multimedia content, remember that not everyone can see or hear it. In those cases, people open subtitles and transcripts or listen to audio descriptions. Remember that it may have nothing to do with disabilities. Some may prefer subtitles because of being in a loud environment or not understanding the spoken language well.
  • Not everyone uses a mouse. It’s either due to preference (developers know perfectly well about this) or because of physical limitations. Instead of a mouse, people can use just a keyboard, voice recognition software, or hardware like switch controls. 

Remember HTML semantics

HTML provides very simple and easy to use tags that give a semantic value to a webpage. You just need to know about them and use them properly. Some general tips:

  • Don’t use <div> or <span> for everything. Use <p> for paragraphs, divide the page with <section> tags, and annotate the purpose of content with tags like <main> or <aside>.
  • Remember about header structure. <h1> should be first, and there should be only one. Under <h1> should be <h2>, under <h2> is <h3>, and so on. You should avoid skipping header levels. Also, never treat headers as a way to create bigger text.
  • Always provide alternative text that is short and descriptive for images. However, if the image is only for decorative purposes, leave the alternate text field empty, but still keep the alt attribute.
  • Creating a new paragraph with <p> is not semantically the same as adding a new line with <br>. The result may look the same visually, but it’s interpreted differently.
  • Use <ol> and <ul> tags for lists. Never do them manually.
  • When adding labels to inputs, remember about the for attribute to annotate which input it’s describing. Also, remember that placeholders aren’t meant to be used instead of labels.
  • Try to stick to conventional inputs for forms. While custom combo boxes or date pickers may look appealing , it doesn’t mean it’s easy to use them with accessibility tools. Default inputs are made with accessibility in mind.

However, sometimes we just want to do something from many <divs> and <spans> to make it look nice. If that’s the case, you can use one of the ARIA attributes to add semantic elements. For example, when your <div> is, in fact, a checkbox, you may wish to set role=”checkbox” along with aria-checked.

Accessibility tools don’t know CSS or JS

When creating a webpage with screen readers in mind, you need to remember that these tools don’t parse CSS styles and JavaScript scripts. That’s why, if you want to emphasize something despite adding nice styles, you should also remember to add an appropriate HTML tag for it. The same goes for scripts. If you have added an onClick event to some element, screen readers won’t recognize this until you annotate it with proper attributes as described earlier. Also, remember about the order of elements. If you’ve modified it in CSS, e.g., the order of elements in Flex, screen readers won’t recognize it.

Make links descriptive

Another problem that users of voice recognition may face is having poorly described links. Imagine you have no mouse, and you rely only on speaking to the computer. You want to enter a link, but each of them is called “click here” or “(link).” How would you click the one you want? In another scenario, every button is described with an icon. The screen reader doesn’t read what the icon means. Additionally, what would you call a link with a speech recognition tool? That’s why links should have more descriptive texts. If you want to use icons, you should add additional labels for screen readers. 

Make your page responsive

Remember what I wrote earlier about zooming in? It’s widespread. To be sure it works correctly, you need to make your web pages fully responsive. Yes, responsiveness is about more than making a page work on mobile. It’s also about resizing the window and zooming in. Even if you don’t target mobile, remember to keep some kind of responsive layout. One of the most important things is to not make users scroll horizontally to read the text. It’s very easy to lose the context of what you’re reading when you have to scroll to the right and then to the left while going to the next line. On the other hand, vertical scrolling isn’t a problem for anybody.

Test accessibility

Even if you’re not familiar with accessibility tools and you don’t have any knowledge about standards, you still can perform some automated tests. Here are some I can recommend for you:

  • In Firefox browsers and developer tools, you can find the “Accessibility” tab. There you will see the page structure as screen readers see it and also some basic errors and warnings.
  • If you don’t use Firefox or want a more user-friendly tool, I recommend Web Accessibility Evaluation Tool (WAVE). It’s a browser extension that works with Chrome and Firefox. It can display all errors exactly where they are on the page and summarize things you’ve done well! It also has a handy feature to turn off all CSS styles, and that allows you to see how your styles affect the readability of the page.
  • To check things in a different way, you should  download the Web Developer browser extension for Firefox, Chrome, and Opera. It allows you to do many modifications to how the browser renders the page. In terms of accessibility, I find it useful to hide all the images and show their alternate text instead. By doing this, you can see whether you still know what our content is about. It also offers many more useful features for web developers, so it’s worth checking out.
  • You may just want to run the screen reader and check your page with it. There are built-in apps for that in macOS, Windows, iOS, and Android. Don’t be afraid to try it. You’ll still see your screen, and it’s always possible to quickly turn it off.
  • Try to only use your page with a keyboard. Use “Tab” to go to the next input, link, or button and “Shift+Tab” to go to the previous one. You’ll use the “Enter” button instead of clicking with your mouse and arrows instead of the mouse wheel.
  • Zoom in, even to 500%!, zoom out, and resize the window. Generally, play around with the responsiveness.

Accessibility standards and further reading

What I’ve just shown you is just a tip of the iceberg. Accessibility is an extensive topic from many different perspectives. I’ve only scratched the surface from the developer’s perspective, but there is still a business perspective, content perspective, design perspective, and even legal perspective. If you want to get further into the topic, you should check out the Web Accessibility Initiative (WAI) website. There, you’ll find resources for developers, testers, designers, content writers, etc. I’d recommend that you first go through the Accessibility Fundamentals section. In that section you’ll learn about guidelines like WCAG for content, ATAG for authoring tools, and UAAG for user agents. You can also see how people with disabilities use the web and how accessibility helps older people.

One last thing. Remember, making the web accessible is beneficial for everyone.

Check out more interesting articles about technologies!