#Accessibility

I have reviewed this issue, and it seems to have been resolved. I am attaching the screenshots for reference.

I have reviewed the changes. The fix is working as expected, due to the role attribute being successfully removed from the ul tags.

The test was performed on a Drupal 11.1.1 site.Attached some screenshots of the final markups.

Moving the issue to RTBC.

Certainly, that create article path looks wrong.

I have reviewed the changes which are made as requested and they looks good to me thus moving it to RTBC!!

There are some issues sneaking into Core that should have been caught by automated testing.

Some of these missed issues may be a result of the limited nightwatch_a11y_testing profile. A bunch of Axe errors appear when I use the modules from the standard profile.

I've been digging into it a little more before I create an issue.

RE #25, I found these test case URLs.

• "/"
• "/admin/content"
• "/admin/structure"
• "/admin/structure/block"
• "/admin/structure/taxonomy/add"
• "/admin/structure/types/add"
• "/node/add/page?destination=/admin/content"
• "/search/node"
• "/user/1/edit" (tested with and without the navigation module
• "/user/login"

In these files:

• a11yTestDefault.js
• a11yTestAdmin.js
• a11yTest.js

I'm wondering if there's an error in the admin tests.

{ name: 'Create Article', path: '/user/1/edit' },

Should perhaps be:

{ name: 'Create Article', path: '/node/add/article?destination=/admin/content' },

Thanks @dunx, I've gone through them and updated them variously. Several of them need more info (or for someone else who knows more about it to look at them!).

I'm seeing almost identical errors without this module, so these problems may be in core. I'm looking into it further and will file core issues if needed.

Four related issues (including this one):

1. https://www.drupal.org/project/drupal_cms/issues/3500771 🐛 Front-end Performance Suggestions (Via Google Lighthouse) Active
2. https://www.drupal.org/project/drupal_cms/issues/3479394 ✨ Add Google Lighthouse testing Active
3. https://www.drupal.org/project/drupal_cms/issues/3500770 📌 Aim For 100 in Google Lighthouse Scores Active
4. https://www.drupal.org/project/drupal_cms/issues/3481524 📌 CMS Benchmarking Active

Thanks @dunx. Converting to a meta.

Automatically closed - issue fixed for 2 weeks with no activity.

I've created 6 child issues with this as parent.

Point 1 https://www.drupal.org/project/drupal_cms/issues/3500930 🐛 Improve a11y of Drupal CMS installer - recipe checkbox contrats Active
Points 2 and 6 not raised as language selection no longer present.
Point 3 https://www.drupal.org/project/drupal_cms/issues/3500931 🐛 Improve a11y of Drupal CMS installer - focus clarity Active
Points 4 and 9 https://www.drupal.org/project/drupal_cms/issues/3500932 🐛 Improve a11y of Drupal CMS installer - missing focus Active
Point 5 https://www.drupal.org/project/drupal_cms/issues/3500935 🐛 Improve a11y of Drupal CMS installer - missing icons in high contrast Active
Point 7 https://www.drupal.org/project/drupal_cms/issues/3500933 🐛 Improve a11y of Drupal CMS installer - low contrast on buttons Active
Point 8 https://www.drupal.org/project/drupal_cms/issues/3500934 🐛 Improve a11y of Drupal CMS installer - buttons with poor focus Active

Hopefully I've included all the required info. I re-used the same images and alt text ;)

Rebased and all unit tests are green now. Marking as Needs review.

Thank you @HeikkiY. Changes look good to me.

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

The current implementation would need a review although the failing pipelines are a bit of mystery because they don't seem related to code changes in this issue. Perhaps the issue branch needs a rebase?

I did notice that the comment from #9 is not taken into account in the current implementation where it still uses aria-label and not aria-hidden. Instead of using the aria-label that the screen readers might ignore, we could perhaps also use the visually-hidden class with a span to add more context for screen readers or CSS content property.

Sorry for confusion, that is correct.

This is just default Olivero, the same is true for any instances of .button, e.g. the 'Apply' button on the blog view.

The default color is:
--color-text-primary-medium: var(--color--primary-40);

And on hover:
--color-text-primary-loud: var(--color--primary-30);

So there's hardly any difference. I'd probably lean toward trying to fix this in Olivero?

OK, I understand the confusion now :) You are talking about the tags in the node teaser. But that's not the problem. Drupal CMS does not output the tags in the card view mode. The tags field that is getting flagged is the one on the full page display.

Here is a summary of the current state:

1. In core, the markup works for the teaser view mode (which has an h2 for the title)
2. In Drupal CMS, the markup for the card view mode does not contain tags so is not an issue (we don't use teaser anywhere by default)
3. In core AND Drupal CMS, the current markup does not work for the full view mode, which jumps from h1 to h3 for the article page

Does this clarify things? The fix would require us to handle the tags field differently for the teaser and full view modes.

Actually, this could be fixed easily in Drupal CMS as there are no tags on the homepage. So an override in the drupal_cms_olivero would sort that one out, but I do think this needs to be fixed in core for articles. Unfortunately the page variable isn't available in the tags field template, so my current solution doesn't work.

Homepage

h1 page title
  - h2 node title
    - h3 tags
- h2 node title
    - h3 tags
- h2 node title
    - h3 tags

Article
h1 node title
  - h3 tags

Home in core has /node as the default homepage content, so h1 would be returned, which is fine.
h2 will (among others) be all the node titles and the tags should be h3 associated with the article node title. Technically everything is fine as it is for listing pages.

The problems currently appear on the article node pages. The node title is h1, and then the tags jump to h3.

Not only that, but please link them all here as related issues, so that we can turn this one into a meta. Thanks to whoever is willing to take that on!

@the_g_bomb this issue is for core only, we should handle any Drupal CMS exceptions separately.

Is this an improvement for core itself to make? I assume so, since it's using the same template. But if not, then we can close this and open CMS-only issues.

I don't follow. The home page would then go from h1 (once we re-add the title) to h3, isn't that the whole problem? Same for the listing pages, if we stick with h3 then it skips h2 on those pages.

Keeping the h3 on the homepage and listing pages would keep the tags hierarchically associated with the related h2 title, and so would be semantically better.

Could someone please split this out into actionable issues? Some of them should be fairly simple to address but they won't be all in one mega issue.

Thanks @rkoller. Installation is critical to adoption.

I see many changes in MH 13 that are not related to this issue
https://git.drupalcode.org/project/views_load_more/-/merge_requests/13.diff

How does 📌 Locate drupalisms that might create confusion among users Active fit into this 'discovery phase'?

Minor formatting/wording updates.

This is likely caused by the template your admin theme is using.

I found that I was able to resolve these issues by overriding the toolbar template. It was a bit tricky since I had to add a template suggestion to wrest control out of my admin theme's (Claro's) grip.

I put this in my .theme file:

function my_theme_theme_suggestions_toolbar_alter(array &$suggestions, array $variables) {
  // Add theme hook suggestions for toolbar so that we can override Claro. Otherwise, we just get Claro's template.
  if (!empty($variables['element']['#attributes']['id'])) {
    $suggestions[] = 'toolbar__' . str_replace('-', '_', $variables['element']['#attributes']['id']);
  }
}

Then I copied Claro's toolbar.html.twig into my theme as toolbar--toolbar-administration.html.twig.

In the twig file, I saw

{% for key, tab in tabs %}
   ...
    <nav class="toolbar-lining clearfix" role="navigation">
   ...
{% endfor %}

Which was causing trouble -- there's not a unique name on this element, which could be used several times. So I added an iterator:

{% set i = 0 %}
{% for key, tab in tabs %}
   ...
    <nav class="toolbar-lining clearfix" role="navigation" aria-label="admin-toolbar-nav-{{ i }}">
   ...
{% set i = i + 1 %}
{% endfor %}

For your second issue (which I also had), I added a landmark to wrap the whole toolbar. I haven't run this past any accessibility experts yet, but this does pass Axe's test:

<section id="toolbar-wrapper">
  <div{{ attributes.addClass('toolbar') }}>
    <nav{{ toolbar_attributes.addClass('toolbar-bar', 'clearfix') }}>
   ...
</section>

I hope this helps someone!

The div out of the a is required by assistive technologies like Voice Over for proper vocalization (tested on Safari and Chrome).

But this change could probably require some CSS tweaks I guess.

Attaching missing files in my previous comment!

I found the "Copied to Clipboard" message is not clearly displayed when the Copy button is clicked - the words overlap on top of each other. I guess this might be a related issue but this does not need the div out of a.

Attached is the screenshot and the patch fix!

We have tested #170 and confirm it is working for us on D10.3.9 and D10.4.1. Thanks everyone!

@asawari from the image it seemed like you tested the MR on issue page , not on local setup.

Test status -Fail
ARAI Issue is reproduceable. But , patch is showing an error.
Tested this using the tool -http://aka.ms/AccessibilityInsights on edit basic page.

Unfortunately automated checkers are looking for it and so we are shipping Drupal CMS with something that will be flagged as an error on all blog posts.

I'd certainly prefer to address this properly rather than just make the error go away by whatever means we can. So I still think changing it to an h2 is a better option and seems optimal as a change in core.

The fact that the Drupal CMS home page doesn't have an h1 seems like something to address separately, so I'll create an issue for that.

I'm not currently using this anywhere, but if we get a community-tested solution RTBC'd by enough people, I'm willing to merge a fix!

Facing the same issue with Drupal ~10.4

Thanks, moving over to Gin for the fix!

Just started a DrupalCMS trial on launch day and came looking for this exact issue. IMO there is way too much empty space in both the grid view and list view. If we are keeping the center alignment design, then here is a good implementation for center alignment tile design: https://docs.helpscout.com/

Suggestions

• Reduce min-width of list items in .pb-projects-list and .pb-projects-grid from 400px to 350px
• Shorten, center and increase font sizing of the project descriptions
• Increase font sizing of project title, make the link colour black
• Center the Install button and Installed checkmark

Some discussion about -ms-high-contrast over here too: https://www.drupal.org/project/drupal/issues/3327405 📌 Potentially remove -ms-high-contrast Needs work

@rkoller I tested the MR and I was able to see the autosave-form-save class in the DOM and also that the autosaving still works, as well as resuming from a draft or rejecting a draft.

Regarding the deprecation notice this was resolved with https://www.drupal.org/project/autosave_form/issues/3355495 🐛 PHP 8.2 deprecation issue with AutosaveFormBuilder Needs work some time ago.

I have merged the MR now.

Thanks for the link to the comment. I see where you are coming from and agree that on a personal level, skipping the heading may not have that great an impact.

Unfortunately automated checkers are looking for it and so we are shipping Drupal CMS with something that will be flagged as an error on all blog posts.

On the homepage, H2 won't work across the board as users using headings navigate will get all the tags marked as the same importance as the headings rather than as a child of the article. Those tags without the context of which article it refers to, will be meaningless.

The other option would be to add a if page check to the template and use h3 on lists like the homepage, and h2 on the article itself.

I think there are a couple of issue which are related to the styling in particular to gin theme.@ phenaproxima. suggested a better way to solve a problem for styling in Change UI for the install queue to match bulk operations 📌 Change UI for the install queue to match bulk operations Active issue's
this comment. 📌 Change UI for the install queue to match bulk operations Active .
We can have discuss and come up with a solution so that all the styling issues can be solved using a finalised approach.

Based on the discussion in #3333401-30: Pager h4 causes accessibility flag on many pages → it should be a heading. That comment also suggests it doesn't matter that much whether the headings increase by one.

But I guess h2 would work in all cases pretty much. I'm a bit confused though because the last comment says it's changed to a span but the MR has a div.

Div it is

the commit you've referenced is about something else, probably the commit was fixing #3458844-33: Improve keyboard navigation/general a11y for categories dropdown → , but the problem this issue is about is still relevant, otherwise i wouldnt have opened the followup. the issue got raised in #3458844-36: Improve keyboard navigation/general a11y for categories dropdown → . i've rested, and the problem persists with voiceover active in safari, edge and firefox on macos. as outlined in the issue summary and the acompanying video. simply activate voiceover, expand the multiselect. first navigate by the arrow down key one or two entries down then use VO-arrow left (VO = ctrl and option) and step back to the beginning of the multiselect dialog. and as you can see in the video the voiceover cursor steps outside the dialog and focuses elements outside the dialog that are located before the dilalog in the DOM. if you then press arrow down the voiceovercursor literally jumps back inside the dialog. the dialog remains open all the time. if you now scroll further down the dialog with the arrow down key and one or two entries before the end use the VO-arrow right button, now. the VO cursor is also reaching outside the dialog, but here the dialog immediatly collapses.

Wonder if it actually should be Div. That’s what the comment field label seems to do at least

I changed it to an h2, which works for the node page in terms of hierarchy but it doesn't work for the home page where the node__title is an h2.
I have changed it to be span.

I've tested the MR tonight. With the feature branch checked out the autosave button seems to be hidden and is not visible to sighted users nor screenreader users, but if i search for the class autosave-form-save in the web inspector i have no matches at all on the entire node edit form. so it seems like the autosave button isn't available at the moment? cuz there is also a deprecation error shown:

Deprecated function: Creation of dynamic property Drupal\autosave_form\Form\AutosaveFormBuilder::$_serviceId is deprecated in Drupal\Component\DependencyInjection\Container->createService() (line 285 of /var/www/html/repos/drupal/core/lib/Drupal/Component/DependencyInjection/Container.php).
Drupal\Component\DependencyInjection\Container->createService() (Line: 177)
Drupal\Component\DependencyInjection\Container->get() (Line: 430)
Drupal\Component\DependencyInjection\Container->resolveServicesAndParameters() (Line: 237)
Drupal\Component\DependencyInjection\Container->createService() (Line: 445)
Drupal\Component\DependencyInjection\Container->resolveServicesAndParameters() (Line: 237)
Drupal\Component\DependencyInjection\Container->createService() (Line: 177)
Drupal\Component\DependencyInjection\Container->get() (Line: 28)
Drupal\Core\DependencyInjection\ClassResolver->getInstanceFromDefinition() (Line: 100)
Drupal\Core\Utility\CallableResolver->getCallableFromDefinition() (Line: 34)
Drupal\Core\Controller\ControllerResolver->getControllerFromDefinition() (Line: 49)
Drupal\Core\Controller\ControllerResolver->getController() (Line: 166)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle() (Line: 116)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 90)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 709)
Drupal\Core\DrupalKernel->handle() (Line: 19)

tested on ddev on drupal 11.x and php 8.3. I'll set the issue back to needs work

Solution doesn't appear to match suggestions. Seems this was added part of Oliveros POC https://git.drupalcode.org/project/olivero/-/commit/4e21276137f151bfdd02... way back when.

That said not sure p tag is correct. Would vote for div, span, or a different header.

Realizing now it would be moving this the governance project, and not the documentation component of Drupal core. Will mention to the working group.

I've updated the description with more detail. Apologies for the description, we were working quickly to scaffold out issues during a working group meeting yesterday.

We have the issue in the documentation component since we are working to create and document a process for this work. If the governance component is more appropriate, we would need help to make that change, as governance isn't an option for me in the component dropdown.