Active page in menu for newsreader module

[seaneble]

Since sime time ago it is possible to use the news reader module

• without an /items/ parameter
• without a separate page directly as an option of the list module

The standard template nav_default.html5 uses a <span> element for active pages. Back in the days when the reader module was located on an arbitrary subpage, the menu item of the list page would have shown a link, not a <span>.
Nowadays, the menu item is a <span>, because technically one is indeed on the list page. Only a single part of the URI signals Contao it should display the appropriate news item. The navigation menu does not care.

A lot of people expect to be able to click the menu item to get back to the list view. But it is not clickable. I could of course change the standard template to always use a link, but normally I like it the way it is.

Could you change the behaviour of the navigation module to output links if the user is on the reader module of a news list setup?

[xchs]

+1

I have noticed that, too.

[leofeyer]

Technically, that would be wrong, wouldn't it? @contao/developers

[xchs]

To reproduce the issue in the Music Academy example website:

• Open the page "News"
• Open one of the news items from the "News archive" (e.g. "Associate Professor James Wilson returns")
• At this point one would expect to get back to the "News archive" by simply clicking again the "News" menu item from the main navigation but it does not work anymore due to the missing hyperlink

[aschempp]

Well, in Isotope we're actually adding a new page to the breadcrumb with the product name (instead of renaming the active page). See https://github.com/isotope/core/blob/master/system/modules/isotope/library/Isotope/Frontend.php#L596

[seaneble]

I think Leos question is quite on the mark: Technically, the visitor is indeed on the same instance of PageRegular or PageModel or whatever class it might be.

But, consider usability: The only native Contao way to get back to the list is the standard 'back' link, which is way down at the end of the news article, and only functional with activated javascript. So if you accidentally opened an article and want to go back, or for any users without JS, the two options are:

1. click anywhere in the menu and then on the 'news' page again OR
2. edit the URL manually

Both don't really make a website look too good in the eyes of the visitor. So I'd plead for usability over technical correctness.

[seaneble]

Small correction: This list module in this issue is actually the news archive module. But that doesn't change a thing.

[leofeyer]

Why don't we just add another nav_ template, which does not render the active menu item with a <span> element but an <a> element?

And while we are talking about this, is it still necessary to render the active menu item with a <span> at all? Can't we use an <a> element with rel="self" as well?

[aschempp]

Related to #6336

[frontendschlampe]

rel="self" is not allowed ... w3c says: Bad value self for attribute rel on element a: The string self is not a registered keyword.

Use <a> instead of <span> --> 👍

[leofeyer]

I see. Nevertheless, I have read some documentation now and most of the tutorials were not using a <span> or a <strong> element at all. They are simply using <a> tags without any further tag or reference.

@kikmedia What do you think?

[aschempp]

Maybe @NinaG can check about the accessibility?

[frontendschlampe]

👍

[kikmedia]

I think one should use an <a href="#">foobar</a> to get rid of the span. '_self' ist really a bad practice. Or did I get your question wrong?

[frontendschlampe]

@kikmedia 👍

[leofeyer]

Do you literally mean href="#" or can we also use the URL? Because # would not solve the initial problem.

[NinaG]

Zur Frage wegen der Reader-Seite:

Ich finde den Wunsch in diesem Fall sinnvoll, denn es geht nicht darum, was rein technisch basiert, sondern was der Nutzer erwartet. Der Nutzer hat auf einen Teaser-Link von News geklickt und ist auf der Detailseite dieser News gelandet. Dass er technisch immer noch auf derselben Seite ist, ist ihm weder bewusst noch ihm begreiflich zu machen (ist für ihn auch irrelevant). Entsprechend wird er erwarten, dass er bei einem Klick z.B. auf "News" in der Navigation wieder auf der News-Liste landet. Das geht in dem Fall nur, wenn Contao erkennt, dass es zwar dieselbe Seite ist, aber der Nutzer unterschiedliche Funktionalitäten je nach Zustand der Seite sieht.

Sowohl Usability als auch Barrierefreiheit sprechen hier imho klar für einen Link der News-Seite, wenn der Reader auf derselben Seite ist. Tatsächlich würde der Nutzer ja auch nicht wieder auf der Detailseite landen, wenn er ihn klickt, sondern eben auf der Listenansicht (wie er es erwartet). Gilt natürlich auch für vergleichbare andere Module, die so einen Effekt haben.

Generell zur Frage, ob man das nav_default so umstellen sollte, dass SPAN wieder doch A ist:

Ich seh nicht, dass die WCAG 2 plötzlich selbst-referierende Links (Links die auf die Seite zeigen, auf der man bereits ist) für gut befindet. Dazu z.B. das hier:

G128: Indicating current location within navigation bars
http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/G128
Example 3:
"When the link is activated to change the contents of the page, the selected link within the navigation bar is disabled since the result of following this link is the Web page currently being displayed."

Würden wir nun doch wieder in der Navigation die gerade aktive Seite mit einem Link versehen, wäre dieser Anspruch auf jeden Fall nicht mehr erfüllt. Man würde unerfahrene Nutzer irritieren, weil sie auf einen Link klicken und immer wieder denselben Content sehen, der bereits da ist. Ebenso natürlich Screenreader-Nutzer, Nutzer mit kognitiven Schwierigkeiten, etc.

Sprich: Ich bin dafür, weiterhin in der nav_default die gerade aktive Seite mit SPAN oder STRONG zu kennzeichnen um selbst-referenzierende Links zu vermeiden. Im Falle der benannten Ausnahme mit Reader-Modulen auf derselben Seite, sollte Contao das aber erkennen und die Seite als A in der Navigation erhalten, weil es für den Nutzer zwei unterschiedliche Seiten(inhalte) sind.

[Aybee]

💯 für strong

[felixpfeiffer]

+1 für die Ausführungen von Nina.

[MacKP]

Bin da ganz bei Nina.
Grüße

[seaneble]

As far as I understand, Ninas comment alignes perfectly with my initial request, so 👍

[leofeyer]

As far as I understand, Ninas comment alignes perfectly with my initial request

No, they don't. Nina is suggesting to keep the <span> (Contao 3) or <strong> (Contao 4) tag for the active menu item. Anything else she is suggesting is well true but technically not possible.

There is no way to reliably determine whether there are URL parameters that require to render an active link or not. Of course, we could go for the auto_item parameters, but that would be an incomplete solution. And anything else (except a full parameter whitelist) would leave us with a lot of false positives.

The interesting part would have been changing from <span> or <strong> back to <a>. This would have also solved a lot of CSS and JavaScript problems we are currently experiencing on touch devices.

But if it is breaking accessibility (is this really the case?), we cannot do it.

[discordier]

Just a thought but can't we simply check if the URL is pointing to the current page but we are having parameters in \Environment::get('request') and mark it trail then?

Like imagine the following:

URI	Page alias	Params	Css class for page	Used tag
/foo/bar/baz.html	foo	bar => baz	trail	a
/foo/baz.html	foo	auto_item => baz	trail	a
/foo.html	foo	-	active	span

We could go this way for ANY parameter IMO, as when the page should not be accessible without the "details" parameter, it wouldn't be included in the navigation anyway (marked "hide in menu").

Am I incorrect on this one? What am I missing?

[aschempp]

👍 but your comparison table does not consider the "hide in menu" option?

[leofeyer]

What am I missing?

You are missing that not every URL parameter automatically means that the page content is different. What if it e.g. is an affiliate ID such as /foo/affiliate/1234.html? That is effectively the same page content as /foo.html.

[tristanlins]

This can't be automated.
What about adding a checkbox to the page experts settings:
[ ] guess as trail if auto item is given ?

[discordier]

The problem is not limited to auto_item parameters. Therefore the checkbox should rather be "always link in menu".

[dmolineus]

There's an ongoing discussion to introduce a aria-current attribute to indicate the current page. http://www.w3.org/Search/Mail/Public/search?type-index=public-pfwg&index-type=t&keywords=aria-current&search=Search

This would not solve the issue how Contao can indicate if it's a current page or not but probably the coming recommodation to indicate the current page.

[felixpfeiffer]

The problem is not limited to auto_item parameters.

Well that's right. But a general checkbox would not be the right way. On the listig version on the page you don't want the a-tag, but the span/strong. Even on paginated versions of the listing, you don't want it.
But on the reader page.

As not everybody uses the auto-item parameter, you would have to make a checkbox "guess as trail for auto-item or the optional following URL parameter" and another textfield to define the optional get-parameter for the use without auto item.

And I am pretty sure, not every user can cope with that, so it's no good idea.

I think Leo is right. There is no good way to do that.

[leofeyer]

Therefore the checkbox should rather be "always link in menu".

This could be solved by simply adding another template (e.g. nav_link_all).

Just a thought but can't we simply check if the URL is pointing to the current page but we are having parameters in \Environment::get('request') and mark it trail then?

You are missing that not every URL parameter automatically means that the page content is different. What if it e.g. is an affiliate ID such as /foo/affiliate/1234.html? That is effectively the same page content as /foo.html.

Actually, if we would decide not to care about such edge cases, this idea would work.

[aschempp]

You are missing that not every URL parameter automatically means that the page content is different. What if it e.g. is an affiliate ID such as /foo/affiliate/1234.html? That is effectively the same page content as /foo.html.

Actually, if we would decide not to care about such edge cases, this idea would work.

I agree with that. Especially because that example should be a query parameter anyway ^^

[leofeyer]

Changed in 65029ec then.

[aschempp]

I feel like this is not the final version.

1. What about the valid use case example of @discordier (Active page in menu for newsreader module #7189 (comment))? If a page is hidden from menu, it should probably not have a link to the parent page.
2. Shouldn't the active page have at least a trail class?
3. There is no way in the template to distinguish between parameter-based "non-active" and real "non-active". So if I do want to have a <span> even with auto_item, I'm almost lost...

[leofeyer]

1. What about the valid use case example of @discordier (Active page in menu for newsreader module #7189 (comment))? If a page is hidden from menu, it should probably not have a link to the parent page.

What?

1. Shouldn't the active page have at least a trail class?

It does.

1. There is no way in the template to distinguish between parameter-based "non-active" and real "non-active". So if I do want to have a <span> even with auto_item, I'm almost lost...

That's true.

[aschempp]

What about the valid use case example of @discordier (#7189 (comment))? If a page is hidden from menu, it should probably not have a link to the parent page.

What?

If I create a special reader page for my news (instead of using the same page), I will likely hide it from navigation. In this case, I would not want the link to the real page. Also, that link would generate a 404 error by the news reader module.

[leofeyer]

I see. That is a valid point indeed.

[leofeyer]

Nope, it is not a valid point. I have just set up a test environment and if a page is hidden from the navigation menu, it will never show a link to the real page, because it is, well, hidden from the navigation menu :)

[aschempp]

lol, you're right, obviously it won't be in the menu then :D