Allow global tokens (and therefore page numbers) in display title

To be clear, if we allow the title area handle to be used everywhere, all this is already possible.

On the other hand I think maybe for the frontpage view we could set it by default, on the other hand I don't think we should assume anything the way how people build
their site, so the default for new views should not be filled with all kind of stuff.

That's it? Will have to find time to test it out. What is the best way to test this?

Ok. Think this is something we can do within 8.0?

Well yes, default views could provide that, but at the same time, I don't think it would be a good idea to enforce it.

Well, you could make an advanced option on the title area handler, which also allows you to set the title different for the first page, for example.

@dawehner - I don't see how appending the page number is anything but a best practice for everyone. Why wouldn't it be a good idea to know where you are midway in a view of 1000 pages?

It isn't how Google does it, but really can't see much argument opposed to it other than that.... Mind you Google has very mixed results on accessibility and don't think is striving for WCAG 2.0 AA.

I'm fine with adjusting the patch to see that this can be disabled through the UI and that the first page or initial text (can be customized). I think that the default should be to include the page number in the title though.

The closest I could find for pagination for this in WCAG is:
http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-title.html

But this is a requirement for WCAG 2.0 A which is below our requirements. This might well be a bug rather than a feature. @DuaelFr thoughts on this?

The goal of Drupal 8 is to be WCAG 2.0 AA. If it isn't, it can be considered a bug. How important we prioritize that is another issue. Just because it's an accessibility bug doesn't mean that it is a blocker though.

I am a core maintainer, but certainly appreciate input from folks like @dawehner who know this module so much more.

Having a tolken like @DuaelFr described in #9 would be ideal. I've just thrown this together quickly with what I think we are looking for:

The pagination should be in the title by default but easily removed.

Investigating the idea of a [page_number] token for use in area handlers.

Turns out we already have [view:current-page] and [view:page-count] tokens, though the page-count token is incorrect: #2572355: Some view tokens ([view:page-count] and [view:total-rows]) are incorrect.

Now looking into what it takes to get those tokens to render for the title field.

Attached patch allows global tokens in the display title.

Self review:

1. +++ b/core/modules/views/src/ViewExecutable.php
   @@ -1710,6 +1710,9 @@ public function getTitle() {
   +    $title = $this->display_handler->globalTokenReplace($title);
   

   We're not passing a langcode in the $options argument to globalTokenReplace(). Is that bad? Or is that only to override the default langcode?

   Would love to hear from i18n folks on this.

2. +++ b/core/modules/views/views.views.inc
   @@ -75,7 +75,6 @@ function views_views_data() {
   -      'sub_type' => 'empty',
   

   Can someone explain this to me? It came up in #4 so I left it in... But if it just allows the title handler to be used in other "area" spots (header, footer, etc.) that won't help us in this case because the view title is (somewhat oddly) rendered in the ViewExecutable object rather than the display handler and isn't an "area".

I can't answer #17.1 or #17.2, but did test out the patch in #16 and it didn't change the defaults or the help text associated with the title element.

I could add in the existing page here:

Unfortunately I don't think we want the output to the page to be the same as the title of the page. So the results here:

You don't actually want to change the text out of the header. It would also be nice if the "Page #" were just a translated string that was available as a token rather than the raw page number.

And it doesn't treat the first page as special if you want to define it as " - Page #"

Hope this helps. It's moving along for sure.

I think we're going to have to address this in 8.1.

Re-rolled.

+++ b/core/modules/views/src/ViewExecutable.php
@@ -1828,6 +1828,9 @@ public function getTitle() {
+    // Allow global token substitutions

Comments should (noramlly) begin with a capital letter and end with a full stop / period .

Fixed and attached new patch.

Adds tests.

Addressing #18 would require extensive work, probably allowing to configure the page title separate from the view header.

I suggest it should be punted to a separate issue (or this patch moved to a separate issue), because what we have here is a ready-to-go, simple, effective enhancement. The current patch enables tokens in the title area, which before wasn't possible. It's a solid step forward.

Regarding #17.1 I notice that the LinkFormatter has
$link_title = \Drupal::token()->replace($item->title, [$entity->getEntityTypeId() => $entity], ['clear' => TRUE]);
i.e. it doesn't set an explicit langcode. There are not many examples of this in core to go by.

The langcode seems to be used by modules implementing hook_tookens. In core they tend to use a pattern like

  if (isset($options['langcode'])) {
    $url_options['language'] = \Drupal::languageManager()->getLanguage($options['langcode']);
    $langcode = $options['langcode'];
  }
  else {
    $langcode = NULL;
  }

or

  if (isset($options['langcode'])) {
    $url_options['language'] = \Drupal::languageManager()->getLanguage($options['langcode']);
    $langcode = $options['langcode'];
  }
  else {
    $langcode = LanguageInterface::LANGCODE_DEFAULT;
  }

So it looks like the langcode is optional and will tend to default sanely if omitted.

@jonathanshaw, thank you for the review and for providing feedback on #17.1. From what you're saying it sounds like it's fine that this code does not provide a langcode.

Addressing #18 would require extensive work, probably allowing to configure the page title separate from the view header.

Agreed. And I believe this can be handled by the Metatag module, at least the part about the title tag being different from the h1 page title.

Apart from the tests a small patch that still applies cleanly on 8.7.x-dev and works as advertised.

IMHO a feature request, as the optional header already supports global tokens which for accessibility is sufficient.
Still a nice improvement.

We might want to add plural support as well, similar to #2888320: Add support for Token and plural in Views Global result summary plugin. We can do that in a followup, however.
If 8.7.x tests are passing this should be RTBC.

#9:
I agree with this. Putting the page number in the <title> is highly desirable.
It's definitely worth updating the default views config, for new installs, but we can leave existing sites alone. That can be deferred to a follow-up issue if needs be.

#11:

More specifically than WCAG success criterion 2.4.2 Page Titled at level A, there is SC 2.4.8 Location at level AAA. This is certainly something we can treat as level-A though; some level-AAA criteria are really just refinements of a more general concept at level-A.

A relevant WCAG technique is G127: Identifying a Web page's relationship to a larger collection of Web pages. This is close to the example 3 there (chapters of a textbook).

#28-29:
These suggest a follow-up should be filed for #18, to allow the visible heading and <title> to differ, so this should be filed before RTBC.

#33:

IMHO a feature request, as the optional header already supports global tokens which for accessibility is sufficient.

I don't really follow what this means. The issue title says it's about allowing global tokens, but #33 says it already supports global tokens.

This could do with an issue summary update, about what is actually being changed here. In particular, the word "title" is ambiguous, as some comments are talking about the (visible) view title plugin, but it's clear that @DuaelFr is talking about the HTML <title> element. I think these are tightly coupled at present?

Linking open issues from the CivicActions Accessibility - VPAT.

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

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

Rerolled patch 2509716-tokens-in-page-title.patch from #26 against 10.1.x and updated test.

Was previously tagged for issue summary update and follow up which still appear to need and happen.

Also if there is a UX change before/after screenshots will be needed