I'll never forget my first HTML class in college. It was 2006 and our professor, Chris Rhode, had the foresight to see accessibility on the web in the forgotten state it is today. Chris knew we had WYSIWYG apps like Adobe Dreamweaver (actually it was Macromedia back then) on our lab machines. We were eager to use these apps; so he had them locked down. Forced to write all our assignments in Notepad or TextEdit, we learned to author each character of our HTML assignments ourselves. Chris knew authorship is everything. He saw the days when Web Developers would no longer author the HTML that governs the experience of their users and made sure each of his students graduated with a conviction to fight against such a progressive decay of the web. Chris taught his students that accessibility is water and we are all as equally in need of as we are deserving of it.
Looking back, I realize Chris taught me the most important rule of web design; to start with HTML–first. After graduating Chris' courses I entered the industry to build fullscreen, highly interactive and award–winning Flash sites. Each of these Flash sites had a fully semantic and accessible HTML underneath that like the foundation of a building was built first. You see I was taught that JavaScript and Flash should only be used to enhance, not author, the DOM that your experience consists of. No exceptions. I took this to heart because Chris instilled upon us a sense of ethics. With great power comes great responsibility and as you obtain the power of publishing to the web it is important you architect it ethically so that not just every person but every user can use it.
In 2007 Chris witnessed me design and publish to the homepage of nike.com as an intern. He saw me win a Rosey Award for being on the nike6.com team that same year then win another Rosey Award for leading development on the best site under $50,000 Initial Production the next year. All four of the developers on the award–winning team I was a part of at NemoHQ graduated from Chris' courses. It was no coincidence why we were winning awards left and right. While the experiences we delivered were enhanced as highly interactive Flash content, the "flashiness" wasn't entirely what made us stand out against the rest of the industry. There was a lot of that going on at the time. When put to the test of screen readers, search engines, and even mobile access these experiences stayed accessible and that gave us a noteworthy edge above the competition. Our peers noticed we were architected the web, not just publishing to it.
In 2009 I returned to the Art Institute of Portland, this time as a Professor, to teach students the principles Chris taught me. The students I had a pleasure of instructing have gone on to build amazing award–winning and accessible experiences. It's so great to see that they are capable of progressively enhancing their experiences, however wild they may be, from a semantic HTML layer. Today I am a Thinkful Mentor and any student I spend so much as an hour with comes away knowing they will architect the web responsibly and not simply publish to it. They will understand that accessibility is water and the experiences they author will be oases within a desert of inaccessibility. As they enter an industry where technology and access to technology is becoming a part of people's daily lives, they will understand the importance of progressive enhancement.
So who's responsibility is accessibility anyways? Look, it isn't a client's responsibility to request accessibility when they come to you for your expertise anymore than it is a property owner's responsibility to request for an architect to construct a building up to code. It is expected of you as a professional. I'm pleased that every experience I contributed to has considered all users on at least some level. Well, up until a certain point anyways. I've worked tireless to live out the principles Chris instilled upon his students but I fear if he knew my level of involvement in the MODX project over the past several years he would be perplexed by my failure to bring accessibility into the MODX platform.
I've been wanting to break MODX for everyone since I first discovered MODX 2.0.8 in 2011. I was working for some incredible designers at the time and just like they require control over every pixel of their design I needed control over every character of the website. I needed this control to bring their designs to life. Needless to say, when I discovered how MODX allows you to freely author websites and organize content, myself and my Art Director at the time, were sold on using it to power our websites. Using MODX quickly became such a dream the thought of not being able to use MODX for any reason became a nightmare. The first website David Nakamoto and I built with MODX won Communication Arts Site of the Month and I had no idea what I was doing. There was one gripe we both had though, the Manager interface itself had room for improvement.
Since 2.0.8 the Manager interface has improved greatly. MODX 2.3 brought an updated UI that is much easier on the eye, but not much easier on the user. While it did reorganize some of the features to make it a more comfortable experience for end users, MODX 2.3 did not make many improvements in the area of responsive design or accessibility. This is because doing so is tricky without making breaking changes. The Manager interface is authored and governed by an outdated and opinionated JavaScript framework which is short for ExtJS. ExtJS has held the MODX Revolution manager interface back from actualizing the experience it could bring to end users. In order to create something truly accessible ExtJS needs to walk the plank and the reimagined experience needs to be architected HTML–first from the beginning. No exceptions. Unfortunately ExtJS isn't slated to be removed in MODX 3.x and we aren't sure what the project maintainers' plans are for a 4.x or 5.x. That brings us to MODX Next, a full rewrite the community has been hearing chatter about since 2012. Without a MODX Next Roadmap to design for we've found ourselves wanting to be prepared for whatever amazing changes may be coming to the MODX platform. We've done this by taking time this year to explore how we define what accessibility means to us at modmore. Let's have a look back at some of things we realized and actualized in 2015.
All Users are Disabled
We all lack abilities and are thus disabled relative to the context of the devices we access experiences through. You may not be physically impaired but the last time you used a touch device could you right click? Your abilities are not just relative to yourself; they are also relative to the device you access experiences through. If I'm working on a MODX site on a desktop using the default theme and then I go to lunch and bring my mobile device I'm still the same person but now I am a different user who relies more heavily on accessibility considerations. We have come to realize the importance of understanding that there are people and there are users and any given person can be a number of users throughout the day. For this reason I feel accessibility considerations should be submitting back to the core of MODX and make use of configurable System Settings.
Users are the Core
For software to be considered a first-class citizen of the accessibility world it must not segregate users by demoting its own core. It is important to invest back into the core of MODX rather than an opt–in theme. The concept of accessibility only having a place in an a11y theme and not the default theme is segregation. It implies that there are "those people" that need accessibility, and they will switch themes, and then there is the rest of us. This ideology insults equal access. It goes against the grain of accessibility.
Siri isn't only enabled for blind users because it is an accessibility feature that is useful to anyone. iOS doesn't have a separate binary for "those people". You go into settings and find the same accessibility settings as everyone else. This is because the eagle-eyed user on a road trip may have just as much use for the ability to listen to articles read articles aloud as the blind do on a daily basis. Europe doesn't print specific Euro bills for blind users. Everybody uses the same bills and the accessibility considerations made for the blind help sighted users as well when they are sorting or feeling for a specific bill. That is accessibility done right. It works out well for everyone in the end. Accessibility should be baked in from the beginning and never looked at as features applicable to "those people".
We have reached out and are pleased to see that there are some issues to port certain improvements made in the a11y theme back to the default theme.
While in Munich for MODXpo 2015 Ryan and I were walking around downtown with some other MODXpo attendees and I got an emergency email from one of my clients that the contact form on her website wasn't working. All I needed to do was update one line of one chunk but trying to navigate to the Chunk and make the change took me thirty minutes to do because the interface was so unusable. As we enjoyed a few liters at the Beer Garden that evening I found myself thinking there must be something we can do to at least make the default 2.x theme less un–usable. A few days later I submitted a pull request to make the default 2.x manager theme more mobile friendly. Now it took some pretty nasty and specific CSS selectors and lots of !important overrides but the end result is a manager theme that doesn't go out of it's way to get in your way.
A More Friendly Mobile Manager
MODX 2.3 brought a major overhaul to the manager interface. The Pull Request targeting MODX 2.5 that uses some styling hacks to override the inline styles of ExtJS has been merged! These hacks bring some mobile friendly considerations but there are still problem areas such as right clicks and hover menus that have yet to be addressed.
Discuss Accessibility at MODX.org
We'd like to invite the MODX Community to discuss accessibility and how it relates to the present and future versions of MODX so we created an #a11y channel at MODX.org. Hop in the channel and let us know your thoughts and discoveries today!
HTML–first Commerce
Mark has been leading development on an all–new Extra called Commerce. Commerce is a fully extendable solution for selling online with MODX and is coming early 2016. We are pleased to announce that the admin panel is being developed HTML–first. This allows Commerce to be future forward and capable of integrating with both current and future versions of MODX.
Eureka Media Browser
Redactor 2.0 features a new and experimental Media Browser called Eureka. We made sure to develop Eureka to be mobile first, responsive, HTML–first, and accessible to screen readers. Check out a preview of using Eureka with OS X VoiceOver below.
Try Eureka out yourself on our demo page. I would love to bring Eureka to all MODX users by creating a standalone Eureka package that adds the Media Browser to the MODX Manager itself, not just Redactor but I could use some help. Let me know if you are interested in contributing.
Markdown Editing in ContentBlocks
Not only is markdown a convenient way to author HTML but its syntax has accessibility considerations as well. With Blockdown we have added the distraction free epiceditor experience to ContentBlocks. Blockdown is opensource and available on Github.
Bonsai Responsive Tree
Back in October of 2013 I started working on a PoC of a jQuery powered responsive tree. At that time I thought this could be a helpful component to use when creating a touch friendly and responsive MODX Manager. I've since found myself favoring another component to solve this however I still think that Bonsai has its place so I've decided to dust it off by committing to a Roadmap to add features like CSS Scroll Snap Points and Framework–Agnostic–Asynchronous–Enhancements.
Yes, MAM
In early 2015 I began actualizing some concepts for a "More Accessible Manager". I've coined this project the MAM PoCs and they are now hosted on GitHub pages. Have a look and let us know what you think by joining the discussion in Gitter.
A More Accessible Rich–Text Experience
Back when I was sprinting on our Redactor 2.0 release Redactor 2.0 wasn't the only thing I was building. I was also building a standing desk out of solid bamboo. This desk took me so long to finish I wound up working out of my Uncle's wood shop for several months as I finished the polishing touches. This involved working out in the unheated wood shop throughout a cold and wet Humboldt winter. I'd often spend my days tending to the ranch and the horses boarded there so my coding took place at night when it was especially cold and wet. The first hour of my shift would involve getting a nice fire going in the amazing antique wood–stove pictured below.
As part of an effort to stay productive while getting a fire going each night I found myself relying on things like OS X VoiceOver so that I could listen to, rather than read, the web. I also relied on zoom features so that I could read text from 20ft away as I tended to the stove. Inspired by my newfound contextual change in abilities, I made sure to bake several usability considerations into our Redactor Plugins. For example, the contrast plugin allows users to "invert" the editor colors. This accommodates users with particular eye conditions and night–owls looking for a dimmer screen alike. The download plugin makes it easy to download the content as a file so that users can make changes outside of the Redactor experience more easily. The speek plugin adds a toolbar to read the editor content aloud and makes use of the HTML5 Speech Synthesis API to offer configurable voices. The zoom plugin adds a keyboard shortcut to enlarge and decrease font size within the content area so you can dust off the wireless keyboard and edit content while couch surfing.
Markup.tips
In early 2015 I launched a personal project over at Markup.tips. Markup.tips is another website about website parts where you will find tools & tips to help you build your next web experience. This is an on–going project but to date I've been excited to publish several progressively enhanced web components that I think may be useful for an HTML–first manager. For example, the main navigation component is a Github inspired browser that lets you asynchronously traverse through folders of content. With a sticky search–bar below, this component was born out of my exploration for a responsive and mobile friendly alternative to the Resource Tree in 2.x. I've also published a jQuery plugin makes it incredibly simple to configure how your markup is read. This is useful if you are looking to create audible components that do not rely on screen readers such as JAWS. At Markup.tips we use jquery.speakable.js to make blog posts configured to be read aloud with the click of a button.
The System Settings page in MODX 2.x is another tricky experience to make accessible. That is why I'm excited to share an accessible settings table that makes clever use of progressive enhancement, the CSS :focus selector, and colspan to display each setting's associated form beneath the setting itself rather than in a modal window. This allows users to easily tab through the entire table to update settings, even if they don't have JavaScript enabled. Markup.tips also explores the benefits of using localStorage to allow users to configure their font face, font size, contrast, and speech settings on a Configurations Pages. I think this is a great example of how JavaScript can be used to enhance, rather than decay accessibility.
Web Guidelines
I've also started authoring some basic Web Guidelines to share best practices that I have found useful when building any web based experience. These guidelines mainly focus on making pages accessible, audible, configurable, enhanceable, legible, optimal, and usable. They are very much a work in progress and are being authored on Github so anyone can contribute and watch!
MIG Guidelines
I've branched off the Web Guidelines to begin drafting some similar guidelines but for creating Manager Interfaces. They are a work in progress available at this branch. I'm excited to explore the possibilities of creating Framework Agnostic APIs along with other concepts there.
Conclusion
To acknowledge that there are many who either cannot access the MODX editing experience or choose more user friendly alternatives is a tough pill to swallow. While we are pleased with some of the progress made this year, the MODX core remains inherently inaccessible. Whether this is due to compromised physical or contextual abilities, we want to bring the MODX experience to everyone without compromise. But what is the plan?
MODX is an incredible tool. The creative freedom MODX brings makes it arguably the best open source software for generating not just HTML markup but any other text format. Ironically, the HTML of the Manager experience is not authored freely by HTML Designers. As of this writing, it remains unclear when the HTML5 doctype will be allowed within the MODX Manager. MODX is arguably the best preprocessor of HTML and yet we have repeatedly and collectively failed as a community to embrace HTML within our tech stack. The MODX project represents the fight for creative freedom within an industry willing to compromise but it is time we broaden that fight to include how we author the manager experience as well. Let us bring creative freedom into the core Manager experience and show the world that working with MODX can be an accessible and usable experience for all. Let us make breaking changes to make this incredible tool we have all come to know and love not just available to all people but to all users. While I'm confident the MODX Community can accomplish anything it collectively puts its mind too, I think we need to formulate a roadmap supported by specifications and guidelines for how we will prevent ourselves from suffering technical debt the next time around. We must be cautious not to make similar mistakes in a new way.
With the proper irrigation, I am certain we can make the next MODX an empowering authoring experience that is accessible to all users. What do you think? How would you like to see the MODX platform re-imagined? Please share your thoughts and be part of building a more accessible authoring tool for the countless web authors relying on us to do so.