Money Forward Developers Blog

3 Mindsets for Improving Accessibility

Hi, I’m @taigakiyokawa from Frontend Forward Group. I’m working on making Accessibility Guidelines and developing common UI libraries as a frontend engineer.

Today, I will introduce as an article what I spoke at the internal presentation for all engineers to raise awareness of accessibility.

同じ記事の日本語版はこちら

3 Mindsets for Improving Accessibility

First of all, here are today’s key points.

  1. Low Accessibility is a “System Failure.”
  2. Start Steadily Where We Can.
  3. “Improve” Accessibility, NOT “Deal with.”

I will explain what these mindsets mean.

What is Accessibility?

Accessibility is the range of situations in which a service can be used.1

“High accessibility” means that a service or information can be used regardless of the situation or disability.

In contrast, “low accessibility” means that a service can be used only under/by particular situations or people.

Therefore, “improving accessibility” means expanding the range of situations where a service can be used.

Who is Accessibility for?

Accessibility is for everyone, not only people with disabilities or elders.

We often see misconceptions such as “accessibility is for people with disabilities or elders,” but accessibility benefits not only particular people. It benefits everyone.

However, it’s still important to know what types of disabilities exist when we imagine the use cases. Therefore, I will introduce the main types of disability when using a Web service.

Main Types of Disability

  • Upper limb disability: difficult to use mouse or keyboard
  • Low vision: need to use a screen with extreme magnification
  • Color vision deficiency, limited color vision: difficult to distinguish some colors or cannot identify some colors
  • Blindness: need to use a screen reader with keyboard-only and/or use a braille display
  • Hearing impairment, deaf: need captions or sign language or need to use speech-to-text tools
  • Cognitive/Learning disability, dyslexia: have difficulty in short-term memory or difficult to read and/or write text
  • Temporary disability (examples):
    • difficult to use a mouse because of an arm is broken
    • cannot hear the conversation during meetings because the headphones are forgotten at home
    • being out, cannot use a PC, but need to submit a workflow now
  • etc.

Who Should Work on Accessibility?

Everyone should improve accessibility, not only designers or engineers in specific fields. We should keep accessibility in mind in our daily work, not only during product updates:

  • Share document in both English and Japanese.
  • Document what was said.
  • Describe the linked content clearly in the text for a link (not “click here”).
  • Do not make text in sales documents too small.
  • etc.

Also in social media, etc., we should always be aware of whether everyone can access the information we share.

Why Does Accessibility Matter?

I introduce the Mindset #1: Low Accessibility is a “System Failure” in this section.

Let’s think about “disability” before going into the mindset. There are two models of disability.

Medical Model

In Medical Model, disability is in human body and mind.

This model focuses on removing disability through treatment, counseling, rehabilitation, etc., from people who “have disability” so that they become “normal.”

A person in a wheelchair faces the steps. If they become capable of walking, they could go up the steps on their feet.

Social Model

In Social Model, disability is caused by an interaction between the society and an individual.

This model focuses on removing the notion that “disability has been occurring” by adapting social environment to diverse situations.

A person in a wheelchair faces the steps. If the steps are changed to a ramp, they could go up the ramp in the wheelchair.

We improve accessibility based on Social Model of Disability.

Therefore, disability is not in the users. It exists in between the users and the services.

Low Accessibility = System Failure

Low accessibility does not only mean a service is difficult to use. It causes situations where some users cannot use a service.

What do we call the cause of a situation where some users cannot use a service?

It’s generally just called a bug or an error, but it’s a “System Failure” from the viewpoint of this section.

Therefore, low accessibility and system failure are the same in the sense that they cause situations where some users cannot use a service.

Many Other Reasons Why Accessibility Matters

There are many reasons why accessibility matters. They are:

However, I think the most important reason is “because low accessibility causes situations where some users cannot use a service.”

Mindset #1: Low Accessibility is a “System Failure”

  • Disability exists in between users and services, not in users.
  • Low accessibility prevents some users from using a service, not just being difficult to use.
  • Low accessibility and system failure are the same in that they cause situations where some users cannot use a service.

It may sound exaggerated, but we should work on accessibility with this mindset.

How Do We Improve Accessibility?

Mindset #2: Start Steadily Where We Can is important in this section.

Find the Problems First

Let’s check the accessibility by using a product together.

In checking, some accessibility guidelines and checklists will be helpful.

Web Accessibility Guidelines & Checklists

There are some guidelines and checklists for Web accessibility. WCAG is the international standard that has been published by W3C and the Japanese version has been published by WAIC. Also, some Japanese companies have published their own guidelines:

Regarding our company, Money Forward Cloud Accessibility Guidelines have been internally published in English. The guidelines consist of Design, Implementation, and QA for each Success Criteria of WCAG 2.2.

Aim To Be “Perceivable” First

However, it’s difficult to know where to start looking at within many guidelines. I recommend to aim to be “Perceivable” first. It comes from “4 Principles of Accessibility” presented by WCAG. The content should be perceivable before it can be operated or understandable.

I will introduce these principles.

4 Principles of Accessibility

WCAG defines the followings “4 Principles of Accessibility”:

  1. Perceivable
  2. Operable
  3. Understandable
  4. Robust

(Source: Introduction to Understanding WCAG | WAI | W3C)

1. Perceivable

Perceivable means to present content and information in ways users can perceive.

  • Add text alternative
  • Indicate relationship
  • Not rely on single sense (vision, color vision, hearing)
  • etc.

2. Operable

Operable means that interactions and navigation must be operable.

  • Keyboard operable
  • Timing adjustable
  • Navigable by assistive technologies
  • etc.

3. Understandable

Understandable means that information and operation must be understandable.

  • Proper language settings
  • No unexpected behavior
  • Errors can be identified
  • Input has labels or instructions
  • etc.

4. Robust

Robust means that content can be interpreted by variety ways including assistive technologies.

  • UI roles, names, and states are properly configured
  • etc.

Accessibility is Rarely Solved Automatically

We should keep in mind that there is almost no automatic solution for improving accessibility.

There are many automatic check tools and static analysis tools (linters) for checking accessibility issues. Installing them is very welcome.

However, accessibility check needs basically to be done manually. For example, to check whether an image has text alternative, automatic tools can detect whether the image has a text alternative, but only human can check whether its text is as intended. (It may be checked by AI in the future, but now it’s too difficult to mechanically determine whether the description is set as intended within the context with other content)

In addition, beware of services called “accessibility overlays,” which claim to be “WCAG compliant” if you install them. As Overlay Fact Sheet mentions their effectiveness and problems, it’s difficult to regard these services as fundamental solutions for accessibility problems.

Let’s just improve steadily from where we can.

Case Studies

In this section, I will introduce some common problems and solutions of our products. (In the internal presentation, I performed a demonstration with Money Forward Cloud Attendance using a Screen Reader.)

  1. Cannot read icon buttons
  2. Cannot understand dropdown menus’ behavior
  3. Difficult to find the purpose section
  4. Cannot understand the result by pressing a button

1. Cannot read icon buttons

Icon buttons without labels must have text alternatives. Also, use <button> element for them to be focusable if the buttons are made with <div> or <span> elements.

<button type="button">
  <svg role="img" aria-label="Notification">...</svg>
</button>

You can add aria-label to the <button> element, but it’s better to add a text alternative to the <svg> element because the icon is a meaningful image. For details of the reason, please check (ja) アイコンボタンのアクセシブルな名前はボタンが持つべきかアイコンが持つべきか.

2. Cannot understand dropdown menus’ behavior

It’s too difficult to make dropdown menus accessible. I recommend using libraries that guarantee accessibility at the component level.

  • Use <button> element to make it focusable.
  • Use aria-expanded, aria-controls, aria-haspopup attributes to inform status changes of the dropdown to assistive technologies.
  • Related guideline:

3. Difficult to find the purpose section

Some users have difficulty finding the purpose section of a page if the section has no heading or wrong heading level. Use proper heading levels and landmark roles to make the section easy to find. Alternatively, it may be better to re-consider the structure with designers.

<section id="workflow-list">
  <h2>Workflow List</h2>
  <div>...</div>
</section>

4. Cannot understand the result by pressing a button

Some users cannot understand the message that was displayed on the screen after pressing a button. The screen changes must be announced to assistive technologies.

<div role="status">User profile has been updated</div>

Mindset #2: Start Steadily Where We Can

  • Let’s use the product and find its problems together.
  • Aim to be “Perceivable” by referring to guidelines.
  • Accessibility almost cannot be solved automatically.

I think you will become interested in thinking about accessibility if you can understand some problems and their solutions, so let’s improve steadily first.

When Do We Work on Accessibility?

Mindset #3: “Improve” Accessibility, NOT “Deal with.”

(By the way, this word comes from (ja) アクセシビリティ基本研修 by SmartHR）

Misunderstanding of “Deal with Accessibility”

Have you ever heard or seen the phrase “deal with accessibility” before?

The phrase is often used with the intention of working to improve accessibility.

I’ve used the phrase before.

However, the phrase “Deal with” misleads us into believing that improving accessibility is something that should be done optionally. “Deal with” is for compliant guidelines, not for accessibility itself.

Therefore, “Deal with” implies that improving accessibility is a step to check, find problems, and improve services or features with extra costs after they have been released.

Indeed, that’s the only way to improve accessibility for a service that has already been released, as I explained in the previous section.

However, such an operation will always be treated as a work that costs extra money and would have low priority.

Improve Accessibility in All Development Processes

When can we improve accessibility?

We should improve accessibility in all development processes. The processes can be divided into three: “design”, “implementation”, and “QA”. There is room to improve accessibility in each process.

Design: Improving Accessibility

In the design process, we should discuss precisely about the UI specs of accessibility with the designers, and then decide on them.

  • What should the text alternative be for this image?
  • How should this UI be operated by keyboard?
  • What HTML element is assumed with this UI?
  • etc.

Implementation: Improving Accessibility

In the implementation process, we should create the UI following the Web standards, and execute tests for interactions and keyboard operations at the component-level.

  • Use proper HTML elements and attribute values.
  • Run static analysis (such as eslint-plugin-jsx-a11y).
  • Execute tests for emulating keyboard operations.
  • Perform simple manual checks on each Pull Request.
  • etc.

QA: Improving Accessibility

In the QA process, we should always check accessibility at the product level before the feature is released.

  • Check that the UI can be operated only with a keyboard.
  • Check that the role, name, and state of the UI can be recognized by screen readers.
  • Check with automatic tools (such as axe DevTools).
  • etc.

Mindset #3: “Improve” Accessibility, NOT “Deal with”

  • “Deal with accessibility” misleads us into believing that improving accessibility is something that should be done optionally.
  • Improve accessibility in every single process: design, implementation, and QA.
  • Decide on the UI specs of accessibility at the design, and always check them before release.

Let’s incorporate accessibility from the beginning. Recall it especially when developing new features.

3 Mindsets for Improving Accessibility (Once Again)

  1. Low Accessibility is a “System Failure.”
  2. Start Steadily Where We Can.
  3. “Improve” Accessibility, NOT “Deal with.”

Last Words

Lastly, let me quote some words of Tim Berners-Lee, the inventor of the World Wide Web.

“The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.”

Tim Berners-Lee W3C Founding Director and inventor of the World Wide Web

(Source: Accessibility | Our mission | W3C)

From the beginning, the Web was designed so that its content will be accessible.

Let’s create services that maximally utilize the power of the Web!

Let’s improve accessibility together!

References

Published-date