[#31090] - [4.0] Accessibility Checker [WIP]
- Closed
- 16 Oct 2020
- Medium
- Build: 4.0-dev
- Draft PR
- # 31090
- Diff
- brianteeman:oc1-a11y
User tests: Successful: Unsuccessful:
Summary
This PR implements the html_codesniffer from squiz in two different ways
- A plugin that when enabled will perform a full accessibility check on the current page in the front end
- An xtd-editor plugin button that will perform a full accessibility check of the content in the editor. Tinymce, codemirror etc
Test Instructions
- Apply the pr
- npm i
- database fix and then discover the two plugins
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.
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Administration Language & Strings Templates (admin) NPM Change Repository SQL Installation Postgresql Libraries Front End Plugins |
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.
| Labels |
Added:
?
NPM Resource Changed
?
|
||
@brianteeman P.S.: Don't forget to add some update SQL for adding the new extensions (plugins) before removing draft status.
I just forgot to commit them - have done now.
It will never have draft status removed if people dont test, comment or review
I just forgot to commit them - have done now.
@brianteeman I can't see that here on GitHub.
It will never have draft status removed if people dont test, comment or review
Well, draft means not ready for testing and review yet, at least most people think so. When removing draft status, GitHub calls it "Ready for review".
It is not complete which is why it is a draft. But it can't be completed without feedback
| Category | Administration Language & Strings Templates (admin) NPM Change Repository SQL Installation Postgresql Libraries Front End Plugins | ⇒ | SQL Administration com_admin Postgresql Language & Strings Templates (admin) NPM Change Repository Installation Libraries Front End Plugins |
It is not complete which is why it is a draft. But it can't be completed without feedback
@brianteeman Absolutely right. I hope we get feedback, and of course people can test it. It just might be that they have to test again after changes coming while in draft. I'll see if I can find the time to test it on weekend.
Feedback from me so far is that according to the description it looks good to me and is a useful thing.
@brianteeman Still something's wrong with the installation SQL, and probably also with the update SQL. Drone reports column count not matching value count for some insert statement.
Update: The update SQL's look ok, for the installation SQL's see my suggested changes.
@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.
I imagined that it will be a tool that will examine several dozen typical aspects of accessibility throughout the site and report that they may cause problems. For example, that images do not have alto attributes. For example, that there are functions that do not have keyboard event handling (e.g. in applied add-ons, extensions). Itp.
If you make a good addition for authors, I will be happy.
@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.
Yes, and it can be disabled, right?
As stated in the first post it is NOT enabled by default
Yes, and it can be disabled, right?
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)
the same happens on mysql
@zwiastunsw may I remind you that I stated in the RFC
Mode 2 a site plugin that could be enabled (like debug mode) for checking the full page in the frontend
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.
btw, imho, this is a good step in the right direction
To date this is only implemented as far as there is a button on the editor area
@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
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.
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2020-10-16 07:06:48 |
| Closed_By | ⇒ | brianteeman |
@brianteeman Sorry, I've missed the activation method question.
Currently the checker is active and visible to everyone whenever the plugin is enabled.
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.
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.
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.
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.
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 :(
anyone have a clue about the drone error?