No Code Attached Yet a11y bug
avatar pnkr
pnkr
15 Feb 2022

Steps to reproduce the issue

I installed 4.1.0 and i have enabled accessibility plugin in frontend.

Expected result

Actual result

There is the following console error

Uncaught (in promise) DOMException: Failed to execute 'check' on 'FontFaceSet': Could not resolve '1em Material+Icons' as a font.

in: /media/vendor/accessibility/js/accessibility.min.js

System information (as much as possible)

Joomla 4.1.0

Additional comments

screen shot 2022-02-15 at 13 19 11

Votes

# of Users Experiencing Issue
1/1
Average Importance Score
5.00

avatar pnkr pnkr - open - 15 Feb 2022
avatar pnkr pnkr - change - 15 Feb 2022
Labels Removed: ?
avatar joomla-cms-bot joomla-cms-bot - change - 15 Feb 2022
Labels Added: No Code Attached Yet
avatar joomla-cms-bot joomla-cms-bot - labeled - 15 Feb 2022
avatar brianteeman
brianteeman - comment - 15 Feb 2022

Confirmed

avatar Quy Quy - change - 15 Feb 2022
Labels Added: bug
avatar Quy Quy - labeled - 15 Feb 2022
avatar brianteeman
brianteeman - comment - 15 Feb 2022

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

avatar brianteeman
brianteeman - comment - 15 Feb 2022
avatar brianteeman
brianteeman - comment - 15 Feb 2022

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

avatar brianteeman
brianteeman - comment - 15 Feb 2022

image

avatar pnkr
pnkr - comment - 16 Feb 2022

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


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/37050.

avatar woluweb
woluweb - comment - 16 Feb 2022

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"
avatar zero-24
zero-24 - comment - 16 Feb 2022

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

avatar aesereht
aesereht - comment - 28 Feb 2022

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

avatar zero-24
zero-24 - comment - 28 Feb 2022

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

avatar drmenzelit
drmenzelit - comment - 3 Mar 2022

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

avatar woluweb
woluweb - comment - 3 Mar 2022

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
avatar pnkr
pnkr - comment - 11 Mar 2022

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
}
`

avatar R-R-M
R-R-M - comment - 21 Mar 2022

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.


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/37050.

avatar brianteeman
brianteeman - comment - 21 Mar 2022

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

avatar R-R-M
R-R-M - comment - 21 Mar 2022

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. screen shot 2022-03-21 at 14 01 02screen shot 2022-03-21 at 14 01 02


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/37050.

avatar brianteeman
brianteeman - comment - 21 Mar 2022

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

avatar drmenzelit
drmenzelit - comment - 21 Mar 2022

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.

avatar brianteeman
brianteeman - comment - 21 Mar 2022

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.

avatar R-R-M
R-R-M - comment - 21 Mar 2022

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...

avatar R-R-M
R-R-M - comment - 21 Mar 2022

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)
Screenshot 2022-03-21 at 15 54 35

avatar R-R-M
R-R-M - comment - 21 Mar 2022

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.
Screenshot 2022-03-21 at 16 09 43

avatar R-R-M
R-R-M - comment - 21 Mar 2022

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
Screenshot 2022-03-21 at 18 07 46
Screenshot 2022-03-21 at 18 38 00

avatar sozzled
sozzled - comment - 21 Mar 2022

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.

avatar R-R-M
R-R-M - comment - 21 Mar 2022

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.

avatar zero-24
zero-24 - comment - 21 Mar 2022

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.

avatar brianteeman
brianteeman - comment - 21 Mar 2022

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.

avatar woluweb
woluweb - comment - 21 Mar 2022

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.

avatar zero-24
zero-24 - comment - 21 Mar 2022

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?

avatar zero-24
zero-24 - comment - 21 Mar 2022

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 :)

avatar sozzled
sozzled - comment - 21 Mar 2022

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?

avatar brianteeman
brianteeman - comment - 21 Mar 2022

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.

avatar brianteeman
brianteeman - comment - 21 Mar 2022

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.

avatar zero-24
zero-24 - comment - 21 Mar 2022

@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?

avatar sozzled
sozzled - comment - 21 Mar 2022

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.

avatar zero-24
zero-24 - comment - 21 Mar 2022

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". 🥳

avatar R-R-M
R-R-M - comment - 21 Mar 2022
Screenshot 2022-03-21 at 16 09 43

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)

avatar sozzled
sozzled - comment - 21 Mar 2022

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.

avatar zero-24
zero-24 - comment - 21 Mar 2022

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.

avatar R-R-M
R-R-M - comment - 21 Mar 2022

@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.
Screenshot 2022-03-21 at 23 37 23

avatar zero-24
zero-24 - comment - 21 Mar 2022

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?

avatar R-R-M
R-R-M - comment - 21 Mar 2022

This is a Safari problem only

avatar drmenzelit drmenzelit - change - 26 Mar 2022
Labels Added: a11y
avatar drmenzelit drmenzelit - labeled - 26 Mar 2022
avatar brianteeman
brianteeman - comment - 8 Jun 2022

see #38009

avatar alikon alikon - change - 8 Jun 2022
Status New Closed
Closed_Date 0000-00-00 00:00:00 2022-06-08 14:00:21
Closed_By alikon
avatar alikon alikon - close - 8 Jun 2022
avatar alikon
alikon - comment - 8 Jun 2022

please test #38009

Add a Comment

Login with GitHub to post a comment