Review a11y concerns in ContentModerationConfigureForm

The select link is lacking context for screen readers

As a core gate, this would probably be WI crticical I think? Hopefully I'm using the tag correctly, thanks. Thanks Lee for filing this!

Looks fine to me, I would RTBC, but think we need accessibility sign off.

I did an accessibility review.

Unfortunately #8 results in aria-label="Select content type entities" on the <select> and Select the content type entities for the Editorial as the modal title.

These should be aria-label="Select content types" and Select the content types for the Editorial workflow as the modal title.

That's not our fault.

\Drupal\Core\Entity\EntityType::getPluralLabel adds @label entities.

There is an issue open for this, but I can't find it.

We could change the modal title from "Select the content type entities for the Editorial" to "Select the content type entities for the Editorial workflow" but that's a separate issue.

We don't need to do this - it's going beyond what we need to do to satisfy the accessibility gate.

The operations links elsewhere in the admin UI don't have aria-label attributes, so patch #8 would introduce a UI inconsitency. Likewise, the aria-label attributes already present in the State and Transition operations links in WorkFlowEditForm.php are out of step with other core pages.

The select link is lacking context for screen readers

The link does have context, at least as far as it is defined in WCAG. There are two success criteria relating to link text.

1. 2.4.4 Link Purpose (In Context) - Level A
   At this level it's sufficient if a link makes sense in the context where it encountered. Context comes from the semantic document structure. Typically this means the surrounding text in a sentence/paragraph, or in this case the related table header element. Most screen readers offer tools to interact with tables (announce headers of current cell, jump to start of row, etc). A user can employ these to find be sure that they have the correct operations drop-button in a table.
   Having said that, there are some ways we could improve the link context for operations in tables:
   • Table <caption> elements - our admin forms are lacking these currently. Most admin pages in Drupal have just a single table, and the purpose can be gleaned form the page title. The workflow configuration form is unusual in having 3 separate tables (states and transitions from WorkFlowEditForm, plus the applies-to table from ContentModerationConfigureForm). Table captions could help a lot here!
   • Row-level table headers. When these are absent, some screen readers will resort to treating the first row cell as the header. This is OK much of the time, but our tabledrag/tableselect feature doesn't play well with them. For example Chromevox gives the table headers as "row header drag to re-order, column header operations". We'd really want it to say the row header is "Draft", say.
2. 2.4.9 Link Purpose (Link Only) - Level AAA
   This level is about links being understandable when they are disconnected from their context in the document structure, for example when using a list-all-links screen reader tool.
   The aria-label attributes in patch #8 would help to satisfy Link Purpose (Link Only), but level-AAA exceeds the requirements of our accessibility gate. The read-more links for node teasers already address Link Purpose at level-AAA. These are more important in a way, as they are aimed at website visitors, rather than admin-users.
   I do think it would be a good idea to pursue 2.4.9 Link Purpose (Link Only) for operations links across all of Drupal core. However I think it would be better to target a future D8 minor release, and introduce it across the whole of core admin, instead of doing it one form at a time.

So in the short term I propose:

• Won't-fix for the the patch in #8.
• Start a new patch here to remove the aria-label attributes from the state and transition operations links in WorkFlowEditForm.php. This is to avoid being inconsistent from the rest of core. I guess we can probably do this in time for an 8.4.0 RC release.

Longer term, let's use separate issues to explore admin-wide table captions, row-level table headers, and level-AAA link text for operations. These would all make great targets for 8.5.0 say.

The patch I'm suggesting would remove the 4 aria-label instances from edit/delete state/transition operations in WorkFlowEditForm.php

@Sam152 - Beat me to it! 😆

The patch in #16 looks to cover everything mentioned in #15. Talking to @andrewmacpherson on Slack it sounds like consistency is key, so lets get this in!

I just tried #16 in simplytest.me - all looks good.

Updating issue credit to add Wim and Andrew for their reviews

Checked there were no other instances of aria-label in content moderation and workflows modules.

Committed 3cb53fe and pushed to 8.5.x.

Cherry-picked as 9f0c704 and pushed to 8.4.x