I have tested this item ✅ successfully on 004c75d

All seemed to work as described. I don't know about 'the show_noauth param' thing - never met it.

On documentation: We (I) need to update the Help screens when this gets committed.

All works as expected and is better than before.
An accessibility error could be: "redundant link", as there are two (or if there is a readmore three) equal links are close together.

I give a positive test because it is better than before and users must know what they do.

I have tested this item ✅ successfully on 004c75d

RTC

Do you really thing it's needed to add a new option? I mean we try to reduce useless options and this looks like a template option and not a com_content option in my opinion...

No its not useless!! What is useless are the current options which are not usable by a regular user. This makes them usable.

It's not useless because it's not useless is not really a good answer ;-)

but ok if you think it's needed to disable the link on an images (which should always be on for people which have troubles to target the title correctly or always click on the image first because it's bigger like me) then I'm ok with it.

Either we are serious about creating a cms that will create accessible content or we are not.

why is the link on an image a accessible problem? (sorry that I don't know it)

I'm happy with the rest of the pr

It is stated in the description

Accessibility error : Identical links next to each other
Accessibility / html error : No link name on the image link ( They are just announced by a screenreader as link without any indication of what they are a link to)

Accessibility / html error : No link name on the image link ( They are just announced by a screenreader as link without any indication of what they are a link to)

that's the other part of the pr that's should be fixed and is fine I think.

Accessibility error : Identical links next to each other

That's something I can't understand why it is a problem and by the way if I don't understand who should someone understand it who only want's to have a website? How should anyone think that this options is a a11y option?

can one of the links automatically be disabled for a screenreader?

OK Let me try to explain the multiple issues.

Firstly if you select linked titles you also get linked image. You didnt ask for that but you got it anyway. The link on the image was created without any meaningful description. This means that a screenreader would just announce "Link" for every linked image. As this is for the blog intro image then you will now have multiple links on the page that all have the same name "Link". If that is fixed by ensuring the link has a meaningful name then you hit the second problem. You now have two identical links next to each other. This is against the WCAG rules but it also means a user using any form of assistive technology has to navigate past double the number of links to get to the one that they want.

This is not about making accessibility an option or something that you have to configure. This is about making all content accessible.

In my JaB talk I talked about how we have been led down the path of responsive design where we ensured that the content was great on any device. So that our websites worked on all devices without doing anything special. This device first approach completely ignored people. A people first approach ensures that content works great for all people without doing anything special.

can one of the links automatically be disabled for a screenreader?

Not just about screenreaders. Anyone navigating a site in a linear manner eg with a keyboard also has the problem of double identical links. And no you can't do that and nor should you.

If you want to see a really typical example of why this needs to be fixed just check out the supposedly accessible template https://paswjoomla.net/joomla/

But should then the CMS not come with a proper default and when somebody want's to change the default behavior, then make a template override? I understand @HLeithner that these tiny options are flooding the core already.

A correct default solution would be to generate the image without link. As @laoneo says. This was default until someone has made a PR for linking the image too.
But I know that, if we remove the link on the image, we soon will have a PR for linking the image - because it seems to be a natural human behaviour to klick on images in a blog, more than on headlines.

I understand @HLeithner and would like to reduce the number of params instead of increasing them. And I am sure that all users will choose to link image AND title because they don't know why this is not a11y (or don't care about a11y).

So this PR makes sure that if there is a link on the image, it at least is correct.

I am sure that all users will choose to link image AND title because they don't know why this is not a11y (or don't care about a11y)

sure too

We really should be making it easier for content creators to produce accessible content. Not just for the joomla UI to be accessible. If I had my preference it would be to only allow either title or image to be linked eg
Blog links ->

• none
• readmore
• title
• image

But I was pretty sure that would get rejected so I made it an option

I am sure that all users will choose to link image AND title because they don't know why this is not a11y (or don't care about a11y)

sure too

thats why I proposed the accessibility checker

Linking the image was done in 2014, so the web changed quite a bit since then. I think it is fine to get rid of the links. For reference, here is the pr which added them #4134.

@brianteeman please simple remove the link on the image since it is a a11y problem we shouldn't confuse people with options they shouldn't use^^ if someone want's the image linked he/she should do a layout override.

And please add a comment in the source why the image doesn't have a link anymore.

There is nothing wrong with having the image as a link (when the code is correct). The problem is only when you have a linked image AND a linked title AND they are next to each other. So no I wont remove it. Either accept or reject this PR. It is correct as it is.

Can we not detect that programmatically and create then proper HTML code? Is it really necessary that a human needs to define here how the output should be that it is accessible? With my little knowledge I have the impression this is something core should do correct out of the box.

You're a better person than me then if you can write the logic to determine this programmatically with the current options

With the proposed defaults core will do it correctly out of the box.

I like this approach
https://inclusive-components.design/cards/
to make blog elements clickable.
I have it working on some pages using overrides.
Maybe something to think about.

Thanks @rdeutz