MODX Accessibility Forces

The other day Ryan Thrash asked me to help out with making MODX 3 Manager more accessible. That was great news to me. An accessible content management interface will be a huge asset to the accessibility community. There are not many solutions for accessible online editing out there, an accessible MODX backend will really fill a gap.

It is still too early to figure out what has to be done in detail. The good news is that we can start from scratch, implementing accessibility during the design phase, then going forward step by step through development. Best conditions to achieve a good result.

For the time being we should join our forces.

Hello out there, are there any other accessibility people? Or people interested in accessibility? – I would be glad to hear from you. Please feel free to start any discussion or question related to MODX and accessibility.

See you
Brigitte

Since most of us would like to see extjs in the modx3-manager again
This may be interesting:
http://docs.sencha.com/ext-js/4-0/#!/video/17840717

For years I've been longing for an "unobtrusive" Manager that would work without Javascript. That means all links and buttons would normally reload the page with the new forms, fields, etc, but the Javascript would override the link and button action to do its AJAX-y thing. It may be tedious with all the page reloadings (and not even all that much more tedious than it is now since the page has to refresh so much to reload the Tree and the Menu anyway), but it would work.

This is also kind of interesting: http://words.steveklabnik.com/emberjs-and-accessibility.

Ember JS is built on JQuery and Handlebars and should probably be considered for the MODX 3 Manager.

I understand that you guys are interested in new arguments which Javascript framework to rely on, but sorry, I cannot be of much help in this respect. They both may have WAI-ARIA added, which one does it better nobody can tell, the limits will show up during development (the devil is in the details, we say in German).

The point is: WAI-ARIA is not at all ready for use in web apps. Up to now, browsers and screenreaders did a good job in implementing WAI-ARIA landmarks and forms support – a very little part compared to what we would need for web apps built of custom controls. For the time being we should better rely on HTML than WAI-ARIA. HTML has all it takes for accessibility.

Susan made a good point when wanting an “unobtrusive” Manager. You certainly heard of the layer model in standards-conformant web dev:
- HTML is for content and structure
- CSS is for presentation
- Javascript is for behavior
This means of course to avoid script-generated content to the minimum. If we do it like this, accessibility problems will tend to zero – not to forget the design rules given in WCAG, of course.

I can’t wait to do in real

Quote from: Bruno17 at Apr 04, 2013, 04:33 AM

Since most of us would like to see extjs in the modx3-manager again
This may be interesting:
http://docs.sencha.com/ext-js/4-0/#!/video/17840717

I think we need to stop framing the conversation around there being a single JavaScript framework in the MODX 3 Manager. IMO the MODX way would be to ship the core product with web standards that can be progressively enhanced however developers like. AngularJS, React, Ember, every other JavaScript framework or library, all those things have one thing in common: they are compatible with VanillaJS.

So, if we can can go about architecting the front end, and the API, in a more standard way I think we can see a Manager that uses any number of frameworks with direct on the user experience. For example, imagine being able to switch from AngularJS to React without affecting the display and UX of components at all. Imagine being able to use the two together on the same page.