After seven years of front-end development, I recently realized the need for accessibility...

Author | Deepak K Vijayan

Translated by | Phoenix

Planning | Yan Garden

As a front-end developer for over 7 years, I never thought my job needed to be accessible until recently.

Yes, we do provide images with alt tags and use header, footer, main, aside, nav, and section tags... That's what most people stop at. Some of us still use divs with classes as these specific layout elements. Why? Because we don't know.

It's not anyone's fault that we do this, except for a few, most people in this field are pushed into this pit to make a living, and most of them do the same thing over and over again in the pit, and finally wonder what I'm doing.

Until it is necessary to change.

Perhaps this need will come in the form of enlightenment, which, by the way, rarely happens, and it is more likely to change the correct industry accessibility specification from a guideline for development teams to a mandatory requirement.

The latter may be the situation you and I are in. Well, the small talk is over, and we go straight to the point.

Note: Not for senior front-end technicians, I didn't go into detail about accessibility, I just wanted to develop a simple guideline that can be followed across all projects, similar to a list of things to be aware of.

If you find any errors, please feel free to point them out and I will correct them as soon as possible.

Here are the things we need to be aware of when developing any front-end:

HTML Semantics - Correct use of HTML partition elements

Headings – Used to display the structure of the document, not for large font designs

Keyboard navigation uses "tabindex" and ARIA – ensuring tabs are available and removing redundant tab links

Accessible icon buttons – use at least those with the appropriate labels

Focus Indicator - Do not disable the default focus style unless there is an alternative

Provide visual labels whenever possible

Descriptive infographics – Provides a fallback text description for screen readers

1

HTML semantics

There's something called ARIA Landmarks, which simply divides a web page into different landmarks, making it easier for screen readers to navigate inside a web page.

Currently this can be achieved without active thinking, as we may have done it unknowingly, i.e. "By default, the HTML partition element defines the ARIA landmark."

This means using HTML partition elements correctly, like 、、、、 article>, etc., instead of using them.

Check out the ARIA Practice (https://www.w3.org/TR/wai-aria-practices/examples/landmarks/HTML5.html) for more in-depth learning.

2

title

Another way screen readers browse the web is by using titles.

Using headings is a way to show the structure of your document, and don't use it if you're just designing to display large fonts or bold.

Consider a scenario without an h1 page, where when a screen reader reads such a page, the user cannot know the title, and the title of the page is usually expressed in terms of representation.

In this case, to improve accessibility, you can do two things:

Ask the designer to make some necessary changes, which may not work because the design has already been signed off by the client.

Add a tag to the page structure and hide it.

When we need to hide something on a web page, there are several options:

display: none;

visibility: hidden;

opacity: 0;

clip-path: inset(100%)

Options 1 and 2 are not feasible because they remove elements completely from the DOM, screen readers are not available, and hidden attributes are not possible, which is equivalent to "display: none; ”。

Refer to hiding your element with the following style class:

3

Keyboard navigation uses "tabindex" and ARIA

What we need to understand is that not all users use a mouse to navigate the web, some only use a keyboard to navigate, and some use a screen reader. For these users, getting from one part of a web page to another may not be as simple as someone using a mouse.

Let's consider the following scenario:

Suppose we have a blog, on the list page of the article, an article looks like this:

It has a thumbnail, a title, a description, and a "Read More" button, which is a common template for almost all blog posts. So, how do we link to the detail page?

We make the thumbnails into a link (link 1), followed by the title (link 2), followed by the "read more" button (link 3), all three links pointing to the same page.

Therefore, when we use a screen reader or keyboard to navigate the page, we have to press the tab key 3 times to jump to the next article.

This, of course, must be avoided, and it is simple. For redundant links, you can add the following properties:

tabindex="-1" (it prevents links from being tab selected - for keyboard users)

aria-hidden="true" (you don't need to expose it to screen readers, as you already have the same link – for screen readers)

4

Accessible icon button

First of all, when there are buttons in the design, you should use elements, don't use other elements, and then set the style to the way the button looks, I know we've been doing this for a long time, but the time has changed.

Wait for the other elements, and then style them to look like the buttons, I know we've been doing this for a long time, but the time has changed.

The reason is that, as stated in the HTML Semantics section, native elements have many built-in ARIA attributes.

Although the button used and made looks exactly the same to most users, it looks very different to blind users who use screen readers, and screen readers may even ignore that it is a button.

Here are also some caveats:

Not styling buttons and setting them ideal

For buttons that have no text, only images, follow any of the following three steps:

Use the hidden to indicate the button label

Use aria-label on it

Use aria-labelledby on