Confirmed

The problem is caused by an incorrect change in the code by @infograf768 graf768 upstream ranbuch/accessibility#27

ranbuch/accessibility#31

Instead of relying on upstream the change in #36948 will fix it

It works!
You are a life saver! ?
Thanks you!!!

I added the 'useEmojis' => True
but there seems to be side-effects:

• the wheelchair icon is skewed
• in the popup the close and refresh are like "italic"

Hmm the intention of the useEmojis option is to remove the dependency of google fonts. When there are glitches with the use of the option "useEmojis" that does have to be reported upstream i would say

in which file should i add this line (useEmoji => true) ?

@aesereht please check and test: #36948 its the change you are looking for once tested this can go into the next release :)

That is how the plugin is looking like in Joomla 4.1.1-dev (xampp on Windows). Can someone confirm?

Not tested 1.1.1-dev yet, but this is exactly what I was getting when setting the emoji option to "1" in the current J4.1.
Two issues that I see:

• the Close and Refresh buttons are italic which is not nice for an icon
• same for the blue a11y button: also italic

emoji settings sets some weird CSS with skew and italic...
so a quick fix is this.
`
/* open accessibility menubutton */
._access-icon {
font-style: normal;
transform: none!important;
}

/* close and reset buttons */
._access-menu ._menu-btn {
font-style: normal
}

/* an extra css to remove the rotate on hover :P */
._access-menu ._menu-close-btn:hover,
._access-menu ._menu-reset-btn:hover {
transform: none!important
}
`

Adding this as a comment and opinion, my driving force to upgrade to J4 was the accessibility feature for front end users. I currently have this feature turned off due to this bug, in my opinion the emojis are very dated, not consistent in style and don't offer any visual representation of their actions. Despite correcting the CSS the JavaScript file overrides my custom CSS. Being able to switch off the fallback to emojis would be very helpful. The material icons or a custom svg image would be a perfect solution.

Instead of adding useEmojis true replace the files in media\vendor\accessibility\js with these two files which do not have the stupid upstream bug.
accessibility.min.zip

Thanks Brian, I have tried that but I think there's more to it than removing the +. Also I've just tried it on a clean install with your additional files being the only replacement. See image below. I can create the correct CSS and add it to my stylesheet but the JavaScript occasionally overwrites it. It would possibly help if the CSS wasn't in the JavaScript file and only in the style sheet.

the two js files I gave you fix the font family bug. It must be Material Icons and not Material+icons

I would like to point out that Joomla is participating in Google Summer of Code 2022 and one project is to improve / rewrite the accessibility plugin: https://docs.joomla.org/GSoC_2022_Project_Ideas
So we will hopefully have some solutions for the open issues in the next months.

or we could simply do the obvious thing and fix it now. Joomla broke it so joomla can and should fix it. But instead it is better to bury your head in the sand and ignore the facts. I spent a long time putting accessibility features in to joomla 4 and took a great deal of abuse for doing it. Now joomla has broken it and instead of fixing it it seems its better to boast about not using a google font and to use an emoji that everyone hates. Not that anayone here would know as they never visit the forums where users comment.

sitting back and relyoing on a gsoc project is crazy. only a very small percentage of them are ever usable. it's all down to the mentor - only one has a perfect success record.

the two js files I gave you fix the font family bug. It must be Material Icons and not Material+icons

In my case this hasn't fixed the problem, the images I have uploaded were after I installed the modified JS files, cleared browser cache and website cache and page cache are off. This is the only topic I have ever posted on Github, and have been using Joomla since the start. The emojis need removing, Joomla is so much better than that option. (Please :-) Happy to try another ideas...

Mac OS 12.2.1
Safari: 15.3
Joomla 4.1.0
PHP 8.1.3
Clean install, default template, only modification is the two JS files above, note accessibility.min.js.gz (has been removed)

The below image is what happens if you include the accessibility.min.js.gz file and use the two modified files from Brian above. Hope this explains where the inconsistency is coming from.

I now have the material icons loading in Safari chrome and Firefox, combination of problems. I removed the original J4.1.0 accessibility.min.js.gz as this is drastically different from the accessibility.js file that Brian has suggested above. This explains why despite switching to the modified JS files the zipped accessibility file has been loaded by the browser instead. This works in Firefox and chrome on MAC OS. But does not load anything in Safari, removed the additional spaces see image below fixed the problem in Safari, which now loads the material icons. However there is still a console error in Safari. See second image

Emojis are, IMO, a dim-witted idea in this situation (i.e. using them instead of glphys): different web-browsers render them differently and inconsistently. I agree with @brianteeman and the fix to use the Material Icons font-family is sensible.

Not that anyone here would know as they never visit the forums where users comment.

Well said, Brian. For other J! CMS developers who don't visit other forums where these matters are discussed, see https://forum.joomla.org/viewtopic.php?f=808&t=992530 as one example.

Going to temporarily remove invert colour option in the accessibility menu as it forces the menu to stick to the bottom of the screen in Firefox. I'm pretty certain this has been reported somewhere else but will investigate it later.

Emojis are, IMO, a dim-witted idea in this situation (i.e. using them instead of glphys): different web-browsers render them differently and inconsistently. I agree with @brianteeman and the fix to use the Material Icons font-family is sensible.

Its the feature that we where pointed to by the origianl developer. Feel free to integrate the material icons locally and its fine to go. But we should avoid as much new external dependencies as possible.

Feel free to integrate the material icons locally and its fine to go.

that will not work!! Joomla broke the code that supports material icons.

But we should avoid as much new external dependencies as possible.

This is NOT a new external dependency.

One of the German ladies (I think it was @astridx ) had prepared SVGs so that we would not depend on a font nor on emojis.
This seems to be the best option in many regards.

This is NOT a new external dependency.

I'm talking about the remote google fonts which should be avoided.

that will not work!! Joomla broke the code that supports material icons.

From my understanding that bug has to be fixed upstream and than we need a new release not a bug within the implementation of joomla?

One of the German ladies (I think it was @astridx ) had prepared SVGs so that we would not depend on a font nor on emojis. This seems to be the best option in many regards.

Cool idea in the bestcase thats integrated into the upstream lib and than we can use them with an parameter similiar to the Emojis setting :)

It's the feature that we where pointed to by the original developer. Feel free to integrate the material icons locally and its fine to go. But we should avoid as much new external dependencies as possible.

I love this! It was the original developer's dim-witted idea to use emojis, not the CMS development team's lack of understanding of the consequences in slavishly using that approach. Well, the dog ate my homework, too.

I understand the rationale about "avoiding" the dependency on external fonts (esp. if one feels threatened that Google may withdraw them in future); where's the evidence of a Google conspiracy? (Perhaps it's a knee-jerk reaction to the ill-fated FLoC idea, hmmm?)

AFAIK, the Material Icons font-family is open-source and it could be added to the ../media folder, couldn't it?

This is NOT a new external dependency.

I'm talking about the remote google fonts which should be avoided.

Yes I know what you are talking about and it is not a NEW dependency

that will not work!! Joomla broke the code that supports material icons.

From my understanding that bug has to be fixed upstream and than we need a new release not a bug within the implementation of joomla?

The bug was created after the upstream developer was bullied into merging broken code, despite warnings, by joomla developers.

Stop passing the buck!! And your pathetic battle against google is really beyond a joke now.

final comment before I click ignore.

@zero-24 it was your pull request to use emojis that has broken the ability to use icons. You didnt give a choice to the site owner to ignore your vendetta against google. Your change forced the use of emoji.

@zero-24 it was your pull request to use emojis that has broken the ability to use icons. You didnt give a choice to the site owner to ignore your vendetta against google. Your change forced the use of emoji.

And you asked me to use this setting over invenstigating how to load them locally.

"Vendetta" wow I have just checked what that is and i can assure you I have nothing against google nor google fonts at all and nothing with blood for sure. But we as cms should use as less external stuff as possible, about that we even had an motion back when we where discussing that other captcha system, and external stuff includes google fonts.

Whats the problem with the solution to go and just load it locally and both sides can be happy?

The problem, my dear Tobias, is that you have not understood the capability of ordinary J! users to easily adapt this convoluted approach to suit their needs. Perhaps if you spent as many hours a day as we simple, non-technical folk spend on the forums, you may get an idea of the kinds of questions that people ask.

I don't give a fig-leaf for JPEGs, BMPs, GIFs, PNGs, SVGs or other image formats. They only add more bloat to the payload in deploying a J! installation. Thank the gods we got rid of Hathor. I also don't care for emojis. Fonts are fairly easily deployable these days.

All of which are irrelevant to someone whose visual acuity is diminished. These "issues" are only relevant to people who have 6/6 vision. I sometimes have to squint in order to tell the difference between an "I" (capital i) and an "l" (lowercase L) but the context in which the letter appears usually explains which is which. People who have difficulties with eyesight require a completely different "context".

When it comes to declaring that there are "sides" in this discussion, there were no sides when J! 4.0.0 was released. The embattlement commenced after that time. If we want to wait for GSOC to take the lead on this matter then I suggest we return to the way things were when J! 4.0 was released and "improve" the situation in a future release of J! 4.x (or even later).

To summarise, the problem is because of another disability: deafness. We've explained our position; please hear us.

The problem, my dear Tobias, is that you have not understood the capability of ordinary J! users to easily adapt this convoluted approach to suit their needs.

I'm not asking the ordinary J! users to change or adapt anything as mentiond above for now the emojis are the only thing that works as, from my understanding, there are issues with the current upstream google font implementation. So for now until that issue has been fixed emojis are a better workaround for the ordinary J! users vs an broken font right?

And I have not said that we can not use the font thing I just said we should not depend on this to be loaded from remote.

Perhaps if you spent as many hours a day as we simple, non-technical folk spend on the forums, you may get an idea of the kinds of questions that people ask.

Funny enough thats a thing I took from the forum up to the CMS to fix as a person reported that the CMS still loads google fonts by default without a option to take it off. Now I'm the bad guy because I took that request up from the forum? Hopefully not because that is what you just asked me to do even more :)

Sometimes there are just different opinions that can not be changed by "just look at the forums" nor do they need to be changed that way. From my understanding having different people, different backgrounds and different opinions working torwards the same goal helps everyone.

I don't give a fig-leaf for JPEGs, BMPs, GIFs, PNGs, SVGs or other image formats. They only add more bloat to the payload in deploying a J! installation. Thank the gods we got rid of Hathor. I also don't care for emojis. Fonts are fairly easily deployable these days.

Yes the font is there it "just" has to be shipped locally and we are good to go right?

All of which are irrelevant to someone whose visual acuity is diminished. These "issues" are only relevant to people who have 6/6 vision. I sometimes have to squint in order to tell the difference between an "I" (capital i) and an "l" (lowercase L) but the context in which the letter appears usually explains which is which. People who have difficulties with eyesight require a completely different "context".

I agree that where the accessibility tools are intended to help right and why different contrast settings are aviable. But that has nothing to do with this issue here right?

When it comes to declaring that there are "sides" in this discussion, there were no sides when J! 4.0.0 was released. The embattlement commenced after that time.

I'm sure many will disagree, didnt we we both even had disagreements arround that time? Finding the best compromise between two or more "sides" result into the best result for everyone. Lucky us there is no (friendly) dictator who decides or forces everything on us. :)

To summarise, the problem is because of another disability: deafness. We've explained our position; please hear us.

Your position is "We should use material icons over emojis" right? As mentiond a few times now its a opinion that I can be happy with my only request is that I want it to be loaded from you local instance and not from external. So both "sides" can be made happy and using that we found yet again the best solution for both "sides". ?

Good to hear that we're all on a similar wavelength. Now we've cleared the air if anybody knows of a way to stop this console error in safari that would be very welcome. (without using emojis may I add)

I'm joining Brian on the I've-had-it-up-to-here bench. My "position" is not to use Material Icons over emojis; I don't give a rat's arse whether you use one font-family or another. My position is that emojis (and relying on a half-arsed piece of Javascript to populate the menu) are inconsistent, inappropriate and dysfunctional for "normal sighted people". That's my position. Please don't attempt to editorialise my "position".

I have relatively average eyesight but, without boasting about my good fortune, I can see that the current system is broken. Therefore, I'm taking my leave of this subject and I'll sit on the sidelines while the J! CMS developers flounder like fish out of water.

My position is that emojis (and relying on a half-arsed piece of Javascript to populate the menu) are inconsistent, inappropriate and dysfunctional for "normal sighted people".

Thats another story and about how that plugin has been build. I dont intend to change any of that nor have I touched that part with any of my changes yet. For that I would líke to ask you to open an dedicated issue and explain your alternative solution and not taking over this issue here that is "just" about that broken font thing.

That's my position. Please don't attempt to editorialise my "position".

I'm sorry I have misunderstand your position than. It was not my intention to "editorialise" your position thats why i had a question mark in there, thanks for clearing things up :)

Good to hear that we're all on a similar wavelength. Now we've cleared the air if anybody knows of a way to stop this console error in safari that would be very welcome. (without using emojis may I add)

I have no safari on my end but i can confirm the changes that brian proposed fixed the issue on my end with google fonts enabled.

@zero-24 I've implemented the JS fix from Brian removed the accessibility.min.js.gz which is riddled with problems. And it all works. It's now just a console error in safari which would be nice to fix without having to load emojis. See image below.

i'm sorry i dont have that level of detail with JS. To me it looks like this is an upstream bug which only comes up on Safari as i can not confirm it with chrome on my end. what happens when you use chrome on mac does it show the same error message to you?

This is a Safari problem only

see #38009

please test #38009