So while without your PR the information if the check result is good or bad was visible by colours green and red and the text, yes is alway good and no always bad.

Now with this PR only the color shows if the result is good or bad.

In my opinion that's an accessibility flaw.

The column header is "Checked" so changing the text in that column to enabled or disabled makes no sense - especially to a screenreader

Perhaps a better solution is to have better text

@brianteeman Maybe it would also help to make the check conditions (title) be questions? E.g. "Is the database supported?" yes/no, "Is the Behavior - Backward Compatibility plugin disabled?" yes/no, and so on, with yes alwaqys good and green, no always red and bad.

If so: Would that be a change in the meaning of the language strings so it would fall under our b/c policy, so it needs new keys and deprecate the old ones for removal in 7.0?

@brianteeman Could make sense to provide legends for the tables in addition so you know the title on the left side is the condition, the button on the right side is the result, and if something's wrong the optional text below the title is the instruction to fix it?

The column headings are correct

It just needs better description/advice as I suggested above

See #46326 for an alternative proposal

This was a simple clarification of the confusing information only with minor changes.
But all this would need a full refactoring as it’s not the best about UX and accessibility.
If the column label is Checked, so the yes/no is not better; it should be a checkbox or a ✅ indicator.
I can work on an another PR for that, but may need more time to be validated.

I close this PR to work on another more advanced one.

Re-open with a better proposal!

@brianteeman you mentionned on Mattermost a valid point:

BTW even if your site fails all the required checks you are still offered the option to "upload and update"

We can do another PR for this?

Something like this, maybe:

I do not agree with this. It is not an error. The column header is checked so saying it's value is error is wrong

So we have 3 alternative PRs for the same thing, this one here, #46326 by @brianteeman and #46327 by @chmst .

Updated PR

Note for @brianteeman : it's possible to integrate your new language strings when the plugin compat for J5 is enabled only (and keep it simple when it's OK)?

I do not agree with this. It is not an error. The column header is checked so saying it's value is error is wrong

I've tried with existing language strings, but what could be a better wording? "Warning", "Failed", "incorrect"...
As this label should work for all Requirements states.

How about combining all 3 PRs?

• Use the titles from @chmst 's PR #46327 .
• Use the notices from @brianteeman 's PR #46326 .
• Leave the "Yes" and "No" texts for the result as they are but add the check marks or cross marks from this PR here.

P.S.: An aspect to be considered is our b/c policy for language strings. We cannot change the meaning in a patch version.

@brianteeman As you are the native speaker in our little 3 PR club: Do you see any problems with that in any of the 3 PRs?

@richard67 my pr introduced new strings so there is no BC issue

@cyrez the check is yes/no if you say fail that implies the check failed not that the result is no

@richard67 my pr introduced new strings so there is no BC issue

@brianteeman Would Christiane's PR mean a meaning change for the title strings?

@brianteeman i've updated with a new language string "Action required" instead of "Error", and integration of your 2 new language strings.

In the description of this PR, i've added 2 screenshots: When checked is ok and when it needs action.

For info: it is still a proposal and not ready for test.

Let me explain:
Currently, if for example you don't have JSON support, you miss information notice about it.
For example, "Missing native json_encode / json_decode support. Contact your hoster or check your server settings to enable JSON support." (not best English... just for example, to get useful information for a call to action with help).

And for other PHP and database settings as well.
What would be great is notice for each one when the condition is not checked, with useful information as Brian wrote for the compat plugin.

Larger update of this PR with new language strings and notices for each requirements.

@brianteeman @richard67 i've extended the purpose of this PR to an overall improvement.

Note: maybe just the "Checked" column header not accurate and could be changed to something more clear?

@bembelimen suggested I keep the badge, so here's a preview just in case...

Links to manual are only ever in english but if you link to docs then they are in the current language if they are in the format https://docs.joomla.org/Special:MyLanguage/LINK

Links to manual are only ever in english but if you link to docs then they are in the current language if they are in the format https://docs.joomla.org/Special:MyLanguage/LINK

Do you mean for "Technical Requirements" link or for link to Compatibility plugin page on manual as well? As not sure all exist on docs.joomla.org

I think i will use updated to use badge as @bembelimen suggested, for consistency with other parts of the pre-update process.

I like this appraoch, I think this improves usability. And close my PR.

I have tested this item ✅ successfully on 03738ba

checked both.

Thank you for your test @ChristineWk !

I've udpated the language file with Capitalisation for labels as mentionned in the manual.

Thanks @richard67 for the direct link to the manual.

Rule is that titles or labels are capitalised, see https://manual.joomla.org/docs/next/user-interface-text/capitalisation/ .

Links to manual are only ever in english but if you link to docs then they are in the current language if they are in the format https://docs.joomla.org/Special:MyLanguage/LINK

Do you mean for "Technical Requirements" link or for link to Compatibility plugin page on manual as well? As not sure all exist on docs.joomla.org

its above my pay grade to make a decision but I would expect all links to go to content in my own language. This is possible with the docs site but not currently possible to the manual

FYI some of the checks will never be displayed as failed. For example the php version check will never display a fail as the component checks that before this page even loads

FYI some of the checks will never be displayed as failed. For example the php version check will never display a fail as the component checks that before this page even loads

Yes, i saw that as well. But for consistency, i think it's best to keep the new language strings for it, or no?

About links, like @brianteeman, i think it would be best to link to the User documentation instead of the manual, and with possible translation.
As far as i know, a new User Documentation site is about to be launched, so this could be an update to plan for those strings when the new user documentation site will be public, and with the needed information there?

My preference is #46326 by @brianteeman
It is concise, clear, correct and prevents people like myself trying to get my head around a double negative.

After talk with @chmst, I've improved accessibility for links with a target blank. All those external links in language strings (not only the ones related to this PR, but as i've got the hands on it, let's fix it in the same time) missed a title attribute for screen readers.

That does not change the main purpose of this PR, but improve all com_joomlaupdate language accessibility in one shot.

Thank you @chmst for your help! 👍

the last change does not improve accesibility - it was better before. Voice over on osx and JAWS will ignore the title. In many ways this use of the title makes accessibility worse not better.

https://www.tpgi.com/using-the-html-title-attribute/
https://silktide.com/blog/i-thought-title-text-improved-accessibility-i-was-wrong/

the last change does not improve accesibility - it was better before. Voice over on osx and JAWS will ignore the title. In many ways this use of the title makes accessibility worse not better.

https://www.tpgi.com/using-the-html-title-attribute/ https://silktide.com/blog/i-thought-title-text-improved-accessibility-i-was-wrong/

So, this is done like this (with a title attribute) on every other area of Joomla admin (just check the admin login page to see html code).
I agree with that, but in the same time W3C itself recommends it for WCAG 2:
https://www.w3.org/TR/WCAG20-TECHS/H33.html

So, what should we do then?

We can do this "Technical Requirements (Open in a new tab or window)" (but we may get long links in some area where the icon is already a visual for the target blank).

EDIT: i've read the first article, and no mention it's bad in this case for a href anchor: the title adds specific information for screen readers. Visual information is provided by the icon indicator of a target blank.

being wrong on other places is not a reason to repeat the error. what you had before was perfectly ok

being wrong on other places is not a reason to repeat the error. what you had before was perfectly ok

What i did at first is my favorite one as well.

I will ask the A11y team to have a view on it. ;-)

@cyrez Is this PR ready for testing now or do you expect more changes?

@cyrez Is this PR ready for testing now or do you expect more changes?

Not yet, i'm just reverting the language strings with update for accessibility with a screen reader (did all the test, and will set a working solution).
So, just wait a few minutes, and it will be ok for testing ;-)

So, @brianteeman, i did many test with VoiceOver, and the visually-hidden as set in this PR for the new strings is the best!

In VoiceOver (MacBook), both title attribute and visually-hidden text inside the link are read.
BUT, if i'm in French the title attribute has no language detection and spells it in "french" (it's horrible english text with a french spelling).
With the visually hidden text, the language is detected, and i've got a second voice in English.

So, definitely, visually hidden text wins!

This PR is ready for test!
cc/ @richard67 @brianteeman @chmst @ChristineWk @dautrich

To not block it for a patch release, i will do the other target blank fixes in another PR later, for 6.1 release.

Thanks for correcting the accessibility of the links

I am still not convinced that https://manual.joomla.org/docs/next/ is the correct site to link to at the moment due to it being english only

Thanks for correcting the accessibility of the links

I am still not convinced that https://manual.joomla.org/docs/next/ is the correct site to link to at the moment due to it being english only

Yes, i would prefer the User documentation, but the new one is soon ready, and the current one does not have the information (you have to click on a link to... the developer manual).
This could be updated later, maybe?

Current User Docs page: https://docs.joomla.org/Technical_requirements (You have to click to go on a new page)
New page: https://downloads.joomla.org/technical-requirements (you have to click to go on a new page)
Last page: https://manual.joomla.org/docs/next/get-started/technical-requirements/ (the one in this PR)

So, this should be fixed, as having 3 steps to get the information is not good. :)

I have tested this item ✅ successfully on 9e56375

I have tested this item ✅ successfully on 9e56375

Are there some language strings which become obsolete as this PR adds new strings? If so, the obsolete strings should be deprecated with a corresponding comment for removal in 7.0.

Are there some language strings which become obsolete as this PR adds new strings? If so, the obsolete strings should be deprecated with a corresponding comment for removal in 7.0.

Added the deprecated strings in 7.0 ;)

What seems inconsistent to me (at least in the screenshots in the description):

• When the condition for the Joomla 5 b/c plugin fails, the title is "The 'Behaviour - Backward Compatibility' Plugin Must be Disabled".
• When the condition for the Joomla 6 b/c plugin fails, the title is "Behaviour - Backward Compatibility 6"

For consistency I would expect the latter to be: "The 'Behaviour - Backward Compatibility 6' Plugin Must be Enabled".

What seems inconsistent to me (at least in the screenshots in the description):

* When the condition for the Joomla 5 b/c plugin fails, the title is "The 'Behaviour - Backward Compatibility' Plugin Must be Disabled".

* When the condition for the Joomla 6 b/c plugin fails, the title is "Behaviour - Backward Compatibility 6"

For consistency I would expect the latter to be: "The 'Behaviour - Backward Compatibility 6' Plugin Must be Enabled".

Is it required if no B/C issue? For example, if you use only Joomla 5.4 with no third-party extension installed, is it needed to have the compat 6 enabled?

Note: i can add those strings for now.
But maybe the global logic can be reviewed in the case no third-party extensions could break the site on J6. (by security, to not block update only if zero third-party extensions installed)?

IMO, this could be another PR...

What seems inconsistent to me (at least in the screenshots in the description):

* When the condition for the Joomla 5 b/c plugin fails, the title is "The 'Behaviour - Backward Compatibility' Plugin Must be Disabled".

* When the condition for the Joomla 6 b/c plugin fails, the title is "Behaviour - Backward Compatibility 6"

For consistency I would expect the latter to be: "The 'Behaviour - Backward Compatibility 6' Plugin Must be Enabled".

Updated!
Screenshot with all not OK updated in the PR description.

Is everything OK now? :-)

Note: i can add those strings for now. But maybe the global logic can be reviewed in the case no third-party extensions could break the site on J6. (by security, to not block update only if zero third-party extensions installed)?

IMO, this could be another PR...

I don't see the need for such a change. Not everything which needs the Joomla 6 b/c plugin must be a 3rd party extension, it could also be an override, and all those cannot be checked. So better safe than sorry and force people to enable the J6 b/c plugin before the update.

Is everything OK now? :-)

Seems so.

@ChristineWk @dautrich Could you test again with the latest changes? Thanks in advance.

I have tested this item ✅ successfully on d0508b6

@richard67 Done

I have tested this item ✅ successfully on d0508b6

OT: I always had the GitHub token.
I got a message saying it was missing. I don't know why.
I re-entered it...

RTC

✅ Final test before merge with JBT 5.4-dev

• Before the PR, seen the confusing double Negation
  'Behaviour - Backward Compatibility' plugin is disabled No
  with enabled 'Behaviour - Backward Compatibility' plugin
• Applied PR with gh pr checkout 46324
  • Checked everything red and the suggestions and links are correct
    • Set mbstring.language = Japanese in php.ini file and checked the recommended .htaccess fix is working
    • Enabled 'Behaviour - Backward Compatibility' and disabled 'Behaviour - Backward Compatibility 6'
    • Remaining tests set to false by hacking -> state = false;
    • Links are going to Requirements for Joomla! 6.x
    • ⚠️ Not to disable parse_ini_string PHP function is not named in Requirements for Joomla! 6.x -> I will handle this in parallel
    • ⚠️ 54-60/compat-plugins is not up-to-date -> I will handle this together with 6.0 RMs
  • Checked everything is green
  • Tested in light and dark mode

👍 Thank you @cyrez for your contribution. Thank you @brianteeman, @richard67, @chmst and @Webdongle for supporting this PR. Thank you @ChristineWk and @dautrich for testing.

Thank you @ChristineWk and @dautrich for testing.
Thank you too @chmst @brianteeman and @richard67 for your review, help and suggestion!