Add a dashboard to the Accessibility Tools recipe

There are no real technical problems here, but the dependencies on core recipes pose some issues that you didn't cause, but we still have to figure out, before I can commit this.

I'll give it a blast to make the change requested. I was trying to follow the style of the SEO Dashboard, so I think the Full HTML is possibly only to allow the addition of a class to the a tag. If I alter the existing Basic HTML filter to add the class attribute to the allowed list. That would remove the need for the use of Full HTML.

I removed the dependency on the image format, it wasn't needed.
I also changed the full_html dependency to the existing easy_email and it hasn't got the "Limit allowed HTML tags" which removed the needed class.

Seems reasonable but we should not be relying on the easy_email format. It's for emails.

Looks good to me from a code perspective; assigning to @pameeela for final review.

I'm quite hesitant to add another dashboard that really only contains links, and I need to run this by the UX team.

Separately the text format issue is a real problem! Definitely don't want to add basic_html for blocks on a dashboard, and now I see that Full HTML was added back for a different dashboard..... yikes.

Happy to park this. The intention is to have a content view here, which will show accessibility issues with a users content. But the module that provides that isn't in existence yet, so I can re-address this when the view is available.

@the_g_bomb yes basically I think that's what we should do, wait until we have the content view.

But I also think this might be suitable to add to the main dashboard, rather than having a separate one for that.

Once ✨ Provide a Config Action to add/edit a component in a layout Active lands, the recipe could just add a block to the welcome dashboard.

For that instead of a list of links, we decided to use menus in 📌 Define how wireframes links block on the right should be created Active . Probably we want to use the same here.
This depends on ✨ Render menus as a list of CTAs Active landing on the dashboard module. This will create a stacked vertical list of links, not sure if you intended this to be horizontal.

That will be implemented for the creation actions in 📌 Provide a "Dashboard CTA" menu for the content creation CTAs Active (no MR yet, sorry)

FYI, There is now a way to create a list of content and display the A11y issues status, so I may like to bring this out of postponment if there is still appetite for an A11y related block on a Dashboard.

At first thoughts I would wonder how that would be applied to an existing dashboard. Does the recipe need to know where on Dashboard it is going to be applied, given that the Accessibility Tools are an optional recipe and will likely be enabled after everything else has been setup.

This change record has details on the config action you would use to add it.

https://www.drupal.org/node/3519491 →

I'm happy to pull this out of postponement. We'd need to do additional refactoring to move the dashboard into another module (maybe drupal_cms_admin_ui, so that drupal_cms_accessibility_tools could depend on it) but that could all happen in this issue's scope. For now, implement it in whatever way gets it looking and working how you want. I can assist with the refactoring.

the_g_bomb → closed merge request !177

the_g_bomb → changed the visibility of the branch 3485831- to hidden.

the_g_bomb → changed the visibility of the branch 0.x to hidden.

the_g_bomb → changed the visibility of the branch 2.x to hidden.

Thanks for the pointer @thejimbirch. Nice and straightforward.
The only bit I wasn't clear on was how to determine the position.
Is that used instead of weight? (I noted it says weight will be automatically calculated)
What happens if another recipe chooses the same position?

That looks like a good start but it's missing a dependency and it needs light test coverage.

The dependency changes look right but the test should approach the dashboard from a functional end-user perspective. :)

I tried this out and I think it could be better. Here's what I see in the dashboard after applying the recipe (in the Tugboat preview):

If I was a content author or editor, I would have no idea what this meant or what it was doing there. The lowercasing of "url" looks unprofessional (and is a technical word anyway). The button is unreadable. There's nothing in the block, and no explanatory text. Clicking the button brings me to an equally inscrutable page.

I'll commit this if @pameeela feels it would be beneficial, but I'm not sure we should release this in its current state.

Thank you for the screenshot @phenaproxima! Agree this is not commit-able in its current state, but to be fair it would probably be good to provide some specific advice.

But I think this also needs an IS update because the current proposal is to add a block to the existing dashboard. @the_g_bomb are you able to update it with a description of how this block works and what it is intended to provide to the user?

This is an upstream issue from Editoria11y. I'll open a ticket to amend the block titles and make them more usable.

This is essentially the out-of-the-box "No results behavior"

This block shows the issues discovered by Editoria11y. When you first install it, as there are no issues discovered yet, you need to browse the site to make this useful.

If you visit the demo page at: /accessibility-tools-demo-page. Then revisit the dashboard, you should see that block gets populated with a list of some of the issues found. The header also changes to say "Recent issues", and there is a "more link" to a more detailed list page.

I have updated the recipe. I suspect a different block may be a better choice for this on further investigation. I have also updated the recipe so that the dashboard now overrides the title to be more useful.

I then updated the test to use the new title to identify if the block is being placed in the dashboard rather than testing if the config is being updated, as requested.

I was struggling to identify the block as stark doesn't output the classes as expected in the test, but also I thought the title may be a bit brittle to use as a test, as it is being provided by a third-party module, and may change if the module updates at any point leading to a broken test, overriding the title means that should always be available.

I like that a lot better. I'd love to see Editoria11y merge some "no results found" text into their view, as I agree that the lack of any text at all is totally unclear. I wonder if there's a class we could add to the button which would allow it to become readable?

It might be possible to do this stuff in the view without waiting on upstream, if we can figure out exactly which switches to pull in the dense jungle that is Views configuration.

Not sure if it messes things up in the module but for our purposes, it would be better if the link was styled to match the block above, not as a button.

Screenshot:

Just looking at the view config. I don't think that a title override is the right behaviour for no results -- I think the title should stay the same, but with a message in the view explaining that either there are no issues or pages need to be viewed in order to show results.

Also the button to view all should not appear if there are no results. Is this feedback better against the module rather than here? I don't think these are Drupal CMS overrides, IMO this should be the default behaviour.

Thanks Pamela. The title override for the no results is an issue with the module. I have opened a couple of issues already, and plan to open a couple more, so hopefully that specifically can be fixed.

I have our own title override in place for the dashboard, so it shouldn't matter what happens to the view, if the module is updated, the title of this block will always remain as "Pages with accessibility alerts". I can change the text used there if required, but it also adds some stability for the recipe test that is in place.

In terms of the button colour, I 100% agree that needs to be sorted. I'll look into where that is coming from. I thought the view was just using the standard More link, so it may be an issue with the Drupal CMS CSS, but I'll investigate and add changes here or in the module as appropriate.

@the_g_bomb ahh sorry, I always forget about the 'More' link, I didn't even think about it being that. How strange that this link is getting button classes added but the other one isn't.

The button comes from here:
https://git.drupalcode.org/project/editoria11y/-/blob/2.2.x/editoria11y....

I have duplicated the reports block to override various bits as requested.
e.g.: here is the new "No results message":

And the listings with a link to the Editoria11y reports page.