Update/inline help a11y

[jeryj]

Fixes #43617

After discussing a bit more with @diegohaz, we've put together some clearer direction for how the markup and interactions should work.

Overview

The search input will operate independently of the results. There won't be any arrow key interactions on the results while focused on the search input. Instead, we can use a role="grid" on each search results section.

This would allow the support search component to take fewer tab stops in the flow and allow fo arrow key interactions on search results.

Markup General Structure

    <section>
      <form role="search" aria-label="Search">
        <label for="search">Search for Help</label>
        <input id="search" type="search" />
      </form>
      <div aria-label="Search Results">
        <h3 id="section-1">Support articles</h3>
        <ul role="grid" aria-labelleddby="section-1">
          <li role="row"><span role="gridcell"><a tabindex="-1" href="#">Item 1</a></span></li>
          <li role="row"><span role="gridcell"><a tabindex="-1" href="#">Item 1</a></span></li>
        </ul>
        <h3 id="section-2">Show me where to</h3>
        <ul role="grid" aria-labelledby="section-2">
          <li role="row"><span role="gridcell"><a tabindex="-1" href="#">Item 3</a></span></li>
          <li role="row"><span role="gridcell"><a tabindex="-1" href="#">Item 4</a></span></li>
        </ul>
      </div>
    </section>

Keyboard interactions

• Tabstop: Search input
• Tabstop: Search Results section 1, first item with virtual focus
• Arrow Up/Down: Move to previous/next search result. If at the bottom of the first section, an arrow down press would not do anything.
• Tabstop: Search Results section 2, first item with virtual focus. Same arrow key interactions as first section.

Other Interactions

1. Use speak() to announce state changes on the search, such as:

• Loading/Searching
• New results loaded
• Errors

Testing instructions

Fixes #

[matticbot]

Test live: https://calypso.live/?branch=update/inline-help-a11y

[matticbot]

Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:

Sections (~15065 bytes added 📈 [gzipped])

name      parsed_size           gzip_size
home         +12900 B  (+3.2%)    +3456 B  (+3.3%)
preview      +12289 B  (+9.1%)    +3173 B  (+8.5%)
help         +12289 B  (+2.8%)    +3176 B  (+2.7%)
domains      +10881 B  (+1.0%)    +2796 B  (+1.1%)
checkout      +9777 B  (+0.6%)    +2464 B  (+0.6%)

Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to.

Async-loaded Components (~3796 bytes added 📈 [gzipped])

name                                             parsed_size            gzip_size
async-load-blocks-inline-help                       +12289 B  (+19.4%)    +3195 B  (+21.5%)
async-load-blocks-inline-help-popover                +1588 B   (+0.8%)     +554 B   (+1.0%)
async-load-blocks-support-article-dialog-dialog       +153 B   (+0.2%)      +47 B   (+0.2%)

React components that are loaded lazily, when a certain part of UI is displayed for the first time.

Legend

What is parsed and gzip size?

Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory.
Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.

Generated by performance advisor bot at iscalypsofastyet.com.