Expand the a11y nightwatch coverage in Core

Created on 22 January 2025, about 2 months ago

Problem/Motivation

Given that Nightwatch has been udpated to include axecore in the work done in ✨ Automate Accessibility Checks for Core Active
Resulting in: ✨ Automate Accessibility Checks for Core Active

It would be good to continue to cover the rest of the pages highlighted in phase 1:
✨ Automate Accessibility Checks for Core Active

Can we expand the coverage to test more pages and with a more expanded set of installed tools.

Currently:
core/profiles/tests/nightwatch_a11y_testing/nightwatch_a11y_testing.info.yml
core/modules/navigation/tests/src/Nightwatch/Tests/a11yTest.js
core/tests/Drupal/Nightwatch/Tests/a11yTestDefault.js
core/tests/Drupal/Nightwatch/Tests/a11yTestAdmin.js

Cover a minimal set of scenarios, what else should we be covering?

Should we expand the coverage?

These have already been suggested:

  • Home page - Done
  • Search
  • List View
  • Table View
  • Sample article content type
  • Sample blog content type
  • 404 page
  • Log in
  • Create new account
  • Reset your password
  • Admin - Content
  • Admin - Content: Add Article - Done
  • Admin - Content: Add Blog - Done
  • Admin - Structure - Done
  • Admin - Structure: Block layout
  • Admin - Structure: Create Content type - Done
  • Admin - Structure: Create Taxonomy - Done
  • Admin - Structure: Create View
  • Admin - Appearance
  • Admin - Appearance: Configure Olivero
  • Admin - Extend
  • Admin - Configuration
  • Admin - Configuration: Basic site settings
  • Admin - People
  • Admin - People: Add user
  • Admin - People: Permissions
  • Admin - Reports
  • Admin - Reports: Status report
  • Admin - Help
  • Admin - Help: Text editor

Can we also remove the colour contrast checker that has been disabled.

  // @todo remove the skipped rules below in https://drupal.org/i/3318394.
  {
    name: 'Structure | Block',
    path: '/admin/structure/block',
    options: {
      rules: {
        'color-contrast': { enabled: false },
        'duplicate-id-active': { enabled: false },
        region: { enabled: false },
      },
    },
  },
✨ Feature request
Status

Active

Version

11.1 πŸ”₯

Component

other

Created by

πŸ‡¬πŸ‡§United Kingdom the_g_bomb

Live updates comments and jobs are added and updated live.
  • Accessibility

    It affects the ability of people with disabilities or special needs (such as blindness or color-blindness) to use Drupal.

Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @the_g_bomb
  • πŸ‡¬πŸ‡§United Kingdom the_g_bomb

    Suggest first step is to use 'standard' install profile rather than the limited 'nightwatch_a11y_testing', even if we have to skip tests until the issues are fixed.

  • πŸ‡¬πŸ‡§United Kingdom the_g_bomb
  • Pipeline finished with Failed
    about 1 month ago
    Total: 96s
    #408509
  • Pipeline finished with Failed
    about 1 month ago
    Total: 89s
    #408521
  • Pipeline finished with Failed
    about 1 month ago
    Total: 7154s
    #408524
  • πŸ‡¬πŸ‡§United Kingdom the_g_bomb

    The failing test looks to the related to image resizing and maybe related to:
    https://www.drupal.org/project/drupal/issues/3484845 πŸ› [random test failure] ImageUrlProviderTest::testResize Active

  • πŸ‡¬πŸ‡§United Kingdom oily Greater London

    @the_g_bomb Grepping the core codebase I notice there are not apparently any existing usages of the 'standard' Nightwatch profile showing up. What is the 'standard' profile? Is that a configuration that has been standardised for Drupal? Or is it the default configuration profile that Nighwatch itself provides whether Nighwatch is being used on Drupal, Wordpress etc?

  • πŸ‡¬πŸ‡§United Kingdom the_g_bomb

    It is just the standard installation profile, so it sets the site up as everyone else sets it up. Wasn't aware that other tests don't use that, but I suspect that without doing that we won't check the accessibility of many tools included by default.
    If I can get this running, it may be worth setting up umami_demo as well.
    Basically it should just run the installer using the profile at:
    /profiles/standard

  • πŸ‡¬πŸ‡§United Kingdom oily Greater London

    #8 Yes I was confused. I thought it was a configuration profile for Nightwatch itself. But I suppose umami could be useful at some point. The article edit url seems fine especially since there is an existing url for the 'Page' node type that uses the same query param.

    Wondering if trying without the query param (I read something about the query param being required to POST the form?) which i think would just load the form? To try to isolate the cause: is it the query param in the url? I think the issue is currently isolated to the article edit url being added to the test. If we can isolate it to the query param that would be slight progress?

  • πŸ‡¬πŸ‡§United Kingdom oily Greater London

    #8 I notice that core.entity_view_display.node.article.default.yml version in Nightwatch profile contains core.entity_view_display.node.article.default.yml
    But it is not contained in the same file in standard profile. Havent looked at the umami version of the file yet.

  • Pipeline finished with Failed
    about 1 month ago
    Total: 559s
    #411936
  • πŸ‡¬πŸ‡§United Kingdom the_g_bomb

    Β―\_(ツ)_/Β― Sometimes the tests don't work until you retry them.

  • πŸ‡¬πŸ‡§United Kingdom oily Greater London

    @the_g_bomb I hate that when you go all around the houses. Life sucks sometimes : )

  • πŸ‡¬πŸ‡§United Kingdom the_g_bomb

    FYI, I think it would be a good idea to move the existing Nightwatch tests to either Playwright or PHPUnit as appropriate when they are available. Just keen to get the current tests working as optimally as possible in the meantime.

  • πŸ‡ΊπŸ‡ΈUnited States kentr Durango, CO

    FYI, there was some concern about using the standard profile when the nightwatch a11y tests were created: #3293469-23: Automated A11y tests in Nightwatch β†’

  • πŸ‡¬πŸ‡§United Kingdom the_g_bomb

    Yeah, I did think there would be a reason for using a slimmed-down profile, but then as the a11y tests are testing the user experience rather than specific functions or features, using a controlled environment might not test what users actually experience.

    In fact, there is a case that freshly installed Drupal may not have enough things in place to ensure everything is accessible. e.g. the homepage list of articles with pagination.

    To be honest, I suspect we may want each profile to have its own set of tests. I would love to see umami_demo and the drupal cms out-of-the-box experience covered by some a11y tests.

    Thanks for the feedback, looking forward to seeing how you get on with PHPUnit.

Production build 0.71.5 2024