How we improved web accessibility in a carbon offset application

A solution for carbon offsetting

Chooose is an Oslo-based tech company that was wanting to build a software application that would enable businesses and individual users to increase their carbon footprint awareness as well provide a simple means of mitigating this footprint. Since then, and in cooperation with Startup House, they’ve managed to develop a complex and quite brilliant platform that connects users with carbon offsetting projects. 

Part of this solution was the development of a carbon emissions calculator. Its key feature now is a function that evaluates flights-per-passenger or cargo-volume carbon footprints based on certain factors affecting fuel consumption for a specific flight. The calculator may also apply to hotel-stay footprints, as well as to those of transport fuel consumption on the ground.

Given Chooose’s ongoing commitment to providing the best-possible user experience, along with their awareness of the importance in supporting the broadest spectrum of users, they implemented here strict web accessibility standards in their applications. In the development process therefore, this meant facilitating web accessibility based on the WCAG 2.1 standard. 

Web accessibility: essential for some, beneficial to all

Web accessibility is an inclusive practice for designing websites or web applications that integrate assistive technologies so that those applications may be used by people with disabilities. These users may be individuals with impaired vision and/or hearing, or other physical/cognitive deficiencies that make web use difficult. 

But web accessibility is also beneficial to the elderly, as well as to those using mobile devices, smart watches, smart TVs, outdated devices and/or browsers. It’s also handy when engaging a website in unfavourable conditions, be they overly quiet or noisy, or when extreme daylight makes content reading particularly tedious. 

Through its commitment to social inclusivity, web accessibility ultimately strives to provide equal access of information and services to all users, regardless of their abilities or disabilities.

It’s worth mentioning that supporting web accessibility is important in terms of legal compliance.

The international technical standard that sets principles and guidelines on how to make web content fully accessible is the Web Content Accessibility Guidelines (WCAG), which is developed by the World Wide Web Consortium (W3C). 

Web accessibility benefits

The benefits full website accessibility provides are numerous: 

Improved ease of access to information & services for the disabled increases the potential of a website to expand its user base and broaden that base's profile.

Enhanced user satisfaction - implementing web accessibility improves overall UX (user experience) by making application use easier across various devices and in varying contexts. This encourages ongoing, continuous use of the application by a broadened range of customers. 

Better indexing by search engines -  making an application more accessible can help to improve its ranking in search engine results, thus increasing user traffic.

Positive brand impact - implementing web accessibility demonstrates an organisation's commitment to inclusivity and accessibility, which in turn can extend market reach and enhance overall brand values.

Start with semantic HTML

When considering web accessibility, the most important factor in any application’s front-end development is the creation of a layout based on semantic HTML elements, and ones that are properly applied in terms of the function and purpose of their content. 

Semantic HTML tags clearly and accurately describe the meaning and purpose of the content they enclose. This makes it easier for assistive technologies such as screen readers to understand and interpret the content of a page. As a result, using semantic HTML improves the accessibility of a website for users with disabilities.

There are many HTML elements which in theory seem identical, but in fact are intended for different types of content. For example, a button in the application can be marked using a button or a div or any other tag. However, a button tag ensures that the user-agent recognizes this element as an interactive part of the UI, and one that is activated by mouse, keyboard, touch, or voice command to prompt some kind of action. Although a div may be applied as an alternative, this would not be without a considerable amount of custom code behind it. 

The same applies to other elements like paragraph, table, link, quote, audio, video, time, address, etc. – and many more. So, it’s important to remember that when creating React components, we should always rely on semantic HTML elements underneath.

Theme contrasting

According to another WCAG 2.1 criterion, providing enough contrast between text and background is crucial for optimal visibility and thus legibility. Naturally, this is particularly important for the visually impaired who may have difficulty reading text that is without sufficient contrast or perhaps do not use contrast-enhancing assistive technology.

Ensuring the correct contrast between text and background is beneficial to all users in various situations. For example, when using web applications in unfavourable light conditions where direct sunlight renders screen reading difficult, or when screen settings are put on darker themes.

WCAG 2.1 recommends the minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text (24 points or larger, or 19 points or larger if bold). This means that the difference in luminance between the text and the background should be at least 4.5 times greater for normal text, and 3 times greater for large text.

This criterion is often overlooked because it requires verifying the design of the entire app and/or  changing individual colours – often a bone of contention between developers and designers. What's more, one must also consider situations where element colours in the app may be fully customized by the user. For example, when for the sake of maintaining company brand consistency, a user will match the appearance of an app to those of a of a company’s branding using certain color combinations.  Here, it may happen that these colors do not meet the accessibility requirements in terms of contrast values. In such situations, the following design tips will be useful.

One solution is to create a separate, alternative theme for the application, where colours meet the contrast requirements, and the theme is easily applied, e.g. by using a switch in the application settings. This way, we can provide users with an alternative theme and the appropriate colour contrast, yet without interfering with the default personalised application theme.

Keyboard navigation

One of the WCAG success criteria is to ensure that all functionalities of the application are operable and available through a keyboard interface without the need to use a mouse. This allows the blind, those with impaired vision or problems with  hand-eye coordination to use application features and reach all content.

It’s crucial to ensure that the order for advancing focus is defined correctly. This must  follow the order that maintains logical meaning and operability when the user navigates the application using the TAB or arrow keys. The main method of ensuring that sequence is by properly ordering  HTML elements and by the use of semantic elements that can receive focus whilst being operable with a keyboard.

Perceivable inputs

There are several ways to make an HTML input accessible in accordance with WCAG 2.1. Here are the ones we used when developing the Chooose application, and our approach was as follows:

First, we provided a descriptive and informative label for the input. This was done using the ‘<label>’ element, which could be associated with the input using a ‘for’ attribute. The label had to use clear and simple language, and accurately describe the purpose of the input. The same would apply to the placeholder which provides clear instructions for completing the input correctly.

The next step was to ensure that the input could be operated with a keyboard, and that the method of its operation met the keyboard navigation criteria mentioned earlier. We did this by taking care that the input had a logical tab order, and that users could interact with it using the keyboard only. For example, we ensured users could use the Tab key to move between inputs, use arrows for selecting options on select elements, and press the Enter key to submit the form.

The next step was to provide  feedback when the input was invalid. We did this by using the ‘:invalid’ pseudo-class in CSS, which allows you to style the input when its value is incorrect. 

For example, you could use this pseudo-class to display an error message next to the input or to highlight the input in a different colour. We also included error messages using the toast component from Chakra UI to give feedback to users after an action had taken place.

Next was implementing an autofill feature on text inputs in HTML. We found this useful for several reasons. One of which was that it saves time and effort for users needing to enter the same information repeatedly, such as name, address, email address etc. By making the completion of a website form easier, user experience is thus enhanced.  

Focus trap

Using only a keyboard is a bit tricky when it comes to handling modal dialog elements.

In our case, there was additional content and information which we placed inside dialog boxes in the application so it could be reached while not taking up extra space in the main container view. 

To ensure the content placed in the modal was accessible by keyboard, we had to solve the following problems:

Opening and closing the modal window using the keyboard, where in addition to the dedicated button, the modal can be closed using the ‘ESC’ key. This solution was handy since it let the user to close the modal window without using the mouse, which meets the WCAG requirement citing that all functionalities of the content must be operable through a keyboard interface.

Moving the focus to, then retaining it inside the modal element upon opening so that the user cannot ‘go outside’ and reach elements that shouldn’t be accessible without reclosing it.

When a user navigates through a modal window using the ‘Tab’ or ‘Shift+Tab’ keys, there is a risk of losing focus on the modal's elements if the user navigates to the last or first element inside the modal. This can happen because the next element to receive focus is outside the modal window. To prevent this, we used the 'focus trap' technique, which ensures that focus remains within the modal window until the user closes it.

We then implemented a solution so that when a user presses the tab key on the last item in the modal, it moves the focus to the first focusable item in the modal and not to the next item outside it. Similarly for the shift+tab combination, the focus from the first element moves to the last element.

Now, there’s an accessible dialogue window that stores the application settings, which you can see below. There are also a couple of different interactive elements like switches, dropdowns, and a ‘save’ button, among which the user can move focus without risk of focusing on any element outside the settings modal.

No ARIA is better than bad ARIA

Using the ARIA (Accessible Rich Internet Applications) attributes in HTML can make your web content and applications more accessible. These attributes provide additional information about the meaning and purpose of elements on the page, which can be interpreted by assistive technologies such as screen readers.

In other words, ARIA supplements HTML elements with extra attributes so that the user receives more specific information about the role, purpose, and meaning of a given element. However, it is important to use ARIA attributes correctly in order to ensure that your content is truly accessible. 

Using ARIA attributes improperly, or using them to compensate for a poorly designed user interface can in fact make your content less accessible and therefore harder to use for those with disabilities. It’s said that developers should always rely on using native HTML semantic elements and use ARIA only when appropriate.

Overall, it is important to employ ARIA attributes wisely and to avoid using them as a substitute for good design and accessibility practices.  

Content relationship

In terms of WCAG 2.1 requirements, content relationship refers to the way that different pieces of content on a web page are related to one another. This includes both the structural relationship between different elements on the page (e.g. headings and subheadings), and the relationship between the actions triggered by interactive elements and the content that depends on them.

Users without visual impairments understand the structure of content through visual cues, where headings and subheadings are differentiated by means of font sizes, font weight, whitespace, horizontal lines, and so on. However, all users should be able to perceive these differences. 

The visually-impaired can only rely on the headings relationship that is encoded in HTML heading tags and their order. Using proper heading levels allows screen readers and other assistive technologies to properly interpret the structure of your content and present it to users in a way that is easy for them to understand and navigate.

In the case of Chooose, the another way we provided content relationships in our carbon application is by using the ARIA live regions. The ARIA-live attribute is used to indicate that an element's content should be announced to users who are using assistive technologies. This can be useful for people using such technologies because it allows them to be notified when the content of an element has been updated.

To achieve this, we added the ARIA-live attribute to the elements whose content changes on interaction. Thus enhanced, the application now notifies assistive technology users that there have been content updates they should be aware of.

Here comes Chakra UI

Chakra UI is our React component library of choice for most development projects at Startup House. One of the main reasons for this is the prominent advantage Chakra UI enjoys over other libraries: accessibility support. 

Out-of-the-box components provided by Chakra UI support accessibility requirements in terms of proper keyboard navigation, focus management, and ARIA implementation. There are a lot of custom hooks that export logic for use in creating tailor-made components so that we can handle web accessibility even in complicated custom components.

Legal compliance 

In many countries, there are laws and regulations that require websites and web applications to be accessible, e.g. the ADA Regulations in the US or The Web Accessibility Directive applicable in the EU. 

Summary

Given the multiple benefits it provides all users, web accessibility is an aspect of application design which developers and stakeholders must never overlook. Moreover, ensuring this equal web services-and-content access to those with diverse abilities demonstrates a company’s social commitment and thus does much to enhance that company’s public image. 

These days, web accessibility is an indispensable part of modern application design. So, if you’d like to find out how we can help you build an accessible web application and learn of the many benefits it will provide, don’t hesitate to contact us.

Finally, if you’d also like to find out more about our partnership with Chooose, check out our case study on how we developed their carbon footprint-tracking dashboard.