Community Concerns

Hey Jay,

AFAIK If you support WCAG [1.0] you have to basically support .no-js. If you support WCAG [2.0] you can get away with using script, sort of by progressively enhancing alternate content
http://www.w3.org/TR/WCAG20-TECHS/client-side-script.html#SCR38

According to the guidelines of progressive enhancement, unless ExtJS is enhancing something that is already there, this project may make the Manager $50,000 less painful to use but I still don't understand the basis for considering it #a11y. Let alone "first class" #a11y. I dunno, maybe I'm just making a big deal out of this whole accessibility thing:
http://markup.tips/html-ftw

MODX is arguably the best PHP (hypertext preprocessor) around, so it is ironic that the 2.x project suffers from a lack of consideration for hypertext itself. It's almost like we are all afraid of it for some reason. What gives?

I think we both know accessibility is something I've longed to see in the Manager but it is sad to see the LLC define accessibility with the marketing spin found on a11y.modx.com. Keyboard Navigation, ARIA roles, and focus indication are things that should just inherently exist. They are features that together make accessible and non-accessible pages alike more usable. It feels like the MODX building just finally got written up by the fire martial so now there's a fake cardboard cut out of a wheel chair ramp out back with a sign that says "accessible to all...stay tuned & coming soon!!!". You put some signs up to make things easier to find, and greased some hinges but everybody still can't access the ramp around back; meanwhile the marketing department is out front working an #a11y lemonade stand making claims they don't even seem to understand.

Is this project going to start progressively enhancing markup and drop use of custom components like ExtJS comboboxes over <select>? That alone would make things much more usable and standard.

2.x made the assumption that native browser features would not surpass those of ExtJS (they did) and accessibility doesn't matter (it does). Those assumptions became part of semver for the project. I'm curious to see how the Revo project is going to un-make those decisions without breaking semver.

I really don't think we are talking about the same thing. JP, you are looking at accessibility in a tech way, but this program is about accessibility in a physical way.

The goal of this project is to provide the Modx manager so that people with physical issues can still use the manager. Some people may need everything in 50 point type, others may need sounds to navigate around. That kind of accessibility.

Quote from: nuan88 at Mar 31, 2015, 03:04 AM

I really don't think we are talking about the same thing. JP, you are looking at accessibility in a tech way, but this program is about accessibility in a physical way.

I'm looking at accessibility as it is defined by the web standards community and the WCAG Guidelines; something the MODX project has repeatedly chosen not to do. These are not my opinions, they come straight out of the guidelines. I'm not trying to be a downer, I'm all for making the Manager more usable. Who isn't?

If you didn't start your app in HTML it can be the most usable thing there is but it will never be semantic, or accessible. Just stop. Don't take my word for it? Look into CSS Naked Day. This is why these initiatives exist:
http://markup.tips/css-naked

Usability and accessibility go hand in hand but as I pointed out before making an interface more usable does not inherently make it accessible. Again, these are not my opinions they are definitions.

Choosing ExtJS to power the manager may have been the correct decision but it has proven to be a costly one. Not only in accessibility but in shelf life. If you start your interface with standards it doesn't expire. If your experience is governed by a opinionated and dated framework like ExtJS your hands are tied. The Manager looks like it went through a blender on your smartphone because ExtJS 3.x doesn't even know what media queries are; and it never will.

It's 2015. Web Components are around the corner. Element Queries might not be all that far away after all. A MODX 3.x really could bring creative freedom into the Manager but I think the MODX Community has to collectively decide to stop making the same mistakes. If the MODX project doesn't start the Manager with HTML next time around what is to stop it from needing to crowdsource a major initiative like this just so people can use a web interface?

I voice these concerns because I hope that they will be considered in the context of a 3.x roadmap. I believe MODX really does have the potential to be the best CMS, for anyone but has to stop being afraid of web standards. We can have our cake and eat it too but HTML is the flour and we have to start with it. [ed. note: dinocorn last edited this post 11 years, 5 months ago.]

JP,

I support your sentiments exactly. I agree 100% with starting with HTML first. I'd suggest something like React.js would be a non-starter IMO for the next MODX manager. We can have our cake and eat it too.

Choosing Ext at the time was a critical decision made by someone who was not a front end developer yet needed a front end for the application layer, quickly. We do not need to reflect on how or why that decision got made and all the "could haves" that we can consider. That said, accessibility was not ignored because to ignore it would have been to think about it and decide not to do anything about it. Accessibility wasn't even on the radar and therefore, here we are. I am not laying blame on anyone for that oversight. It's done. Time to sleep in the bed we made. Though some nicer sheets might help.

The current accessibility project is one of solving an immediate pragmatic problem, which is to enable people on the accessibility spectrum to be able to use MODX Revolution today and thus, some of those changes will also make improvements for people of all abilities. Will it be fully WCAG compliant, not at all likely. But people who use assistive technologies to use MODX Manager should be able to use MODX as someone who doesn't use assistive technology. We are in no way suggesting this be the end game. Or this is where we need to stop.

For MODX next, my opinion is to build an the entire interface in HTML and CSS and then add in async and background functions progressively. To speed application interface performance and layer in meaningful UX elements that provide additional depth to the application.

I would be all in on helping start build out a component library (though I think we're premature for the use of web components but should be aware they are coming). To start building out the views and setting forth a set of UI principles for the next version of MODX that will be future proof as the basics were done right, the first time.

I think this specific discussion needs it's own thread if you're game. I'd be more than happy to start on the road to a new project to get interface prototypes and some patterns going so we can create a new, functional, accessible and future proof, design lexicon for modx before we write a single line of code.

Quote from: smashingred at Apr 02, 2015, 09:30 AM

JP,
I support your sentiments exactly. I agree 100% with starting with HTML first. I'd suggest something like React.js would be a non-starter IMO for the next MODX manager. We can have our cake and eat it too.

I think we are in agreement. The a11y.modx.com page is still raising money claiming for first class #a11y software that will be built upon and within the semver restraints of software that didn't think about accessibility at all. If this feat is pulled off, somebody should right a book about it.

I'm used to being the odd-one-out, it's the life of an HTML-advocate. I started my career as a Flash Developer so I've seen the implications of dateable software but even then the flash interfaces we built for clients like Nike6.com were completely #a11y accessible. How? We built them on top of semantic HTML layers. We tested them with JAWS. Fully clickable (and searchable) sites became asynchronous one-page flash sites.

My point is that as a Flash Developer I thought about accessibility because frankly we had no choice. Flash wasn't accessible, so we had to.

Thing is, JavaScript isn't accessible either. While it is considered standard and ok to use that doesn't mean that you shouldn't think at all about the people that don't have it enabled. Is it that hard to use a noscript tag?

Flash died because overnight everyone became disabled; we have these tiny, limited smartphones in our palms now. Did the industry as a whole care about accessibility before? Not really no. Does it now? Nope. Responsive Design to many is just about making it so people that can see and touch things can see and touch things on a small screen.

When I started Markup.tips just a few weeks ago I chose React really just because it was the framework of the day. I really like some things about it, particularly JSX. React and Angular both have really clever ways to empower markup and it is nice to see the industry shifting back towards where it started.

Thing is though, React and Angular are both dateable tools. A few years from now we could be talking about how irrelevant they are. That's why one of the concepts of Markup.tips is JS-drivers. It is admittedly a foolish undertaking because it requires a lot of repetition but the concept is simple. Components should be able to be designed so that they are so HTML heavy, they can be flavored using one of several light drivers without changing the user experience or functionality. In other words I am working on an Angular driver for this simple to do list I created in React. I should be able to switch between the two without the user even knowing.
http://markup.tips/components/creating-an-accessible-to-do-list-powered-by-react.js.html#focus

The main navigation component described here, same thing. Working on multiple drivers.
http://markup.tips/tips/sticking-components-above-the-fold.html#focus

The only reason this is even remotely feasible is

• i spend too much time in front of a computer
• those components are 85% or more HTML

I am starting to realize that accessibility can almost be judged off measuring a component's weight alone. If it is not primarily made of HTML and CSS it probably isn't very accessible. Let's be honest here; measure pretty much any 2.x Manager component. They are close to if not 0% HTML and use little CSS as much of the layout is governed by ExtJS.

If 3.x could support HTML from an API standpoint (standard as well as async forms) it seems like a major win. In conjunction with the ability to create custom manager themes, the LLC wouldn't even need to worry about whether or not it worries (or worried) about accessibility because the community could make other themes that are actually accessible and actually pass all the #a11y tests.

Unless I am mistaken, something like this could not be done in 2.x.
[ed. note: dinocorn last edited this post 11 years, 5 months ago.]

Quote from: dinocorn at Apr 02, 2015, 10:07 AM

Unless I am mistaken, something like this could not be done in 2.x.

Nope.

On the LLC and MODX next. Stay tuned in the coming weeks for changes to how MODX CMS is governed and the projects are managed. MODX LLC will ideally and quickly get dislodged as a bottleneck for progress on the project.

Quote from: smashingred at Apr 02, 2015, 10:20 AM

Quote from: dinocorn at Apr 02, 2015, 10:07 AM

Unless I am mistaken, something like this could not be done in 2.x.

Nope.

On the LLC and MODX next. Stay tuned in the coming weeks for changes to how MODX CMS is governed and the projects are managed. MODX LLC will ideally and quickly get dislodged as a bottleneck for progress on the project.

Glad to hear it Jay. I went out of my way to try to not use MODX recently and just couldn't do it. The way it puts designers in charge of markup that makes up their experiences is *too brilliant* to use anything else. Really, I tried. That said it is tough to sell clients on a non-mobile Manager interface. It is exciting to hear that change is in the air because I still believe this same level of brilliance can exist within the Manager itself. And then MODX wins the internet. [ed. note: dinocorn last edited this post 11 years, 5 months ago.]

Further to our conversation I read this article this AM and it's exactly the mindset and thinking I think we need to approach any new UI in MODX with: http://alistapart.com/article/let-links-be-links

Again, I am thinking a new venue for a discussion on building the foundation for the principles and ideas for a new MODX Manager deserves its own space.

Quote from: smashingred at Apr 03, 2015, 08:04 AM

Further to our conversation I read this article this AM and it's exactly the mindset and thinking I think we need to approach any new UI in MODX with: http://alistapart.com/article/let-links-be-links

Again, I am thinking a new venue for a discussion on building the foundation for the principles and ideas for a new MODX Manager deserves its own space.

Completely agree. It doesn't matter if you are talking about a fullscreen Flash site or a one page Angular app, neither are accessible unless they sit atop HTML. Period. All people must to be able to get into your experience before they can start using it. To the industry, a11y means letting everyone in the building, not an array of ExtJS usability wins. Will keep an eye out for a new thread.

Writing accessible markup can be tricky and making it dynamic often requires an un-opionated backend. I think that is part of the reason many skip over HTML-first design; they know Wordpress won't be able to generate the markup dynamically anyways...

MODX is arguably the best CMS out there at generating a11y HTML so there is no reason for the /manager to be afraid of it. Is there?

Which leads to the question, why can't MODX use MODX to generate Manager pages? Why does it need a separate, mostly hard-coded Manager?

Another thing that has always puzzled me is why, after years of dealing with an obsolete version of the mootools libraries, the Manager was designed to be locked into what rapidly became an obsolete version of the ExtJS library?