• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
Logo for DigitalA11Y

Digital A11Y

Your Accessibility Partner

  • About
  • Articles
  • WAI-ARIA
  • WCAG
  • Resources
    • Cheat Sheets
    • A11Y Blogs
    • A11Y Toolkit
  • Contact
You are here: Home / Web Accessibility / WCAG / Understanding SC 4.1.2 Name, Role, Value

Understanding SC 4.1.2 Name, Role, Value

Last Modified: December 5, 2019 by Raghavendra Satish Peri 6 Comments

4.1.2 Name, Role, Value: 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. (Level A)

Note: 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

The intent of this success criterion is to make sure that assistive technologies receive the necessary semantic information from all the interactive elements present on the page. Each element has an accessible name, role, value, state and property which are conveyed to assistive technologies. In turn, this information enables people with disabilities to interact with these elements.
Native HTML elements, if coded according to standards, will have all the necessary name, role, value and state by default. But there are so many custom component widgets like tabs, tree, grids etc. that need to be constructed from ground up and when need to be made accessible we rely on WAI-ARIA. These custom components need to be provided with a name, role, value, state & property manually using WAI-ARIA attributes. For example, if a div or span needs to be constructed into a button, we can use role=button. But that doesn’t provide accessible name or keyboard operability. So we use aria-label to provide name and tabindex=0 to provide keyboard operability. At the same time we also need to provide the click handlers using JavaScript to this button so that users can use enter or spacebar key to activate the button.

Doesn’t That look like lot of work? if one uses the native HTML button, element all these features are provided by default and no extra code is required. Only when some feature that cannot be coded using HTML use scripting languages to build the widget and use WAI-ARIA to provide the necessary name, role, value, state and properties.

Points to Ponder

  • Use native HTML elements wherever possible
  • USE WAI-ARIA attributes while constructing custom component widgets
  • Make sure custom widgets are keyboard operable using spacebar or enter keys
  • Provide tabindex=0 for custom widgets so that they receive tab focus
  • Make it a practice to read ARIA specifications to understand the implications and the consequences of ARIA roles, states and properties before using them

References

Understanding Success Criterion 4.1.2

Share A11Y Love

  • Twitter
  • LinkedIn
  • Facebook
  • Reddit

More Accessibility Articles

Filed Under: WCAG

About Raghavendra Satish Peri

Raghavendra Satish Peri is a digital accessibility evangelist working at Deque Systems as Product Manager [Accessibility]breaking web accessibility & mobile accessibility challenges. He authors an Accessibility Blog at DigitalA11Y.com & is galvanizing the adoption of accessibility by inspiring the local tech community with meetups and mentorship. He propelled this thought by founding HelloA11y.com, a community of accessibility professionals, developers and enthusiasts. When away from his computer, Raghava can be found at local cafes & restaurants sampling cuisines, attending local meetups, listening to audio books or writing on his Personal Blog at raghava.in.

Reader Interactions

Comments

  1. Jyothi Reddy says

    December 9, 2019 at 8:41 am

    Well explained Raghava!

    Reply
    • Raghavendra Satish Peri says

      December 10, 2019 at 7:04 pm

      Thanks for stopping & showing your appreciation through the comment Jyothi.

      Reply
  2. Rehan says

    November 6, 2020 at 12:32 am

    a good one explanation.

    Reply
  3. Al says

    January 1, 2021 at 5:25 pm

    Does a link that activates a script that generates content (e.g. link that opens a navigation menu) have to have role=”button” in order to meet this criteria? Obviously using role=”button” is more intuitive to screen reader users, just wondering if it is a requirement to meet this criteria.

    Reply
    • Raghavendra Satish Peri says

      January 2, 2021 at 7:42 am

      Hello,
      The button role is not must to open the menu’s… if there is a link with appropriate name, role & value then it passes this SC…

      Reply
      • Al says

        January 3, 2021 at 3:15 pm

        Thanks

        Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Primary Sidebar

Get Digital A11Y in Your Inbox

Recent A11Y Articles

  • A Sneak peek into WCAG 3.0 First Public Draft
  • Understanding SC 4.1.3 Status messages
  • Understanding SC 2.5.4 Motion Actuation
  • Understanding SC 2.5.3 Label in Name
  • Knowbility looking for mentors in its Accessible Internet Rally

Recent Comments

  • Raghavendra Satish Peri on Foresee Your Colors: Tools to Evaluate your design for Color contrast Accessibility
  • Raghavendra Satish Peri on Digital Accessibility Companies Roundup
  • Andrew Somers on Foresee Your Colors: Tools to Evaluate your design for Color contrast Accessibility
  • Regine Lambrecht on Digital Accessibility Companies Roundup
  • william hruska on 18 Free Mobile Accessibility Testing Tools

A11Y Categories

  • Design
  • Events
  • HTML
  • IOS
  • Mobile Accessibility
  • News
  • Tools
  • WAI-ARIA
  • WCAG
  • Web Accessibility

  • Privacy Policy
  • Sitemap
© 2021 Digital A11Y