[5.2] wip Update accessibility toolbar
Updated to v5.0.4 adds some new functions
- [x] update to latest library
- [x] increase/decrease line height (disable until/if fixed upstream)
- [x] disable animations (NEW)
- [x] default emoji icon no longer skewed
- [x] link to optional accessibility statement (NEW)
- [ ] dark mode
- [ ] Angie icon set (https://github.com/angieradtke/Accessibility-plugin-icons)
- [ ] Fix hot keys not working - nearly there
- [ ] Auto(partial)hide icon and expand on focus
- [ ] extract css to external file to allow greater customisation
- [x] add position option
- [ ] add custom function to use open dyslexie font
- [x] translate "hotkey"
Working with upstream to resolve multiple bugs
Testing Instructions
Actual result BEFORE applying this Pull Request
Expected result AFTER applying this Pull Request
Link to documentations
Please select:
-
[ ] Documentation link for docs.joomla.org:
-
[ ] No documentation changes for docs.joomla.org needed
-
[ ] Pull Request link for manual.joomla.org:
-
[ ] No documentation changes for manual.joomla.org needed
Can you please add #39102 to the to-do list?
This pull request has been automatically rebased to 5.2-dev.
@fedik One of the issues with this script that I would like to resolve is that there are a lot of advanced customisations that can be made via js or css. Creating a UI for this would be overkill as they are typically advanced use cases.
My thought process is that the plugin can have two additional fields for the user to enter advanced jss and css.
An example might be entering the following to the js field
instance.menuInterface.increaseText = function() {
// My own way to increase text size . . .
}
My question therefore is what would be the correct way to output/use the contents of these two advanced fields.
That could work, but that a very bad idea :wink:
What you could try, is to add "important options" (from your point of view) to the plugin parameters.
And then move this code https://github.com/joomla/joomla-cms/blob/a306ee6e21801c874c279b264b0241d66c9b0b53/plugins/system/accessibility/src/Extension/Accessibility.php#L105-L111
to own file (asset) media/plg_system_accessibility/js/accessibility-config.js
Then Advanced Users can override it with template override, when they need something "advanced".
And for css it can be part of user.css (or something kind of accessibility-user.css).
Before I comment on why I dont want to do it the way that you suggest can you explain why it is a bad idea. I wont learn anything otherwise.
Allowing User to insert JS in backed, is kind of the same as allowing User insert PHP in backend. We cannot control that code, and what they put in there. Integrate this code with existing plugin parameters will be close to impossible.
Addittionaly it can create a potential security problem.
Allowing User to insert JS in backed, is kind of the same as allowing User insert PHP in backend.
Doh - silly me
Since I started this PR upstream has completely changed (again)
It is now possible to create our own ui for the toolbar instead of the hacky solutions that were previously available
See the Custom Styling section https://ranbuch.github.io/accessibility/site/
Note: The icons from Angie will need to be adjusted if we want to use them as an icon font (doesnt support multiple colors/shades) although I guess if the latest upstream changes are used to create our own UI for the toolbar then svg could be used
Doing some tests today. The hotkeys work for me, but ctrl+alt+q (animations) in Chrome but not in Firefox ctrl+alt+r activate the reading guide an opens something from my graphic card too, but that is something specific from my PC
yeah the hotkeys are weird. No idea what to do there
IBM Equal Access Accessibility Checker and in the Firefox Accessibility tab I get some errors / things to review... can we do something here?
As you said you didnt want to create our own ui these are both upstream issues to resolve.