[4.0] Accessibility Checker [WIP] #31090
Conversation
joomla-cms-bot
added
Language Change
|
anyone have a clue about the drone error? |
@brianteeman No. But it could be the unrelated, occasionally happening failure. I just restarted drone, maybe we are more lucky this time. |
|
@brianteeman Drone failed again with the system test. It fails already when installing the CMS. Here a link to the screenshot of the result: https://ci.joomla.org/artifacts/joomla/joomla-cms/4.0-dev/31090/system-tests/36434/InstallCest.installJoomla.mysql.fail.png |
|
@brianteeman My suggested changes above will solve the drone issue. |
|
@brianteeman P.S.: Don't forget to add some update SQL for adding the new extensions (plugins) before removing draft status. |
Co-authored-by: Richard Fath <richard67@users.noreply.github.com>
Co-authored-by: Richard Fath <richard67@users.noreply.github.com>
Co-authored-by: Richard Fath <richard67@users.noreply.github.com>
Co-authored-by: Richard Fath <richard67@users.noreply.github.com>
|
@brianteeman If you want to attract people for feedback and maybe already testing, despite of the draft status, it could help to add something like "[RFC]" to the title. |
|
I don't see any sense in integrating the HTML_Sniffer bookmarklets with Joomla. It does not bring anything new. There are other equally good or even better bookmarks and browser extensions that you can easily use. (ARC Toolkit, AXE, Siteimprove) . You don't need to integrate any of these tools with Joomla to use them. The editor extension looks interesting. |
|
What you miss is that by putting it in front of the user then they will start to use it. Hardly anyone checks their site for accessibility. We have to make it easier for people and to not assume they know as much about accessibility as you know. If they did then we wouldnt have so many joomla sites (even those on joomla.org) which massively fail accessibility. |
|
Yes, and it can be disabled, right? So nobody is forced to use it. I am ok with having it in the CMS, I think it's a help. |
|
This is an argument. But this, in my opinion, will not solve the problem of education. If someone doesn't want to deal with accessibility, the add-on won't convince him much. |
|
@zwiastunsw you really are impossible to please on anything. Did you actually try it. It does exactly what you "imagined" on a per page basis. |
As stated in the first post it is NOT enabled by default |
Yes, and when it has been enabled it can be disabled again. So all is ok. |
|
@brianteeman: Please! I really know what I'm saying, I know what HTML_CodeSniffer does and what it does not do. |
|
@zwiastunsw Sorry I forgot that you know everything and are far more knowledgeable than anyone and what you say is always perfect and far more valuable than extensive user research conducted by the EU. I will remember that in future and won't make the same mistake again. Like everyone I look forward to your contribution to Joomla. |
|
from a quick test only System - Accessibility Checker has been discovered (i'm using postgresql) |
|
@zwiastunsw may I remind you that I stated in the RFC
Which you said "This is a very good idea!" |
|
i've followed the Test Instructions ..... but when i try to use the plugin on editor i got this .... i'll try to use the prebuild package later.... p.s. |
|
|
@brianteeman. Only you are the infallible genius in this group. You always have been. I wish you all the best. Just a little more and you'll stay here alone. |
|
using codemirror
|
|
@alikon thats not done yet as stated in the original post |
|
Closing this for now until I finish the editor part. didnt get any feedback on the activation method for the front end which I had hoped for and just the usual negativity from the accessibility team despite delivering exactly what I said would be delivered that they were so enthusiastic about. |
|
@brianteeman Sorry, I've missed the activation method question.
Would be sufficient for me since I think people will mainly need it when in development mode, i.e. on a copy of their live site or on the live site when in offline mode and only a logged in superuser can check it.
I think the guest state is most important for the most sites, so it would need to check that, too. Binding it to a usergroup could maybe confuse people, but I'm not sure about that.
That sounds good to me. Maybe this could be extended by having a link in backend to call the frontend with this parameter, like we can call a template preview with a link. In this case we should make sure that the parameter will be added to URLs when it is set and we navigate to another page of the site so that the whole frontend remains in that mode until we call an URL without that parameter set. Just an idea, not sure if that would be a way to go. |
|
I did go down the root of the template param approach as that was my original thoughts/aims but the problem was that it does not persist across pages and while it is good to be able to have a link in the admin this way it would be frustrating to have to do that for each page. For example you can check the article page but you wouldnt then be able to check the blog article page. Unless someone has a solution to make it persist across pages? |
|
If we add an a11y checker for frontend templates I would suggest to go the same way as the language debugger. Activating it in the global system settings (especially if we have more then tool). Alternate I would had it always active as soon as the plugin is active. Adding an option to the plugin doesn't sounds good. But first I would really like to see the editor checker, I think that's more important for the user. |
|
on hold as this is a new feature so has to wait for 4.1 :( |
Summary
This PR implements the html_codesniffer from squiz in two different ways
Test Instructions
Alternatively use the prebuilt package https://ci.joomla.org/artifacts/joomla/joomla-cms/4.0-dev/31090/downloads/36414/
Page Check
Enable the System - Accessibility Checker plugin
Visit the front end of the site and you will now see the checker
It is fairly self explanatory and can be set to use section 508, WCAG2.1 A, WCAG2.1 AA and WCAG2.1 AAA standards - defaulting to AA
The checks
For a full list of the tests that are performed see http://squizlabs.github.io/HTML_CodeSniffer/Standards/WCAG2/
Customisation
Currently the implementation uses the unmodified code from upstream. However it can be customised with our own css or if we fork it then it can be customised even further.
See the fork from the belgium government as an example https://openfed.github.io/AccessibilityCheck/
Activation
Currently the checker is active and visible to everyone whenever the plugin is enabled. This could easily be changed to a specific user or usergroup BUT that would mean that they have to login and can therefore only check the site in that state and not also in the guest state. So I didn't implement that method. Another option would be to only make it visible when you also enter a param in the url - like with tp=1 for the template preview.
xtd-editor plugin
To date this is only implemented as far as there is a button on the editor area. If you are using tinymce then its in the CMS Content dropdown. If you are using any other editor or none then it is below the textarea.
Activation
The plugin needs to be enabled and then the check is performed when the button is clicked. this is not implemented yet
Display
The results in the admin will be displayed similar to
.
This is part of the EU funded research project for improving the process of creating accessible content by authors https://accessibilitycluster.com/about
The aim of the project is mainly in researching and identifying key needs and areas where all cms can benefit. The project might eventually produce some code examples but that's not the main aim.
The research conducted in stage one of the project identified numerous needs by content authors and we are working on testing and evaluating the possibilities for improving each one of those. Not all of them apply to Joomla or we already address those issues.