mab-recommendations
mab-recommendations copied to clipboard
modxcms
🌐 Accessible Setup ♿️
The MODX Advisory Board recommends, in an effort to make an accessible first impression, the setup process will expose accessibility preferences during the installation process. 🔧🤘
Voting
Only MODX Board Members may cast a vote. The Chief Architect and Chief Maintainer of the MODX Leadership are also granted one vote each. Votes may not be edited after they have been cast.
More info can be found in the voting protocol.
Some really interesting info, and conversation, about success criteria (cognitive) for login https://github.com/w3c/wcag21/issues/23#issuecomment-294915100
A mechanism is available to retrieve or reset authentication that does not require the user's ability to memorize or copy information or character strings; perform calculations, such as including correctly identifying and entering numbers and letters from a character string; see; hear or speak.
Out of progress we made in Malta 🇲🇹, a concept for this is being actively developed here: https://github.com/jpdevries/modx-setup#modx-setup
Demo: https://jpdevries.github.io/modx-setup/
Forum: https://forums.modx.com/thread/102211/new-setup-installer-w-a11y-preferences#dis-post-550879
It focuses not only on accessibility preferences like legibility, motor, and contrast being available front and center...but also heavily focuses on "cognitively disabled" users by reimagining the unboxing process. By cognitively disabled users, I don't just mean cognitively disabled persons. Someone who has a Masters Degree in Computer Science and just found out what MODX is 5 minutes ago, and is now trying to install it, is contextually a cognitively disabled MODX user. They don't know what MODX Extras are, let alone the right ones they need to install to get what they want done. So now with this concept, they don't have to anymore.
Expandable Details
This concept also makes use of HTML 5.2 <details> for expandable "more options" components.
For example, most people are fine with this:
but more options are available:
and you don't need to be a server admin that knows what 0644 and 0755 mean anymore, there is a Transmit-style web component that allows you to manage file permissions WYSIWYG.
There's a screencast overview of the new setup proposal https://vimeo.com/218397030
~12min in if you want to jump straight to the "package wizard" feature, which is now entirely fed by a REST API so that a "list" of packages is not distributed with the MODX core.
@christianseel can you mark this Please Review? I think it is ready for a vote, if not lets discuss
Anyone can change the label 😁
What I'd like to know before this goes to a vote is what these preferences are. To my knowledge there aren't any in MODX right now, so there's nothing to be configured. Should we first focus on some of the options you mention in the recommendation before thinking about adding them to the setup?
To my knowledge there aren't any in MODX right now, so there's nothing to be configured
That's not entirely true, they just aren't labeled under accessibility. The ability to disabled drag n' drop for example is there now and could be considered an a11y preference.
To stay future proof, I don't want the draft to explicitly mention settings or direct references to a particular version guidelines. So for
What I'd like to know before this goes to a vote is what these preferences are
I don't think knowing what the preferences are is necessary. The draft is "we should have relevant a11y preferences exposed during setup" not "here are the preferences we should expose during setup".
Of course the proof of concept I created has ideas for some settings that could be there.
Fair enough. Thanks for the clarification. 😄
Maybe the recommendation itself should be clarified a bit too. I took a stab at rewriting the first couple of paragraphs to be a bit more to the point and states it's a guideline to be followed long term.
If preferences to improve the accessibility of the MODX manager are managed through system settings, these preferences themselves might not be accessible to the user. Whether these preferences relate to contrast, font-size, reduced animations or fully optimised manager themes, if the user is unable of reaching a way to configure such options, to them they might as well not exist.
Therefore, preferences that relate to manager accessibility must also be configurable from the setup. Accessibility preferences may be hidden from view initially and only shown after toggling a button or label, as long the way to show these options is fully accessible and clearly visible. This recommendation is to apply to all future versions of MODX that are not fully accessible out of the box.
Could drop the "...that are not fully accessible out of the box", but I think it makes sense that when we do finally have a fully accessible UI, that providing preferences in the setup should no longer be required.
I think the last two paragraphs of the recommendation, and what is ~crossed out~ could just be removed from the recommendation? (The last paragraph states that what is described in the second to last paragraph is not part of the recommendation, seemingly cancelling each other out.) Git keeps the history, so it can be restored if needed in the future for a different recommendation.
And my final piece of feedback... can we drop the emojis please? I'm all for using emojis in online communication as it can help convey intent beyond text alone, but Recommendations are not the same as a chat where an emoji can clarify if someone is sarcastic or serious. In this case the emojis are distracting from the content, making it harder to take it seriously, which I think is the last thing accessibility needs 😉
Thanks for the edits @Mark-H I worked them in.
Could drop the "...that are not fully accessible out of the box", but I think it makes sense that when we do finally have a fully accessible UI, that providing preferences in the setup should no longer be required.
The preferences aren't just to make the MODX Manager more accessible, but the setup experience as well. Users with accessibility needs benefit from the setup responding to preferences in real time and they may even rely on them to install MODX and get to the manager in the first place. So I think the setup preferences need to be evergreen.
(The last paragraph states that what is described in the second to last paragraph is not part of the recommendation, seemingly cancelling each other out.)
Not exactly. The second to last paragraph is about the ability to choose presets like "I want to install a blog". The package wizard is something else, the ability to granularly choose the specific packages that will be installed. I removed that clarification though.