This is even less reliable. Other components may use different input variables.

@SharkyKZ can you provide an example where option and view are not present?

Option is always present. But view and ID not necessarily. And many other variables can be used in a menu link.

Back to the drawing board and find a way to differ a category blog from an article.
I will try to make it more general.

Also don't forget that you can have multiple menu items point to the same page. Using query variables is not good in that case. Multiple menu items would be marked as active.

correct me if I'm wrong.. if the currently merged solution aria-current="page" is open for improvement, so is the existing code which adds a the class current. Is that piece of code open for improvement too?

If so... we have to extend the MenuHelper with a function that finds out if the menu item is indeed the current page. And not only for an opened item in category blog, also for other components.

Everything is open for improvement!

As I stated in the other pr you are trying to resolve the exact same issue as the display of modules on non-parent items. So if you can resolve this it will be appreciated by many. Even if it removes some of the use cases for "advanced module manager"

correct me if I'm wrong.. if the currently merged solution aria-current="page" is open for improvement, so is the existing code which adds a the class current. Is that piece of code open for improvement too?

joomla-cms/modules/mod_menu/tmpl/default.php

Lines 38 to 41 in 5a7ff7d

	if ($item->id == $active_id || ($item->type === 'alias' && $itemParams->get('aliasoptions') == $active_id))
	{
	$class .= ' current';
	}

If so... we have to extend the MenuHelper with a function that finds out if the menu item is indeed the current page. And not only for an opened item in category blog, also for other components.

The current class does not the same then the aria-current="page" expect, our current class is used for the most specific menu entry but doesn't care if you have a complete shop system under this link.

I'm not even sure if you find the correct menu entry by comparing all input variables.

The other way could be a bit more "secure" check if additional parameters are set and only set aria-current if no other input-var is set, but in theory you page can have another content based on your session or on a cookie.

I didn't see the discussion in the other PR before.

If the idea is to mark only the exact page defined in the menu item and not any child pages, you could probably get all input variables (minus some system ones like Itemid) and compare them against menu item query.

I didn't see the discussion in the other PR before.

If the idea is to mark only the exact page defined in the menu item and not any child pages, you could probably get all input variables (minus some system ones like Itemid) and compare them against menu item query.

that's maybe (hopefully) true for core but you can't say this for 3rd party extensions they maybe include other (from another source we don't know) to decide which page is displayed. I'm not sure if it's better to display none or a wrong one.

Changed the implementation by replacing the comparison.
First implementation compared parameters option, view and id.
New implementation walks through each Factory::getApplication()->getInput()->get($key) and compares it with the equal named $key from $item->query.

Tested with all Joomla 4 Sample data installed.
see: https://github.com/joomla/joomla-cms/pull/29369/files

I would suggest to use array_diff_assoc instead of looping over the query array

Updated PR with newly changes pulled from branch 4.0 dev

@HLeithner

I would suggest to use array_diff_assoc instead of looping over the query array

Would have chosen that option too if I could reach the content of the protected data from Factory::getApplication()->getInput()

@SharkyKZ @HLeithner please review my improved PR.

As explained there are more ways to decide if a link to the page is the current page or not and $_GET is not everything.

@hans2103 Sorry if I'm wrong because I am not very deep into that subject. But as a quick reader, to me what you try to do here reads as if you wanted to implement the router again just at another place.

As explained there are more ways to decide if a link to the page is the current page or not and $_GET is not everything.

@HLeithner feel free to make a PR on my suggestion. I would love to learn from it.

I think it's not possible for the Joomla! cms to provide 100% accurate data and I personally would prefer not to set wrong value. If someone want's this he/she can use a simple template override for the mod_menu.

@HLeithner how can we improve J4 so we can provide 100% accurate data?
It would be great to provide this with J4 out of the box, not with a simple template override.

If we cannot implement it now, I am afraid that it will have to wait until J5.

The Joomla Accessibility Statements tells us we are committed to being accessible to the widest possible audience, regardless of ability or technology.
https://www.joomla.org/accessibility-statement.html

Due the nature of the CMS which is extensible by 3rd party developers I don't see a chance to make this 100% accurate ymmv.

But another question what's the benefit of this link? I mean which group of people have a benefit of this?
And you would like to deliver a wrong solution then non solution (we already have some of wrong solution that block joomla enhancement since 1.0 or so)

Due the nature of the CMS which is extensible by 3rd party developers I don't see a chance to make this 100% accurate ymmv.

The solution in the PR covers this issue by comparing the parameters. If any parameter don't match, the aria-current="page" will not be set.
And it is not wrong if 3th party developers code more in the direction of Joomla coding standards. (wishful thinking... I know)

But another question what's the benefit of this link? I mean which group of people have a benefit of this?

This question is irrelevant due to the first couple of sentences of https://www.joomla.org/accessibility-statement.html

And you would like to deliver a wrong solution then non solution

I would like not to. But I haven't stumbled upon a situation where my proposed solution fails. Please provide me with such a situation and I try to solve it.

(we already have some of wrong solution that block joomla enhancement since 1.0 or so)

Create PR to solve them one by one... start mentioning them in new issues.

But another question what's the benefit of this link? I mean which group of people have a benefit of this?

This question is irrelevant due to the first couple of sentences of https://www.joomla.org/accessibility-statement.html

Sorry but why is a question I have personally is irrelevant?

But another question what's the benefit of this link? I mean which group of people have a benefit of this?

This question is irrelevant due to the first couple of sentences of https://www.joomla.org/accessibility-statement.html

Sorry but why is a question I have personally is irrelevant?

Sorry... I have no means to offend you and let me answer your question.
This addition to the menu item will benefit accessibility of the website.
And accessibility improvements come with baby steps. This PR is one of the baby steps I try to achieve.

The idea that web accessibility only benefits people with disabilities is one of the most common web accessibility myths. (source: https://www.boia.org/blog/common-web-accessibility-myths)

6 Unexpected Benefits of Web Accessibility (source: https://www.boia.org/blog/6-unexpected-benefits-of-web-accessibility)

Adding this is definitely an important improvement for accessibility.

Is there a negative impact by having this attribute on a parent page when we are on a child page? I have no idea. It would be good if the Accessibility team actually spoke up on this issue. No point in having the team if they don't do anything ;)

@hans2103 your answer was no answer, I know why we do a11y I wanted to know what's the benefit is from exactly this attribute but I think I found it my self at the meantime.

Anyway there are so many situations where this entry could be false like one-pagers, ajax-updated content, SPA, Paging and search saved parameter saved in cookies or session data and so on.

Actually that is correct and is not miss leading people who really needs this information. I have the feeling that you think it's better if it's wrong then it's missing. So I'm out here the @joomla/joomla-accessibility-team-jat should say what to do.

Beside that I think it's wrong thanks for you contribution.

The aria-current="page" is not required and no success criterion for any requirement. So it can be set and might be useful IF the value is always reliable.
Aria labels should not be used as self-purpose.
If @HLeithner says that the values are not 100% reliable, it is better to leave it.

Although aria-current="page" is not required and no success criterion for any requirement, it is already implemented. This PR tries to make it more reliable.

if the values are not 100% reliable, it is better to leave it.

@chmst my PR adds a check to compares the parameters of the application input with the query of the menu item. If it fails, the attribute will not set.

@HLeithner would it be an idea if a config item is added where you can toggle this attribute
Apply aria-current="page"? YES / NO (default)
This option will conditional add the attribute aria-current to the menu item which indicates the current page.

I'm trying to understand this discussion and I really don't understand what problem is being solved.
Do you mean that e.g. a link points to a category, because the menu item is a category blog and theand the viewed page (current page) is some kind of a blog article that does not have its specific position in the menu system?
A menu item is not the same as a link to a page. One current menu item can be the current item for multiple pages. Distinguishing a menu item with CSS and showing the screen readers with aria-current is exactly the same.
You write that currently when I'm on a blog article page, the menu item has aria-current. You think that the menu item at this point should not have aria-current attribute, because it's not a category page, it's a subpage, your thinking is wrong.
The aria-current attribute is used when an element within a set of related elements is visually styled to indicate it is the current item in the set.
At this time, when I'm on a blog article page, the visual styling indicates an item like Category blog in the menu, because the item for each article is not on the menu at all. Therefore this stylized item should also have aria-curent=page (or aria-current=location if you want to be very precise). Removing aria-current from a menu item is not a good solution. Because there is no indication for people using assistive technology which menu item is current. When you have a menu, there is always one menu item that is current.
But maybe I don't understand something.
In my opinion, the current aria-current implementation in menu is sufficient. Nothing here needs to be improved.

I have tested this item ✅ successfully on 44f84dd

I see there is discussion as to its merits but the patch does do as it says it should in the test so its a successful test

I have tested this item ✅ successfully on 44f84dd

I see there is discussion as to its merits but the patch does do as it says it should in the test so its a successful test

Please read https://tink.uk/using-the-aria-current-attribute/ and the comments. Specifically
"you’d only use aria-current on the link representing the currently selected page."

The article without a menu item accessed from a blog category would therefore mean that the menu link for the blog category is not aria-current

@brianteeman : I know that article. And I know the comment. But the question that Leonie Watson answered was: Should we use aria-current=”page” on all three levels?
I'm not saying I'm right. But I'm looking at e.g. the WAI W3C page and I see aria-current="page" at the current page, but also aria-current="location" at the top menu item. See: https://www.w3.org/WAI/test-evaluate/tools/selecting/. Link Evaluation Tools have an attribute: aria-current="location", link "Selecting Evaluation Tools" have an attribute: aria-current="page".

For me you answered the question.
If you are on the page then it is aria-current=page
If you are on a child page then it is aria-current=location

It cannot be correct for multiple completely different pieces of content all be marked as a page with the same name

I agree.

but your first comment disagreed with that?

You know, it's not easy for me to describe such complex things in English. That's why I wrote in the previous commentary: Therefore this stylized item should also have aria-curent=page (or aria-current=location if you want to be very precise)

Merged all 4.0-dev changes to keep this PR up to date with 4.0-dev

After the clearing discussion by @zwiastunsw and @brianteeman (thank you both for that) I've updated this PR.

It will set aria-current=page to the menu item when you are on the current page.
It will set aria-current=location to the menu item when you are on a child page of the current page.

For instance... testing with Sample Data Testing it will set aria-current=page to menu item "Park Blogs" and will change the aria-current=location of that menu item when you click one of the two blog posts it contains.

@hans2103 just for reference it isnt necessary to keep updating your branch unless there are any conflicts

I have tested this item ✅ successfully on f52f447

before applying the patch: <a href="/index.php/blog-1" aria-current="page">Blog</a>
after applying the patch: <a href="/index.php/blog-1" aria-current="location">Blog</a>
_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/29369.}

I have tested this item ✅ successfully on f52f447

Menu item Blog is on area-current="page" on home page
Menu item Blog is on area-current="location" on "Welcome to your blog"-detail view

@brianteeman @HLeithner @SharkyKZ Due to previous discussions I am not sure if I shall set this PR to RTC now as it has 2 good tests. Does anything speak against RTC from your point of view? Please report back if or if not. Thanks in advance.

Pinging also @wilsonge for his opinion.

@zwiastunsw are you happy with this PR? if yes then it can be merged.

@hans2103 can you update the branch because drone got some fixes yesterday

Will update as soon as possible. On vacation right now

Op wo 5 aug. 2020 om 12:26 schreef Harald Leithner <notifications@github.com

@zwiastunsw https://github.com/zwiastunsw are you happy with this PR?
if yes then it can be merged.

@hans2103 https://github.com/hans2103 can you update the branch because
drone got some fixes yesterday

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#29369 (comment),
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAE4GTWJPXSL25FES2CXXNDR7EXWTANCNFSM4NQBYMHA
.

--
met vriendelijke groeten,

Hans Kuijpers

HKweb
info@hkweb.nl
https://hkweb.nl
tel: +31 654 224 518

Yeah, it's OK.

RTC

merged recent changes on branch 4.0-dev into this PR

Seems like a valid attempt to me. We'll only find out on this kinda stuff by seeing the real world experiences. Thanks!