Screen Reader Users Do Not Know Sections in Theme Customizer are Expandable

[davidakennedy]

The issue: When testing the new Widget customizer with a screen reader (in this case Mac OS 10.2 with Voiceover and Chrome), the arrows that expand each Customizer section(s) do not announce in a screen reader. A screen reader user may have no idea they are expandable. Note: this is a pattern that exist throughout the Customizer, not just with the new Widget customizer additions.

This relates to this kind of markup on the /wp-admin/customize.php screen.

<li id="accordion-section-title_tagline" class="control-section accordion-section top">
    <h3 class="accordion-section-title" tabindex="0">Site Title &amp; Tagline</h3>
    <ul class="accordion-section-content">
        <li id="customize-control-blogname" class="customize-control customize-control-text">
            <label>
                <span class="customize-control-title">Site Title</span>
                <input type="text" value="Super Awesome WordPress Trunk Testing Site" data-customize-setting-link="blogname">
            </label>
            </li><li id="customize-control-blogdescription" class="customize-control customize-control-text">
            <label>
                <span class="customize-control-title">Tagline</span>
                <input type="text" value="Just Another Super Awesome WordPress Trunk Testing Site for Theme Development" data-customize-setting-link="blogdescription">
            </label>
            </li><li id="customize-control-display_header_text" class="customize-control customize-control-checkbox">
            <label>
                <input type="checkbox" value="fff" data-customize-setting-link="header_textcolor">
                Display Site Title &amp; Tagline
            </label>
        </li>
    </ul>
</li>

What I expected: Some way to know via announcement with the screen reader that the heading elements are expandable.

Recommendation: Use a similar markup pattern to this accessible accordion that relies heavily on WAI-ARIA: ​http://hanshillen.github.io/jqtest/#goto_accordion

I'd be happy to consult on and test potential solutions.

[westonruter]

@davidakennedy: Is this same problem also present on the widgets admin page?

[SergeyBiryukov]

Related: #27592

[davidakennedy]

Replying to westonruter:

@davidakennedy: Is this same problem also present on the widgets admin page?

Yes, looks that way. I glanced at the markup and it's nearly identical. Ticket #27592 also applies there. So we should definitely try to address both areas.

Should I create a separate ticket for that or should we change the component to Widgets and use this ticket for both areas?

By the way, great job with the Widget customizer! It works great navigating with a keyboard only. :)

[davidakennedy]

Never mind, just saw this comment: https://core.trac.wordpress.org/ticket/27592#comment:2 Sounds good to me!

[DrewAPicture]

Seems like this also may be an issue in the menus screen as (last time I checked) there is shared code there.

[davidakennedy]

Replying to DrewAPicture:

Seems like this also may be an issue in the menus screen as (last time I checked) there is shared code there.

You're right. The code is very similar once you add menu items. I'll take a closer look soon. We should definitely try to tackle this as a pattern across the Admin and see if we can't make it better everywhere.

[joedolson]

Adds screen reader notice how to expand panels

[ocean90]

joedolson, is there a difference between "enter" and "return" for screen readers?

In 27591.2.patch​ I reverted the tabindex="-1" change, otherwise I couldn't access the panel via tabbing.

[celloexpressions]

The tabindicies are automatically turned on and off with JS as of so no, that change isn't needed.

To help distinguish between panels and top-level sections, can we use the word open instead of expand for panels? Sighted users have a small visual indicator of the direction it'll open in, but then get a very large animation to indicate the change of context going into a panel. I'm worried that screen reader users could easily become lost or disoriented going into or out of a panel, especially if panels aren't grouped together at the top.

[joedolson]

I don't have a problem with using open instead of expand; that's probably a better word choice, on the whole. As to return/enter, there's no difference between the two for screen readers - but I'm not sure what the generally preferred term is. Either works for me.

[SergeyBiryukov]

In 29240:

Customizer: Add screen reader text to announce that panels and sections are expandable.

props joedolson, ocean90.
fixes #27591.