Addition of natural language to Article and Basic page links on Create Content page

Please find a patch adding the title attribute to the link. I also had to edit the node-add-list.html.twig file in Seven theme as it's basically not using the generated link.

Title isn't read consistently be assistive technology like JAWS. So this pattern wouldn't work:

+        <a href="{{ type.url }}" title="{% trans %}Create {{ type.label }}{% endtrans %}">
+          <span class="label">{{ type.label }}</span>

The better approach would be something like:

+        <a href="{{ type.url }}">
+          <span class="visually-hidden">Create</span> <span class="label">{{ type.label }}</span>

It might be more usable to simply make this visible to everyone:

+        <a href="{{ type.url }}">
+         <span class="label">Create {{ type.label }}</span>

This would require input from the UX folks as it would be a change. It would also get problematic if you had 10 or so content types.

I haven't dealt with translation here obviously, just providing a short response.

This seems like a simpler and more consistent approach.

+1 for either of the new patterns in comment #2.

Markup looks OK.

Tested the patch in ChromeVox - the invisible "Create " text sounds as intended. We're not expecting any differences with other screenreaders?

One niggle: are we being inconsistent by using "Create" as the extra word? I think we should have "Add ..." for consistency with the button on /admin/content (the previous page, typically).

whoops, should have said needs work

Consistency is good and this is a simple change.

Looks good, a nice simple improvement.

Updating the propsed resolution to reflect what the patch in #6 actually does :-)

Why only seven and not classy and core twig templates too?

@alexpott, thanks! There is a node-add-list.html.twig file in Classy but can't find a similar reference in Bartik. Am I missing something?

The classy reference is considerably different than the Bartik one using definition lists rather than list items. It's quite different, but not sure why it should be. It's also less natural to include as a natural language list. It's different enough and is also using <dt>{{ type.add_link }}</dt> but I suppose we could change that somewhere in Classy.

I also think that it would make sense to do this in core/themes/seven/templates/block-content-add-list.html.twig but note that there is no similar file in Bartik or Classy.

Here's a new patch with the changes to the block.

This patch is fine for the templates in the Seven theme.

Bartik doesn't have node-add-list.html.twig, so inherits the version from Classy. This is similar to the version in Node module; a DL list with some an extra wrapper class.

Neither Bartik nor Classy have block-content-add-list.html.twig, so Bartik uses the version form block_content module; it's a DL list.

So it's only the Seven theme that changes things to a UL list. (It's the same situation in D7: core modules use DL and override this in the Seven theme. It looks like these were straight-forward conversions to Twig in D8. )

So the remaining question is what to do with the default templates in Node and Block Content modules - do we want to leave those as DL lists? It looks like these were straightforward Twig conversions; I'm not clear if there was ever a discussion about whether they should be DL.

Changing component to 'markup' as we're now looking at more than one core module. Also adding dreammarkup tag, seems appropriate to alert whoever watches that.

Hi Guys,

This looks very good and works on Firefox (Mac) with default Voiceover.

One suggestion I would make is adding a full stop after the type.label, probably also in a visually-hidden span. This will mean that there is a slight pause at the end of the label, before the description is read, adding more clarity.

<span class="visually-hidden">Add </span><span class="label">{{ type.label }}</span><span class="visually-hidden">.</span>

I tried out the extra full stop with Mark (we're testing it at the DrupalCon sprints). On Firefox/Voiceover you do hear a slightly clearer pause between the content type label and description. I think this falls into the issue scope of natural language for the whole link. The content type label and description are both user-customizable, and the link wraps both of these. The full stop needs to stay in the Twig trans block.

I think ideally we should get the natural language into the core node/block_content modules. If we only do this for the Seven theme, then Contrib admin themes (adminimal, ember, shiny) won't receive any benefit. As Mike notes, DL lists wouldn't work so well.

Attaching a patch with the suggested addition of <span class="visually-hidden">.</span> after each label. I tested this and it sounded really good with voiceover.

I'm not sure I understood next-steps though. Is this patch usable in Seven or do we not want to move forward with it without bringing along the core node module?

Think instead of altering the twig templates we can add an aria-label attribute? So other themes won't have to update their templates too.

This will definitely need accessibility check.

Updated claro theme as they had a custom implementation. The change for the node.module will reflect in stable9 and starterkit themes.

Thinking back on this, I don't think any of these patches are going to work for us, for the simple reason that they are not translatable.

At a minimum, we need the Add to be like this {{ 'Add'|t }}, but even with that we cannot be sure that the order of words will be the same in every language, so the full translatable string will need to be within the same block, and not a number of blocks concatenated.

Something like (breaking onto multiple lines just for clarity):

  {% trans %}
    <span class="visually-hidden">Add </span>
    <span class="label">{{ bundle.add_link.text }}
    <span class="visually-hidden">.</span></span>
  {% endtrans %}

So like this?

Yes, but that seems to only be targetting the Claro theme. We'd need to make sure we cover the other core themes and modules that use this as well, such as stable, stable9, starterkit, system, etc

I took a look at the other themes in D10 and claro seemed to be the only theme using a special template. The rest believe fell back to the default from the node.module.

WCAG 4.1.2 SC.

@smustgrave in that case, I think this patch looks good.

@mgifford you added the WCAG412 issue. Is there any thing we need to consider here for that, or are you okay with this patch?

I'm going to ask a Claro maintainer to have a look at this as well, as I don't want us to change their markup with them knowing about it.

I've quickly tested the patch in #32 with voiceover in macos 12.6.1 and safari 16.1 and the latest edge and firefox.

I've first tested to tab through the page with the tab key (see macos_voiceover_tab.mp4). problem here is that the description is unnoticed in case you dont know that it is there. if you are opening up the rotor the period at the end of the sentence is inconsistent with the other links in the rotor. safari, edge and firefox behave the same.

I've then tested to use the virtual cursor (arrow up and down) to go through the page (see macos_voiceover_tab.mp4). that way i am able to getting aware of the description. the only odd thing is that voiceover is announcing styling informations like bold, italic, blue and alike which is distracting and at the same time you have not one element announced for example for the article link element but three text elements inside the wrapping link element. first add then the link title then the period. and the virtual cursor only works in safari, in edge and firefox it has no effect at all.

I wonder for one if it would make sense to remove the visually-hidden span at the end with the period in it (when tabbing it isn't announced, in the rotor it is inconsistent with the other links and with the virtual cursor it isn't adding any additional value just an extra announced text element inside of a link)?
and would it be an idea to add an aria-describedby to the links? in case the user is tabbing through the list of available content types to add the associated description would be announced automatically. i've manually added an aria-describedby attribute to the article content type in dev tools. it is announced correctly when tabbing through the page but it has to be noted for the virtual cursor if the user gets to the first link with the content type title the description isn't announced like with tabbing nor for any of the other text elements of the link. the description is announced afterwards when the user gets to it with the virtual cursor. so there wouldn't be any redundant information.

@markconroy nothing needs to be changed based on what I tagged. This was just for the ability to sort/organize the issues.

Tagging for tests also. But sounds like we are still working around the fix.