Accessibility for web

Accessibility for web

At icapps, everyone gets the chance to do research on topics that are innovative and relevant for our jobs as developers and designers. Think of topics like AR, chatbots and voice UI. The results of these investigations are presented to the other icapps colleagues during the Innovation Lunches, which are organized several times a year. A great way for our team to stay up to date on the latest tech developments and innovations!

For the previous Innovation Lunch, several of my colleagues and I researched accessibility, in four parallel tracks: accessibility for Android, iOS, web and design.

This blog gives a list of do’s and don’ts to improve accessibility on web. It primarily focuses on improvements for screen readers and keyboard navigation.

CSS Properties

First let us focus on the css properties. Most properties, such as color and font size, change your website visually and improve the readability for people with bad eyesight. These properties however are not going to be discussed here. Our designers usually take these into account in their designs. For blind people however, visual changes are not sufficient. They access websites and applications with a screen reader and usually navigate with a keyboard.

There is one property that is really important for them: the focus indicator.

You might be tempted to remove this outline because it’s not visually appealing but you should never remove the focus on an element. By removing it you are making the keyboard navigation very inaccessible since the user can no longer see which element is selected during navigation. There is no real reason to remove the outline other than esthetic reasons. But if you must remove it you should at the very least provide an alternative styling for the focus, such as changing the background or text color.

Semantics

The use of the proper semantics makes sure that the screen reader knows what the purpose of an element is. If properly used, the screen reader can tell the role, name, state and value of an element. For example, if you use an h1-tag for your primary heading, the screen reader will identify it as such.

It can also be beneficial to use HTML5 elements for the page-layout. They are used for landmark navigation, which identify frequently occurring sections that the screen reader can indicate out loud. For example, in the html code below the screen reader would say that your currently selected element is the header, the main-content or the footer.

Html tags and attributes

The first important property, that most people probably already know, is the alt property in image-tags. A screen reader uses this text to describe the image.

ARIA is a set of accessibility attributes that can be used to describe elements in more detail. ARIA stands for “Accessible Rich Internet Applications”. Here are a few examples:

  • aria-label can be used to give a description of the element. For example, this can be used to let a screen reader say “Close” instead of reading aloud “X”.
  • aria-required can be used to show the validation of a form (whether or not a certain input is required in the form or not)
  • role can be used to describe the role of an element or form. When making a form that is used for a search for example, you can give a role of “search”. This causes the screen reader to tell the user what this form is used for.
  • aria-hidden hides an element for a screen reader, which can be useful for irrelevant content. A good example of irrelevant content could be a visual element that is only there to emphasize the text beside it. Like a back icon before the word “back”.

It is important to note that, while you can use aria to give a description to an image, omitting the alt tag can cause validation warnings with html validators or eslint.

The last property that we are going to discuss is tabindex. With tabindex you can adjust the order in which a user can navigate through elements by using the tab-button. By default tabindex is topdown. While most of the time the default is fine, sometimes it can be necessary to change the tabindex because of css changes or a responsive screen that changes the order of your elements.

Accessibility in React Native

While there are some big differences between web and native, the biggest one being the loss of keyboard navigation on native, accessibility is still equally important.

React Native offers some properties to improve accessibility on native devices:

  • The first one is accessible. This property, which can be used on iOS and Android, indicates if an element is accessible and groups its children in a selectable element. All touchable elements are accessible by default. After making the element selectable all accessibility labels will be gathered.

  • The accesibilityLabel property gives a description of the element that the user has selected.

  • AccesibilityTraits is only available for iOS. It is an indicator for the type of element the user has selected.  Android has the accessibilityComponentType property, which is comparable to accesibilityTraits but more limited.

  • AccesibilityInfo is a method that can be used to check if there is an active screen reader. This could be useful to hide certain content.

Since React Native compiles to iOS and Android, you can use the same accessibility tools as you would for the native apps.

For iOS the accessibility inspector in the iOS simulator is a good pick. It allows you to inspect elements an to see what the screen reader would say.

For Android you have the Google Accessibility Scanner, which is device-only. The scanner works by taking a screenshot of your app and suggesting improvements.