Accessibility and MODx Manager 097

I have been thinking about 097 and how to market it to small enterprise and goverment and the thought of 508 and WCAG came to mind. ExtJS has issues as far as I can tell relating to not working with screen readers and some alternate browser technologies. In many places governments and soon many private companies will be required to comply with 508 and or WCAG or some legislative variant much like it is the law to be wheelchair accessible if you are a restaurant in most places.

What I propose is that we start a MODx Accessibility Project that will review and test MODx to be accessible to persons who are differently abled. The internet and computers have opened significant doors to communications for such people; allowing them more employment, more freedom and can act as a vehicle for their personal liberty.

I understand that the ExtJS project plans on being more 508 compliant but as Derek Featherstone said in an interview with UIE, accessibility is not about standards and laws it is about makeing it possible for people to use technologies.

If we can open up MODx Manager for all people to be able to manage and contribute to content we will be well on our way to the top 3 Content Manangment Applications out there.

I am looking for direction from the whole team to frame this correctly because I feel that by removing all barriers to adoption is Marketing.

(PS Derek is a Facebook friend and I have some other Accessibility friends out there who might lend some sage advice)


All the best,

Jay

That’s another reason for the development of contexts and the clear separation of MODx into core framework and components. Let me explain...

By putting all of the application logic in the xPDO model in the core of the new MODx, and connecting to this model from the "manager" context via the new "connector" context, you can now implement any context to be a management interface by simply reusing these connectors and providing a simple request handling class (which you can customize by context).

In other words, all that is in the manager/ directory is a UI being constructed to provide "views" into the model, and any logic specific to those views, including how they are being templated or presented is encapsulated in the manager/ context. The intention of this separation of manager and connectors, in combination with the new component packaging (aka transport packages) is to provide the facilities for others to more easily develop custom, redistributable content management interfaces. This could include interfaces targeted at and optimized for specific devices, or a generic 508-compliant interface.

We chose ExtJS and Smarty for the default implementation as an example of how you could build these views using specific 3rd-party libraries of your choice. As another example, I originally had the new core working alongside the existing manager code, using it only for the front-end rendering; this is what xpdo.org is still running now, and it works wonderfully with the legacy manager code in the back-end and the new core on the front.

IMHO, this total separation of the core framework from the views into it (be they back-end or front-end interfaces) is critical to making MODx a viable solution in the long-term. There is too much instability in not only the Javascript framework world, but the PHP framework world for us to expect to be anything more than a great idea for the next generation of innovations to use as a model on which to build their own success. I’d rather focus on keeping MODx itself agile and relevant to the emerging ideas. And I have great faith that we are on the right path.

Ahh, the power of contexts again. I will need to dig in and build on the SVN again. ’

I guess then it might be good to plan to have a fully accessible UI for managment built as an addon then for inclusion or in addition to MODx so that we could address the concerns and inclusion of all potential users.

It makes me think that a MODx Accessibility Project would include an entire build out of the Managment Interface/Context and may not be the role of the core team.

I’d love to hear from other team members on your thoughts and my ideas.

Cheers,

Jay

I would be delighted to work on something without javascript. It’s cute and clever and has its place, but that doesn’t make me like it any better. I always feel like I’m trying to tip-toe across a half-frozen river when I’m using a javascript interface. I have no problem waiting for pages to refresh normally.

If I understand correctly, contexts are something like namespaces. So the manager context is basically a separate but connected module. It would be possible to create a totally different manager context, but it could use the same function names, variable names, etc, as well as access the same database.

Also if I understand correctly, it should not be necessary to completely rewrite the manager. If the manager is designed with the mvc model, it should be possible to simply rewrite the v part of the model. The current 097 view is the extjs interface. The model is the database, and the controller is the queries that the view calls for and then displays the returned data. Now if all of this is done as I understand it’s supposed to be, one should be able to simply write another view interface that utilizes the same controller calls to get the desired data. Is this sort of modularity possible under the present circumstances? Or am I way out in left field somewhere picking daisies?

Yes, that’s pretty much it Susan, except the controllers would be what you implement to help create your views and would be custom for the manager interface you create. The reuse happens at the connectors, which are used to gain secure access to the processors (app logic) that reside in the model.

Also, their not exactly like namespaces as they do not allow classes of the same name to be used in the same request (this is a limitation of PHP until 5.3), but they effectively could be used to isolate activity where classes might otherwise conflict.

Jay, I love the idea of a MODx Accessibility Project !
I’ll point this thread to Perrine as she is a trained accessibility expert.

About contexts : the technical explanations really helps understanding how things are built and will work, thanks !
I can certainly see how a MVC model is a great helper in building interface. I have been tweaking ActiveCollab 1.0 backend for instance and this MVC stuff is actually starting to make sense to me.

But from what Jason says, I’d lean toward 0.9.7 going a further than "simple" MVC, I have been reading with interrest about the relationship between xPDO and Smarty. Not sure I understand this yet but the above explanations help

This sounds like a relatively simple (possibly time consuming) project to build out a context in HTML/CSS that is 100% (or near accessible).

Reading an article from Roger Johansson "You cannot rely on JavaScript" he points out the fact that in some cases JS won’t function as expected. There are possible unpredictabilities that will limit or stop the function of applications that rely on them.

So I guess that accessiblity is not the only factor. There are various considerations and I want to make sure that we are looking at all aspects of the UI that ships with 097 to ensure the greatest uptake and least resistance from those who wish to deploy it.

It won’t be necessary to ship all forms with the release bundle but be at least able to deliver a simple solution for common user scenarios that deviate from the JS enabled/Latest Browser scenario.

I look forward to hearing from Perrine and Ryan on this further. I think there is more here than just accessibility but it is a start.

Cheers,

Jay

This accessibility project needs to become an official MODx Core Extension project so that whoever is involved in the development can work closely with the core team to make this happen without unwanted compromises. There will likely be spots that need refactoring in the core to make the integration work 100% but doing this is what will make it possible and desirable for other developers to attempt similar projects on their own.

We’ll talk about distribution of additional contexts like this and how a core distribition featuring the 508-compliant manager instead of the ExtJS one is a trivial task, but I feel confident that our ExtJS 2.0-based manager is going to attract as many curious new folk as it will prevent adoption by those needing a CMS with a 100%-accessible management interface. I just don’t think we’d ever keep the power-user happy with such an interface and likely spend most of our lives trying to make a decent 508-compliant interface that presented a rich-experience and degraded properly based on the client device.

BTW, this is something we will be dealing with post-release, because I do not want to hold up the release of the 0.9.7 core framework and default manager interface any more than it already has been.

Quote from: OpenGeek at Feb 24, 2008, 05:05 PM

This accessibility project needs to become an official MODx Core Extension project so that whoever is involved in the development can work closely with the core team to make this happen with unwanted compromises. There will likely be spots that need refactoring in the core to make the integration work 100% but doing this is what will make it possible and desirable for other developers to attempt similar projects on their own.

Absolutely! I couldn’t see it any other way.

Quote from: OpenGeek at Feb 24, 2008, 05:05 PM

I just don’t think we’d ever keep the power-user happy with such an interface and likely spend most of our lives trying to make a decent 508-compliant interface that presented a rich-experience and degraded properly based on the client device.

Nor do I think we should try. I think that the Extension must be the way to go and that for people who will need to have accessibility, they will be told that they should use it.
Quote from: OpenGeek at Feb 24, 2008, 05:05 PM

BTW, this is something we will be dealing with post-release, because I do not want to hold up the release of the 0.9.7 core framework and default manager interface any more than it already has been.

Agreed. I think that we should announce the project in conjunction with the beta with a set of goals and a roadmap discussing that while 097 will not be accessible OOTB upon release that it is a priority (for some) and that a solution is coming.

I am just happy that I brought this up and that we can start thinking about it. Don’t hesitate to calm me down if I get too excited. I am sure I am having some new member fits right now.

Thanks Jason

Jay