This is a translation from the original post: https://techblog.woowahan.com/15541/

Introduction

Do you all follow the web accessibility rules?
Don't you feel like you have to stick to them, but you postpone due to other tasks?

During restructuring of Baemin Pay's management page it was not easy to modify the already shipped site to suit accessibility. It took a long time to modify, and there were major revisions that even overturned libraries or structures rather than partial revisions.

However, if you pay a little more attention during the development stage, you can prevent this mishap.

What's web accessibility?

Accessibility means designing products, devices, services, and environments that are easily accessible to everyone.

The word "everyone" here includes men and women of all ages, from people with low to high digital literacy, and from people without disabilities to people with temporary or permanent disabilities.

"Design for Everyone"

According to the WHO, more than 15% of the world's population are disabled. In other words, at least 1 billion users need accessibility-related responses.

Accessibility does not only apply to people with disabilities. Accessibility is an area where services are made easier for elderly people or those who are unfamiliar with digital devices. We need to make our services accessible to all ages, people of low and high digital literacy, the disabled and the non-disabled "everyone."

In Korea, Under the Act on the Prohibition of Discrimination against Persons with Disabilities, the Act on the Prohibition of Discrimination against Persons with Disabilities and the Subject of Rights states that applying standards that do not take disability into account without justifiable reasons should not result in adverse consequences or refuse to provide legitimate convenience to persons with disabilities. Accordingly, if there is a demand for improved accessibility to the service, the act of not improving accessibility can be judged as a violation of the Act on the Prohibition of Discrimination against Persons with Disabilities and may have legal responsibility.

In summary, accessibility should be considered when providing services, and overall improved experiences should be provided for all users. In the modern digital society, various services and technologies are developing day by day, and web technology is also developing. Web accessibility is also an item included in accessibility, and services using web technology should be delicately created so that anyone can easily access the service.

Web Accessibility and Web Standards

"Good compliance with web standards !== Guaranteed web accessibility."

Is the previous statement true?
Good compliance with web standards does not guarantee complete web accessibility.

However, just using the appropriate HTML elements for the right purpose guarantees much of the usability and accessibility.

Let's say we have a pair of code:

<div>home</div>

<button>home</button>

They will render apparently the same home. However, the screen reader will read them as follows

<div>home</div> -> home

<button>home</button> -> home button

It has the same style, so they look like the same button, but the screen reader doesn't tell that the div tag is a clickable element because we can't tell that it's a button.

This makes it impossible for visually impaired users to go to the home screen because they cannot tell if it is a button to go home.

Also, the button tag has built-in keyboard accessibility to move to and click on a button via tap or swipe on PC and mobile, but the feature is also not available if we use the div tag.

Of course, I don't think most of us would write the button as a div tag as in the example.
But we do make mistakes in more areas than we think, and we provide an HTML element that is not fit for purpose, causing someone to experience terrible usability.

Alternative text for image (alt)

You all know that images should provide appropriate alternative text. However, not all images need to be provided with an alternative text. For simple decorative elements, no alternative text should be provided. This is because it interferes with the delivery of information by providing unnecessary explanations.

Now, another question may rise.

Can I omit the alt attribute for the simple decorative element img?

No. Decorating elements that do not affect information delivery must be provided with an empty alt=" value.

The reason why you need to put an empty value instead of removing it is because the screen reader reads the image name if there is no alt attribute in the image.

If it is provided as an empty value, it will be judged as a decorative element and will not be read, so don't forget to put it in.

WAI-ARIA

(stands for Web Accessibility Initiative – Accessible Rich Internet Application)

WAI-ARIA is a technical specification released by W3C and was created for the purpose of improving accessibility and interoperability.

It provides with the role, property, and state information to help improve accessibility.

• Role defines the roles of certain components in the UI
• Property defines the characteristics or situation of a component and uses the prefix 'aria-*'
• State defines the component's state information

Role

The HTML elements have roles they implicitly have.

<button role="button">button</button> -> X

For example, the <button>button</button> contains role="button". Therefore, you don't have to define roles like "button role="button".

<button role="presentation">button</button> -> X

Also, role="presentation" should not be given when the role of an element should be told, such as a button tag.
This is because auxiliary devices such as screen readers ignore the original role of the element designated as role="presentation" and simply recognize it as an element for conveying information.

<h1 role=”button”>home</h1> -> X

Changing the native meaning of elements using the Role attribute should also be avoided, but if you assign the button role to the h1 tag as in the example code, you will not be provided with the aforementioned keyboard accessibility.

The roles that can be applied to each element are set, so it would be helpful to check the document before working on it.
(https://www.w3.org/TR/html-aria/#docconformance)

<div role=”main”></div> -> O
<div role=”MAIN”></div> -> X
<div role=”Main”></div> -> X

Modern browsers treat the attribute values in aria-* as case-insensitive, but not all browser versions and ancillary techniques do parsing correctly.
Therefore, it is recommended to use lowercase letters when defining attribute values for role or aria-*.

Landmark
You can use the ARIA Landmark Role to make it easier for screen reader users to navigate the website.
Landmarks are signage features that help identify the layout and role of the content area provided on the screen, which is an advanced type of skip links required by web accessibility guidelines and can be distinguished from areas that are clearer than the title provision of content blocks.
Screen reader users can freely navigate the main areas of the document using the hot keys that navigate landmarks.

Landmarks are defined in eight roles: banner, navigation, search, main, region, complementary, form, and contentinfo.

• Banner: It acts similar to the header element. It is generally offered in the same form throughout the site, but I initially misunderstood it as an advertising banner area because of the name. It mainly refers to information that can contain the site's logo or title or that can represent the site's identity.
• navigation: The roles should not be duplicated, as described earlier, because they serve the same role as the nav element. It should not be used more than two or three times, and if multiple navigation are used, the aria-label properties should be used together to provide a sense of which navigation area is.
• search: You can use it in the input form area for search. You can take the restaurant search area as an example.
• Main: You shouldn't use the same role as the main element, so you shouldn't have to repeat the role. Be careful because you can only declare a main role once within a webpage.
• region: similar to section
• complementary: similar to aside. It is an additional area that can supplement the main content, and it is a content area that maintains meaning even when separated from the basic content.
• form: It plays the same role as the form element and tells you that it is an inputable area.
• contentinfo: It plays a similar role to footer, and is mainly used to identify personal information policies, copyright information.

Doesn't it remind you of the markup language?

As we explained earlier, just using the appropriate tag can provide enough information about the area.

The properties and state of ARIA

We have to assign ARIA roles, states, and attributes to the elements unless they already have proper roles and meaning.

If you apply ARIA, it only exposes additional information to the browser's accessibility API and it doesn't affect the DOM.

The state and properties can be categorized into widget, live region, drag and drop, and relocationship.
Among them, we would like to explain the modal in widget and the live attribute in live region with examples.
There are so many other properties, so be sure to look for them, and there are many properties that are not supported by all browsers and auxiliary devices, so be careful when using them too.

Let's take an example of a confirmation popup that is exposed when you leave the account registration page.

There is a backdrop behind the confirmation popup on the screen to cover the background.
The role was set to alertdialog to let you know that the area other than backdrop acts as an alert, we gave the aria-modal attribute to true.

<div class='backdrop'>
  <div
    role='alertdialog'
    aria-modal='true'
    aria-labelledby='dialog_label'
    aria-describedby='dialog-desc'
  >
    <h2 id='dialog_label'>Leaving the account page</h2>
    <div id='dialog_desc'>
      <p>Would you skip this step?</p>
    </div>
    <button>Yes</button>
    <button>No</button>
  </div>
</div>

We have linked the id value of the account registration page element to tell which confirmation popup it is in the aria-labelledby property, but the title is not exposed on the screen, so it should be hidden by adding some styling. Although be careful because if you cover it through display: none, the element gets ignored in the DOM.

Through aria-describedby, you can link the id of the element describing the purpose of the confirmation to provide an accessible description of the confirmation popup.

Next is the live attribute of the live region.
Image a screen in which if you click the amount button (say, $5, $10, $15), the charge amount is automatically set in the text input.

See the equivalent code:

<h2 id='charge_title'>Amount</h2>
<div
  aria-labelledby="charge_title"
  aria-describedby="charge_desc"
>
  <p aria-live="assertive" id='number'>{chargeAmount}</p>
  <button aria-controls="number">+$5.00</button>
  <button aria-controls="number">+$10.00</button>
</div>

If you look at the aria-live value on the p tag, you can see that it is set to assertive.

Click " +$5.00" in the above example to read the changed $5.00 and immediately inform the user that the currently set value has been updated, and click " +$5.00" once again. Now the screen reader will the updated value to $10.00.

This setting will let you know that your information has been updated.