fix: #3622825 Webform pages render no page title, so form routes have no h1

Rajab Natshahrequested to merge
issue/vartheme_bs5_educare-3622825:3622825-webform-pages-render into 1.0.x

Fixes #3622825.

What this changes

A webform served on its own route at /form/{webform} rendered with no heading. The browser tab carried the right title, but the page opened straight onto the first field, leaving a screen reader with no h1 to land on and the visitor with no statement of what the form is for.

Before:

/form/business-contact  ->  200, document.querySelector('h1') === null
/form/contact           ->  200, document.querySelector('h1') === null
/user/login             ->  200, h1 "Log in"
/search                 ->  200, h1 "Search"

The cause is that the theme never rendered a page title for any route. The page component outputs the Canvas regions and nothing else, and the theme registers no block layout blocks, because Drupal Canvas owns page rendering. The routes that do show a heading, such as user login, carry their own page template and render it themselves.

How

templates/page/page--webform.html.twig plus a page-webform component, following the pattern this theme already uses for the user routes, rather than adding a title to the shared page component, which would put a duplicate heading on every Canvas page.

hook_preprocess_page() hands the title down from the route, and skips it when the form already supplies an h1 in a markup element:

$webform = \Drupal::routeMatch()->getParameter('webform');
if ($webform instanceof WebformInterface) {
  if (!_vartheme_bs5_educare_webform_has_own_heading($webform)) {
    $variables['page_title_for_webform'] = $webform->label();
  }
}

That guard is the point of the design. It means this MR is safe to land on its own, in either order, alongside varbase_webform_base #3622822, which gives the Newsletter Subscribe form its own markup header containing an h1. Without the guard the two together would produce two h1 elements on /form/newsletter-subscribe.

Verification

Anonymous, on a Educare site with both changes present:

Route h1 count h1 source
/form/business-contact 1 Business Contact route
/form/contact 1 Contact route
/form/newsletter-subscribe 1 Newsletter Subscribe route

No regression anywhere else: /, /contact-us and /about each still have exactly one h1.

The guard is demonstrated in both directions across the two themes. On this site the Newsletter Subscribe form has no markup header, so its heading comes from the route. On a Horizon Aid site that already has varbase_webform_base #3622822 applied, the same route yields exactly one h1 too, that one coming from the form's own header rather than the route.

php -l clean, use statements in alphabetical order.

Checkpoints:

  • File an issue
  • Addition/Change/Update/Fix
  • Testing to ensure no regression
  • Automated unit testing coverage
  • Automated functional testing coverage
  • UX/UI designer responsibilities
  • Readability
  • Accessibility
  • Performance
  • Security
  • Developer Documentation
  • User Guide Documentation
  • Reviewed by human
  • Code review by maintainers
  • Full testing and approval
  • Credit contributors
  • Review with the product owner
  • Release notes snippet
  • Release

AI-Generated: Yes

Merge request reports