Accessible Labels, and How the Issues Regarding to the Same are Mapped Under Different WCAG 2.1 Guidelines.

Hi all, I am back again with yet another article. This time I will be writing a bit technical one.

Let us discuss about the accessible labels, and how issues regarding to the accessible labels are mapped under different WCAG 2.1 guidelines.

Every control on a webpage should have meaningful label which should describe its purpose. There are various techniques for providing accessible labels. This is best done by using an HTML label element. This technique will associate the label with the control programmatically.  

 

<label for="firstname">First name:</label>

<input type="text" name="firstname" id="firstname">

 

There are different other techniques as well for providing the labels like by using aria attributes such as “aria-label”, “aria-labeledby”, “aria-discribedby” etc. You can have a look on the following articles to learn how to provide the accessible labels.

·       form elements and accessibility

·       Labelling Controls | Web Accessibility Initiative (WAI) - W3C

 

Ensure following things while providing an accessible label.

·       Labels should be descriptive and meaningful: Label should clearly indicate its purpose. It does not mean that it should be lengthy, but it should be descriptive enough. For example, if there are 2 fields in a form that ask for first and last name, then it should be labelled as “First Name” and “Last Name”.

·       Provide important cues and instructions if needed: Enough information should be provided for the user to accomplish the task without undue confusion or navigation. For example, If there is a  field for entering a date, then it should specify correct format for the date.

·       Label must be properly associated: People who are using different assistive technologies navigate on the controls in different ways. For example, screen reader users navigate on the form controls by using tab key or by using quick navigation keys like ‘b’ for buttons, ‘x’ for checkboxes etc. So, If the label is not associated with the control, then screen reader will not speak the label while navigating through tab or quick navigation keys. the purpose of the control should be clear to everyone, no matter what technique they use to navigate on the same.

·       Group Labels should be associated with the group of elements: For a control that is a group of options, such as a drop-down menu or list of radio buttons or checkboxes, the group should have a label that describes the relationship of the options. the Users of different assistive technologies must be able to understand the purpose of the group of elements.

·       Use aria-label wisely: The value of aria-label will replace the actual label text. So, use aria-label only when it is required. If visual label is there, and there is no accessible label, then one can use the aria-label.

·       Use aria-labelledby wisely: Similarly, the ID provided using aria-labelledby, will replace the actual label text. So, this should not be used for associating the text for making the label descriptive for the screen reader users. Aria-discribedby can be used for the same. If there is a visual label, and there is no accessible label, then one can use aria-labelledby.

·       Make sure that the visual label matches the accessible label: Visual label is the label which you can see on the screen, and the accessible label is the label which is identified by the assistive technologies. People who are using the speech input technologies rely on the visual labels for giving the command. If the visual label is not the same as the accessible label, then their assistive technology will not understand that what that person is asking to do.

·       Do not rely on the placeholder text for providing label to an input field: Wherever possible, avoid relying on placeholder text to label an input field. There are several usability issues relating to placeholder text because it disappears when the user starts typing into the field. So, it's much better to have an external label that remains visible at all times. This will also help the users with cognitive disabilities to understand the purpose of the input field.

·       Same labels should be there for the controls performing the same actions: If there are more than one controls on the webpage performing the same actions, the labels should be same for those controls. Otherwise it will create confusion in the user’s mind if the labels are different for the same.

·       Same labels should not be there for the controls performing the different actions: Again, this will also create confusion in the user’s mind if the same labels are provided for the controls performing the different actions. They will expect the same functionality from those controls.

 

Let’s have a look that how different issues regarding to labels are mapped under different WCAG 2.1 guidelines.

 

Issues

WCAG 2.1 Guidelines

If there is no visual label.

3.3.2 Labels and Instructions

If there is no accessible name/label. Means the label is not identified by the assistive technology.

4.1.2 Name Role Value

If labels are not sufficiently clear and descriptive enough.

2.4.6 Headings and Labels

If instructions are missing for the edit fields.

3.3.2 Labels and Instructions

If labels or instructions are not correctly marked up, identified, or associated with their respective controls 

1.3.1 Info and Relationship

If group label is not associated with the group of elements.

1.3.1 Info and Relationship

If visual label and accessible label is not same.

2.5.3 Label in Name

If labels are not same for the controls performing the same action.

3.2.4 Consistent Identification

If labels are same for the controls performing different actions.

2.4.6 Headings and Labels

 

Let us have a look on few examples.

 

Example 1

Richa who is a screen reader user is surfing a blog website and found multiple “read more button” while pressing tab key. She is confused and unable to know that the “read more button” belongs to which article.

In the above issue, “read more button” is not associated with the article name. This will be mapped under WCAG 2.1 Guideline 1.3.1 Info and Relationship.

 

Example 2:

Aditi is creating account on an E-Commerce website, there is a button which is visible as “next button”. However, her screen reader is just announcing as “button” for the same. Because of which, she is unable to identify the “next button” on all the screens.

In the above issue, accessible label is missing. This can be mapped under WCAG 2.1 guideline 4.1.2 Name Role Value. This issue can be rectified by providing “aria-label” or “aria-labeledby” attributes.

 

I  think we should call for a day as of now. Hope it is helpful.

 

 

 

 

Comments

Post a Comment

Popular posts from this blog

Accessibility benefits everybody, not only disabled. So, lets create an inclusive world.

          Accessibility is going to benefit each one of us. It is not only benefit people with disability. Let us first understand that what does the word “Accessibility” means? In simple words, accessibility means able to access. According to W3C,  accessibility  “means that websites, tools, and technologies are designed and developed so that people with disabilities can use them. More specifically, people can: perceive, understand, navigate, interact with the Web and contribute to the Web.”. However, accessibility helps all of us. For example, captions are necessary for the people who are hearing impaired, the same can also benefit for the people who are watching the video in a noisy environment. Similarly, alternative text for the images are important for the people who are visually impaired, but at the same time it will help to the people who are viewing the image with low internet connection. The biggest problem is people don’t consider acces...
Read more

Why Accessibility of Digital Learning Materials are essential?

Imagine a student named Noah, known for his brilliance in class. Despite his intelligence, he struggles to grasp the concepts of equations taught by his teacher. The reason? Noah is blind, and he cannot see the blackboard or read the textbooks like his peers. This leaves him feeling isolated and excluded in a classroom where knowledge is meant to be shared equally. So, what’s the solution? One option could be providing braille books, enabling him to read and follow along as the teacher explains. However, braille books are costly, and Noah, who may have lost his sight later in life, might not even be familiar with braille. Another, seemingly perfect solution, is equipping him with a laptop and digital textbooks that he can access using screen readers. But what happens if the digital content isn’t accessible with these screen readers? Now, consider another scenario. Sophia and her friends are excited to take a crash course on generative AI. But Sophia, who is hearing impaired, finds ...
Read more

Is Your Authentication Process Truly Accessible for Everyone?

Suppose  you're doing an important financial transaction, and at the very last step, you're asked to prove you're human by solving a CAPTCHA. But no matter how hard you try, you can't get past it. Frustrating, right? You’d feel stuck and helpless. Now, think about how this might feel for people with disabilities. Many authentication methods can create similar barriers for them, leading to the same feelings of frustration. Of course, security is important—we all want authentication to be as secure as possible. But here’s the thing: it can be secure and accessible at the same time, without compromising either.   How can we ensure that authentication process is accessible? Make sure that no step in the authentication process requires mental effort. Users should not be forced to solve puzzles, recall information, or transcribe anything. This is particularly important for people with cognitive disabilities, as they may struggle with tasks like remembering usernames...
Read more