Connectors page: Improve accessibility

[t-hamano]

I think the new Connectors page needs some improvement in terms of accessibility.

• The button text is the same for all connectors, which can be confusing for users who rely on screen readers. As with the theme and plugin install pages, I think explicit aria-labels are needed instead of visual text. For example:
  • Install: Install {connector_name}
  • Installing: Installing {connector_name}...
  • Set up: Set up {connector_name}
  • Cancel: Cancel {connector_name}
• When an action is completed, no notification is sent to the screen reader. We must notify the user that the action is complete via wp.a11y.speak or a snackbar:
  • Install connector
  • Save a valid API key
  • Remove API key
• The focus is lost in the following cases:
  • Install a connector
  • Save a valid API key
  • Remove API key
• When the Set up button is triggered, focus should move to the text field, not the Cancel button.
• If the Save button is pressed and the API key validation fails, the message It was not possible to connect to the provider using this key. will be displayed, but it will not be announced to the screen reader.

cc @joedolson

[carolinan]

I was surprised by the sticky header, but I think it's an edge case:

• Enable zoom, say, 150%.
• Expand all connectors
• Move focus to the input of the first connector; it doesn't scroll into view, it is covered by the header.

On other editor screens with the sticky header, like Editor > Templates, the focused item does scroll into view.

[joedolson]

This definitely needs accessibility work done. It's been on my list to look at, but new interfaces being added this late puts everything on an extremely tight timeline.

[talldan]

The button text is the same for all connectors, which can be confusing for users who rely on screen readers. As with the theme and plugin install pages, I think explicit aria-labels are needed instead of visual text.

I seem to recall a11y feedback in the past suggesting not to do this, so I'm curious about the right approach.

IIRC, the issue was that users that rely on speech recognition / voice command software might try selecting a button using the visual label, but it might not work if the software uses the aria-label and there's a mismatch.

[t-hamano]

IIRC, the issue was that users that rely on speech recognition / voice command software might try selecting a button using the visual label, but it might not work if the software uses the aria-label and there's a mismatch.

This certainly seems reasonable.

However, since theme and plugin pages already use aria-labels that are different from visual text, I simply assumed this might work in the Connectors page as well 🤔

[joedolson]

Additional accessibility issues:

1. The primary heading 'Connectors' should be an h1, currently is an h2
2. The Install button has aria-expanded, and toggles the value after installation, while also toggling the text. In general, if you toggle the state of a button, you should not also change the text. In my opinion, the install button should not have aria-expanded. It doesn't really make sense. The same problem exists for Set up /Cancel, in that the state creates confusion with the button text. What does it mean to have a 'Cancel' button show aria-expanded="false"? So, pressing this will unexpand the cancel state? It would be much clearer to have a button with static text e.g. 'Settings' and aria-expanded. That way it represents what you're expanding, and the state of the button is clear.
3. The individual connectors should have headings. Each service should have a heading, e.g. <h2>OpenAI</h2>.

This relates to the issues @t-hamano cited above with the buttons not having unique names. I'll expand on that a bit: in WCAG, links need to have unique names, but buttons don't. The controls shown above for plugin cards are links, even though they behave as buttons, so they've been given expanded context. Buttons are expected to derive their differentiation from context. E.g., a heading that precedes the button would be helpful. Wrapping the component settings in a fieldset with legend would be even clearer, although for styling purposes a role="group" with aria-labelledby would be fine, too.

There are significant advantages to keeping the visual text of a control an exact match for it's accessible name for voice control, so as long as the buttons have clean context, I'd prefer to leave them with their visual text as labels.

4. If there were spoken announcements that include the name of the connector being installed, that would give enough context to confirm what's happening. Progress announcements sent via a polite ARIA announcement would be helpful.

Agree that all of the error messages would benefit from an ARIA announcement.

I disagree about the focus move on clicking 'Set up'. As far as I can see, these are the same button, and focus should not be moved. As per my comments about, I don't think this button should change names: it should have a static name so that the state management makes sense to a screen reader user, but focus should not be moved.

Overall, I think the biggest issues here are the losses of focus and the lack of semantic structures. The buttons could have expanded labels, but I don't think it's necessary to do so, if they're placed in better context. Announcements of reaction and progress would be very helpful.

[carolinan]

This PR will impact this page aswell
#75934
Note that @jameskoster Is suggesting rewriting it and using DataViews.

Can we decide what needs to done for 7.0 first and what can wait?

[jeffpaul]

Noting from today's core-ai office hours in Slack that it was decided to NOT proceed with DataViews during 7.0, but perhaps to consider that in the 7.1 cycle. As such, let's please proceed with accessibility testing and issue resolution here in the 7.0 cycle with the existing Connectors screen; thanks!