I've been using MODx for a long time, and there are a lot of things I really like about it. One thing that isn't so great about it is its lack of compliance with accessibility standards (Web Content Accessibility Guidelines, Section 508, etc.) in the manager interface. We have blind people at my company that can't use the MODx manager due to its lack of screen reader compatibility. My specialization is web accessibility, so I'm planning on putting together a to-do list for MODx accessibility. I'll put issues in the bug tracker too.
I can contribute some things to the open source code itself, but I have to admit that I'm not the most accomplished programmer out there, so I'll limit my pull requests to templates, styles, and minor things that I feel confident I can do in the programming. In other words, I'm willing to do an in-depth analysis of what the manager interface needs for accessibility purposes -- I'm well qualified to do that -- but I'll need help to actually accomplish it in the PHP and JavaScript.
Do we have anyone in the group who would be willing and interested to work on accessibility fixes?
There are a lot of parts and pieces in the manager, so it will take time to put it all together in a report. I'll keep this thread updated as I do that.
One thing that would help would be to add a label to the bug tracker: "accessibility". Can I get one of the core developers to create this label please?
Quote from: paulbohman at Nov 15, 2014, 10:39 AMI've started to assemble a list of issues which I have posted here: https://dequeuniversity.com/modx-accessibility.html
I'll add to this list as I have time. I will also add them to the bug tracker.
Thank you. Adding them individually to the bug tracker is the most important part. They're unlikely to be fixed if they're not registered there.
The issues that I've documented so far are now in the bug tracking software, as issues 12142 through 12156.
Again, I would appreciate the help of anyone who is interested in the accessibility issues, especially in terms of the PHP and JavaScript. I can help with template and style issues -- and to some degree with PHP and JavaScript -- but there are better programmers out there than I am in terms of creating beautiful enterprise-worthy code. I'm happy to guide anyone on the accessibility end goal, though, because that's my area of expertise. Just ask.
-
☆ A M B ☆
- 24,524 Posts
I wonder if NewsPublisher can be made WCAG complient? Then at least your blind users could edit resources.
The NewsPublisher code looks like it can function as a workaround for some of the basic tasks. Thanks for suggesting that.
Eventually we will want to have a default interface that doesn't require workarounds though. There are a lot of features that NewsPublisher doesn't even attempt to duplicate.
What would you like to see in NewsPublisher?
Thanks for asking! I don't know if it would be appropriate to add everything to NewsPublisher, though, to be honest. If your purpose is to allow people to add pages and edit them, NewsPublisher accomplishes that. But as far as I can tell it doesn't provide a way (or at least not an easy way) to do the following:
- Allow the user to view some sort of document tree so the user can add a new page to a specific container within that tree. It wouldn't have to be a fancy tree like the MODx manager -- in fact that would be bad for my purposes since the default tree is not disability-accessible. It could be a simple list, really, maybe with a button after the pagetitle saying "Add resource here." That's the basics of what I would need as far as that goes. I suppose you could add buttons for some of the other features too, such as publish/unpublish and delete/undelete. Those would be nice too.
- Allow users to sort resources within the tree. The drag and drop of the manager tree is nice, but again, it's bad for accessibility because it requires a mouse, at least in the current iteration. I would need an alternative to the drag and drop that allows keyboard usage. One option would be a simple "move up" and "move down" feature. They could be two buttons along with the other ones mentioned above.
I realize that adding several buttons after each page name will make the interface look a bit clunky in its raw format, but with some clever CSS it could be styled to look acceptable.
If you do implement this, we'd need a way to restrict which parts of the tree users could see, preferably using the built-in MODx permissions as the first level of security, but I'd like to be able to get more specific than that and specify something like &treeParents=`12,15,29`
If NewsPublisher had this kind of tree view manipulation, that would work really well for accessibility purposes for page creation and editing.
It wouldn't address all the other features of the MODx interface: creating/editing templates, snippets, chunks, users, configuration settings, and so on, but I understand that NewsPublisher wasn't meant to do all of those things, so that's ok.
There's no easy way to implement a tree, but version 2.0 lets you specify possible parents which are displayed as a drop-down list with one (optionally) selected.
I'm afraid sorting resources in a tree is beyond the scope of NewsPublisher, which is just designed to let you edit all or part of a single document. It could be an addition to the Manager, though it's really difficult to have a tree sorting UI without drag-and-drop. If it were a list, it wouldn't be so bad, but trees are complicated.
