🇬🇧United Kingdom @the_g_bomb

I am leaving this as draft purely to see how Experience builder pans out.

For Editoria11y to work optimally it should have an inline preview, which works well with Same Page Preview module.

If Experience builder is to land with similar functionality, then we will use that instead.

The question becomes do we add this to add that functionality and then replace it with Experience builder when it is ready?

the_g_bomb → created an issue.

Thanks for updating the target branch

the_g_bomb → created an issue.

the_g_bomb → created an issue.

the_g_bomb → created an issue.

Now that web_page_archive has been updated this should get past the composer installation steps as expected, using:
composer require 'drupal/accessibility_scanner:2.x-dev@dev'

You could add OPT_IN_TEST_NEXT_MAJOR=0 in the .gitlab-ci.yml file.
With openid_connect not being available for 11 as yet, it seems pointless to test that right now.

+1 to remove the dependency, but I agree it should be a new ticket. Would be good to get this merged.

After a very brief initial review of the results, I thought I would surface some of the information.

Commonly mentioned tools to test websites:

• Manual testing
• User testing
• Webaim Wave
• Google Lighthouse
• Deque AXE
• Tota11y
• SiteImprove
• Editoria11y
• Pa11y

Commonly mentioned Drupal accessibility modules:

• Editoria11y Accessibility Checker
• Tour →
• Same Page Preview →
• Block ARIA Landmark Roles →
• → Open Accessibility
• All in One Accessibility →
• Automatic Alternative Text →
• HTML Purifier →
• Tota11y →
• CKEditor Accessibility Checker →
• CKEditor Accessibility Auditor →

The spreadsheet has been populated with modules tagged on Drupal.org with Accessibility.
A second sheet contains modules with Accessibility or A11y in their name or description.
The modules have been categorised into a rough type of functionality they provide.
For modules that I have deemed to be tagged incorrectly, I have marked those as Not A11y in the Accessibility category column.

For consideration for addition to the Accessibility Tools track recipe I have exported the modules that were tagged as "Checker", "Checklist or Dashboards" and for reference those that have been marked as a "Toolbar".

I will be proposing that the Accessibility tools to be added will be from the Checker category to provide authors and editors with feedback to help guide them to producing accessible content. I also hope to find a dashboard-type module that can list issues found in a site scan that need to be addressed. This will help monitor the effort required by site owners and may also serve as an issue queue for authors and editors.

As mentioned in the MR.
I have opened an MR using the latest changes introduced by smustgrave in #21, but with the alternate regex supplied by codebymikey in #15.

I have yet not added the test coverage as requested in #27.

the_g_bomb → made their first commit to this issue’s fork.

Thank you to everyone who submitted a response.

The survey received 25 responses, which provided valuable insight into which tools people are using to improve and monitor the accessibility of their websites.

The information will go a long way in guiding our proposal

This is what AI generated, perhaps it could be cleaned up a bit.

I love it.

That being said, I have seen in this ticket where there are some examples of what other projects are diong and I do wonder if this would look very different to the style the other projects have gone with, however.
https://www.drupal.org/project/search_api_autocomplete/issues/3458912 📌 Project Browser: Create a logo for Search API Autocomplete Needs review

I'm right with you not being a graphic artist, so I'll keep an eye out for Paul Kidby and see if he has any events coming up, perhaps he would swap Drupal development hours for a commission... I say only half joking.

the_g_bomb → created an issue.

Done, thanks for the pointers.

the_g_bomb → made their first commit to this issue’s fork.

Sorry, I didn't remove D9 support as I didn't think it was in the scope of the ticket, happy to update.

Also didn't ignore your comment, I did a find and replace on "Symfony\Component\EventDispatcher\" to replace it with "Drupal\Component\EventDispatcher\".

I must have missed that it replaced both Symfony\Component\EventDispatcher\Event as well as the instances of Symfony\Component\EventDispatcher\EventDispatcherInterface;

The Interfaces have been reverted.

I also removed D9 support and found another issue which I also fixed.

Certainly makes sense. Rather than bikeshed the number have it set in the config, then it can be altered when the bots learn it position.

The above MR which makes weight configurable for D10+. It also adds an entry for the tour.

I did think it might be a clacks tower

Some modules in the following list should be tagged with the Accessibility tag, but currently do not have it applied:
https://www.drupal.org/project/project_module?f%5B0%5D=&f%5B1%5D=&f%5B2%... →
I think these modules should be added to the module analysis list.

the_g_bomb → created an issue.

I have replaced
use Symfony\Component\EventDispatcher\EventSubscriberInterface;
with
use Drupal\Component\EventDispatcher\EventSubscriberInterface;

Which should fix the issue you were facing @orkut-murat-yılmaz

Confirmed. I tried to get things in place, node etc to get the module fully working and ran into difficulties as well.

I have a fix in place locally and will push asap.

I suspect the fix I have in place may also fix: 🐛 Drupal 10 compatibility fixes Needs review

Opened https://git.drupalcode.org/project/web_page_archive/-/merge_requests/8 in 📌 Update dependencies for PHP 8.x support Needs work to fix D10 and PHP 8.x support

Opened https://git.drupalcode.org/project/web_page_archive/-/merge_requests/8 in 📌 Update dependencies for PHP 8.x support Needs work to fix D10 and PHP 8.x support

the_g_bomb → made their first commit to this issue’s fork.

Moving to the Drupal.org project ownership to request taking over the gnu_terry_pratchett module:
https://www.drupal.org/project/gnu_terry_pratchett → .

There are now 2 users willing to keep the module active, but the current maintainer is no longer responding to requests.

There was some movement not long ago, but the correct permissions were not granted to create and edit new releases.

Please could you add the correct permissions to both the_g_bomb and andyd328

Many thanks

Gareth

the_g_bomb → created an issue.

thejimbirch → credited the_g_bomb → .

I am not sure that removing the `role="img"` from svgs that do not also contain a title, necessarily make that module more accessible.

I suspect we may need to also remove the item from he screen readers output to avoid confusion.

Without a role img it may pass check for missing alt text, but it seems to me to be a workaround of the testing tool.

Perhaps a adding `aria-hidden="true"` would help. ref: https://www.unimelb.edu.au/accessibility/techniques/accessible-svgs

Reviving this issue as there will likely be more work involved to release a D11 version.

Happy to be added to the maintainers list.

Kristen Pol → credited the_g_bomb → .

Given that the site is installed using composer and there are a few composer requires listed in the setup instructions. Do you think the core patch should be applied using composer as well?

This set of commands could be given instead of the current commands.

ddev composer require cweagans/composer-patches:~1.0 --update-with-dependencies<br />
ddev composer config --json --merge extra.patches.drupal/core '{"3204271: Layout builder cannot recover on missing layout": "https://www.drupal.org/files/issues/2023-07-16/3204271-20-missing-layout-exception.patch"}'<br />
ddev composer updatedrupal/core<br />

This will ensure that composer installs, requires and updates to core won't updo the application of the patch.

Sorry it took so long

A new release has been pushed: 3.0.0

I have removed D10 support from the 8.x-2.x branch and created a 3.0.x branch to support the changes required by D10 only, such as the change required here.

FYI, I discovered a better way to remove the products and variations, so flagging 0 entities with kill is no longer needed to remove them

drush entity:delete commerce_product_variation --bundle=car
drush entity:delete commerce_product --bundle=car

the_g_bomb → created an issue.

Is that documented? Should it be? Can it be?

the_g_bomb → created an issue. See original summary → .

Confirming both the error and the solution.
Running:

./vendor/bin/phpunit 
PHP Fatal error:  Declaration of Drupal\Tests\sharethis\Functional\Views\SharethisViewsPluginTest::setUp($import_test_views = true): void must be compatible with Drupal\Tests\views\Functional\ViewTestBase::setUp($import_test_views = true, $modules = [...]): void in /var/www/html/web/modules/contrib/sharethis/tests/src/Functional/Views/SharethisViewsPluginTest.php on line 49

Fatal error: Declaration of Drupal\Tests\sharethis\Functional\Views\SharethisViewsPluginTest::setUp($import_test_views = true): void must be compatible with Drupal\Tests\views\Functional\ViewTestBase::setUp($import_test_views = true, $modules = [...]): void in /var/www/html/web/modules/contrib/sharethis/tests/src/Functional/Views/SharethisViewsPluginTest.php on line 49
Failed to run phpunit : exit status 255

Applied the patch to the module and phpunit was able to run.

Create a new PR as the other one looks to be open against the 8.x-1.x branch.

Made the alteration suggested by @ericgsmith

the_g_bomb → made their first commit to this issue’s fork.

I have applied the patch from gitlab using

composer config --json --merge extra.patches.drupal/core '{"#3454605: Roles should be in their own recipes for composability": "https://git.drupalcode.org/project/drupal/-/merge_requests/8413.diff"}'

I can see that the patch applies cleanly and makes the changes described.

I have also attempted to run:
php -d memory_limit=512M core/scripts/drupal install core/recipes/standard

Which completes as expected.

I haven't fully tested the patch in #24, but I can see there is a coding standard issue to address.

Thanks, as this is a D10 only requirement, I will make a new branch that only has the d10+ stuff in it.

Tested applying the patch. Applies cleanly.

Before patch Site Guardian loads and generates the API as expected.

After the Patch a button appears that allows the API key to be re-generated.

Very nice!

Added an MR to fix the issue, please use this patch if testing:
https://git.drupalcode.org/project/bootstrap_barrio/-/merge_requests/81....

the_g_bomb → created an issue.

Is there a documented way to exclude a form from being protected by honeypot? Could you point it out to me and I'll add an issue to the TFA module to get it added to that modules issue queue.

I have switched off protect all forms and can't see a way to explicitly exclude the TFA form. It might be good to have a setting to protect all forms except the tfa (or another) form.

The only way I can see to exclude it is to manually add the form id to the exported honeypot config yml file, or perhaps to switch off Protect all forms and then enable them all again in the fieldset that opens at that point.

I am keeping my fingers crossed that the config file I exported and edited doesn't get reverted the next time I export my config.

While I agree this approach is not scalable to exclude all modules that may need to be excluded, it was the reason behind my comment regarding needing a way to edit the list of unprotected forms. I know there is another issue in the queue to allow the user login form to be protected, which would also be solved by the config editing ability.

Happy to take advice on how this should be solved.

Attaching a change to the config yml file. Not sure that much else is needed.

This will enable on install and then be exported on drush cex, I suspect.

I do wonder if there should be a way to edit the list of unprotected forms, that was we could add or remove items as required.

As outlined in the change record for the removal of classy,
There are a couple of options:
Option 1: use the Classy contributed theme
Option 2: Remove your theme's dependency on Stable themes altogether
https://www.drupal.org/node/3305674 →

To use the contrib version, there will need to be a dependency of classy:classy added to the info.yml and possibly an addition of a require to a composer.json file, to make sure the classy theme is enabled when this theme is enabled.

To remove the dependency, the preprocess functions, twig templates and libraries will need to be moved from the classy theme to this theme, so the inheritance is no longer needed.

Just removing the base theme entry will result in missing functionality and styling as reported in #8.

That patch I just uploaded fails as the tests expect a field called url, which the patch changes to be url-{{random_number}}.

If that is the chosen solution, the test can be updated to proper look for something more appropriate.

My own personal vote is for the patch at #27, which sets the weight to 1 rather than the later patches which set the weight to -1.
I think the Title can be set in another issue.

The patch submitted in: https://www.drupal.org/project/seckit/issues/3193443#comment-15429382 📌 Avoid using document.write(' Needs review reports to fix a similar issue by setting the defer attribute as defer="defer" instead of just 'defer' for the seckit.frame_check.js file.

Is it worth checking if that has a positive effect here too? Perhaps if this is the correct approach the patch at the other ticket should fix the issue this way too.

@tenten71 Here is your patch, I added a description to the field as I think the text "Leave this field blank." should be attached somehow, otherwise if anyone does happen to see the field, they won't know to leave it blank.
Uploaded without prejudice, as I am not sure this should be changing the Title as it is.
Personally, I think this issue should be dealing with the weight, and perhaps #2726697: Configurable placeholder label → should be dealing with the title configuration.