Missing Descriptions of Functional Elements

Back to blog

Making Accessibility Visible Part 4: Missing Descriptions of Functional Elements

Posted October 26, 2021


Posted October 26, 2021

Making Accessibility Visible: Part 4
Making Accessibility Visible: Part 4

This is part 4 in our Making Accessibility Visible series. The series explores how people with visual impairments use screen readers to navigate both accessible and inaccessible sites. We share technical notes to help you solve some of the accessibility issues on your site. Read Part 1: Missing Button Labels here, Part 2: Heading Helpfulness here, Part 3: Image Alt Text here, and Part 5: Keyboard Focus and Dialog Behavior here.

In part 4 of the Making Accessibility Visible video series, professional accessibility testers Sarah and Leslie use screen readers to find out if they can change their delivery address on an e-commerce site. Sarah and Leslie walk us through the steps while testing both accessible and inaccessible versions of an accordion menu on the same webpage. 

Watch the video to understand the importance of proper descriptions of functional elements for users who navigate a website with a screen reader.

Code/technical notes from the video

Task prompt

Navigate the content in the FAQ section of the webpage to find out if you can change your delivery address. 

Results description

When content changes on a webpage in a way that is only displayed visually, the code needs to cue the screen reader to tell the user what type of content they are navigating and how they can interact with it. 

On this page, the FAQ section is an accordion-style menu, where the menu elements can be in an open or closed state. A person using a screen reader can expand or collapse different sections of the menu. Proper descriptions are necessary here, so that people using assistive technology can navigate the menu and determine if they can change their delivery address.

Testers featured

Sarah, Leslie

Broken elements

The menu type and state are missing from the code and only visually represented on the page. There is no indication for the screen reader to announce the type of menu, or even whether a user can interact with it. Without these descriptions, someone using assistive technology cannot navigate this page to find out if they can change the delivery address.

          <a class="accordion active">What are my delivery options?</a>

          <div class="panel active" style="display: block;">

            <p>We deliver orders globally. ...</p>


          <a class="accordion">How can I track my parcel?</a>

          <div class="panel" display: none>

             <p>When your order leaves our warehouse, ...</p>


Working elements

The name on the control cues the screen reader to tell the user that the menu type is accordion. The button announces whether the accordion menu is open or closed, and the user can easily navigate and collapse or expand the content to figure out if they can change the delivery address. 

<ul aria-label="Accordion Control Group Buttons" class="accordion-controls">


              <button aria-controls="content-1" aria-expanded="true" id="accordion-control-1" class="accordion">What are my delivery options?</button>

              <div aria-hidden="false" id="content-1" class="panel">

                  <p>We deliver orders globally. ...</p>




              <button aria-controls="content-2" aria-expanded="false" id="accordion-control-2" class="accordion">How can I track my parcel?</button>

              <div aria-hidden="true" id="content-2" class="panel">

                <p>When your order leaves our warehouse,...</p>




Describing Functional Elements with Status Messages

When sighted people navigate the internet, they see visual cues and status messages that convey information without interrupting the user experience. For people using screen readers, these elements and statuses need to be properly labeled and communicated, or else they may go unnoticed. Without proper labels and status descriptions of functional elements, assistive technology users may potentially miss out on the functionality and key messages of the page.

When we talk about status messages, we are referring to content changes that inform users on the results of their actions, progress on a process, errors, etc. You can find an in-depth description of status messages on the World Wide Web Consortium (W3C) website. 

To make your website more accessible, assign ARIA (Accessible Rich Internet Applications) roles and properties to status messages, so that a screen reader can read them out loud. ARIA extends HTML, adding attributes that communicate to assistive technology. 

For more information and tips on change announcements, check out the resources below.

Additional Resources

Understanding Success Criterion 4.1.3: Status Messages
Learn about the WCAG Success Criterion that covers status messages. You will get examples and techniques for creating status messages.

Using ARIA for status messages
Read this article to learn how to add ARIA attributes to HTML elements for status messages.

Ask a tester:
How do you share feedback on accessibility issues with site owners? Do you feel satisfied with the process?

"It’s very frustrating and very sad when people don’t even reach out and say how can we help or we hear you. I don’t even care if I’m directly involved in the process of fixing things, I just care that I’m heard as a user."

- Leslie, a professional accessibility tester who is blind

Ready to test your website for accessibility?

Scan your website now.

Share post


Keep Reading