Making Your HubSpot Website WCAG 2.1 Compliant

4.1.2 Name, Role, Value

MCS Accessibility Team

MCS Accessibility Team
Last Updated July 23, 2020

The following directions are part of a full step-by-step guide to making a HubSpot website WCAG 2.1 AA compliant. These recommendations are intended for websites managed on the HubSpot CMS but can be adapted for other content management systems. In addition to explaining the WCAG Success Criteria and how to address them, this guide also describes how the AudioEye Managed solution may address each issue.

LEVELA
Success Criteria

4.1.2 Name, Role, Value

  • Resolved
  • Partially Resolved
  • Manually Managed
  • N/A - Level AAA
Principle: Robust
Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.
Guideline: Compatible
Maximize compatibility with current and future user agents, including assistive technologies.

For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.

Note 1: This success criterion is primarily for Web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification.

View Official WCAG 2.1 Compliance Techniques

  • This criteria is partially resolved and/or detected with AudioEye Managed but may require some manual intervention and/or collaboration with AudioEye.

Understanding 4.1.2 Name, Role, Value

"If custom controls are created, or interface elements are programmed (in code or script) to have a different role and/or function than usual, then additional measures need to be taken to ensure that the controls provide important information to assistive technologies..."

This criteria applies specifically at web developers who script their own custom interface elements, which is an uncommon use case. If you're just using standard HTML elements, you'll resolve this criteria and be compliant by default. No manual intervention will be required, and you can stop reading right here!

The criterion's purpose is to ensure that your user will be able to easily interact with your custom controls when using assistive technologies such as screen readers or speech recognition software.

Assistive technology must be able to understand what your control elements do and how they change when used, including:

  • The name of the element. In some cases, this is also the element's label.
  • What the element does. For example, does it expand a collapsible menu?
  • State changes. In particular, the user must know when the element is in focus.

By providing information on the role, state, and value information on all your custom user interface components, you'll ensure your interface is compatible with assistive technology.

There are many different ways you can include this information. Some developers insert markup language including aria-labels. Others might pull in accessibility APIs, such as the the Microsoft Active Accessibility (MSAA) API

How AudioEye Helps

AudioEye will alert Managed customers when 4.1.1 violations are detected and can take action with client approval. However, for instances where Managed customers do have full control to remediate the source issue, AudioEye will collaborate with accessibility stakeholders to instruct them on what specific changes are required, why the changes are important, and how the changes can be implemented. 

Recommended Solutions

As you develop your custom programming, think about accessibility from the very beginning of your project. Identify how you want to ensure the name, role, and value of each element is included (either markup or an accessibility API). If you want to create an entirely new type of user interface component, you'll want to know that too, so you can code in your own accessibility provisions yourself.

Once you've developed your interface, you'll test it by:

  • Visiting your web page using an assistive technology such as a screen reader.
  • Checking that every interface component contains a name and role/
  • Changing the value on each applicable component, and confirm that your tech is alerted to the value change (i.e. click an element to bring it into focus and make sure your screen reader caught the change).

For more information, please visit the official W3C article: Understanding 4.1.2 Name, Role, Value


Download the WCAG 2.1 Compliance Checklist

Checklist Download

Questions?

Let us know if we can help you address this specific WCAG Recommendation.

Recent Morey Creative Studios Blog Articles