Accessibility Mandate

[jpdevries]

View Markdown preview online

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.

[Mark-H]

For the recommendation I'd reiterate the goal of WCAG level 2 compliance in the recommendation content at the start; that's the most important thing. The summary is perfect, the remainder of the recommendation sort of dilutes the point.

Perhaps aside from being clear about requiring WCAG2 in new or updated code in the manager frontend, perhaps there's something we can discuss about how the core integrators deal with this. As we don't have a team of accessibility experts, if the existing team of integrators can be educated as to how to test for compliance, that would go a long way to making sure this actually gets tested. Collecting a list of accessibility mentors and other resources would be useful.

Alternatively we could consider setting up automated tests similar to phpunit, but I'm not sure how feasible that is given accessibility can be subjective.

Not sure how much of that should be in the recommendation, but before this recommendation is accepted I think we should at least have a board discussion about how it could be enforced and make sure there's buy-in from relevant parties.

[jpdevries]

Alternatively we could consider setting up automated tests similar to phpunit, but I'm not sure how feasible that is given accessibility can be subjective.

Karl Groves hit on this at the Fronteers meetup in Amsterdam a few weeks ago. I forgot the exact quote, but he basically said a11y automation testing tools are really great at flagging errors and warnings, but they'll never tell you whether or not something has "good accessibility". You can test if the color contrast ratios are ok, but whether or not it is inclusively designed is subjective.

That said, there are definitely some things that could be worked into the build process. Job's talk at the same meetup was on testing and he recommended doing things like having a limited amount of a11y errors and warnings show up in your development build (watch tasks) so you can kind of keep an eye on it. And then in your preflight build you show all the warning and errors and maybe even let some errors be fatal and hold up the build.

Not sure how much of that should be in the recommendation, but before this recommendation is accepted I think we should at least have a board discussion about how it could be enforced and make sure there's buy-in from relevant parties.

I agree. I still have questions myself. Mostly about how something is subjectively given an a11y stamp of approval. It isn't just about unit tests and even WCAG (the WordPress community has an interesting article on how WCAG is written for web pages and doesn't necessarily have the same context as a web app interface).

I think it would be great if we could organize community members who have a disability and/or experience with assistive technology to do some user testing. One of the things I've learned about accessibility lately is that you don't want to over think it. Sometimes something may seem really clever, like changing the label text of a checkbox based on if it is checked (never do this), but they wind up being anti patterns that hurt accessibility. The second most common feedback in Heydon's Screen Reader User survey was that too much ARIA can ruin a page, just like over seasoning a dish.

[jpdevries]

For the recommendation I'd reiterate the goal of WCAG level 2 compliance in the recommendation content at the start; that's the most important thing

Since attending CSUN '17 and meeting member of the working group, to keep recommendations future proof, I've decided to remove all references to any specific version of accessibility guidelines. We can still reiterate the goals of guidelines, but I want to stay aware from referencing specific versions. We should just say something like "most recent accessibility guidelines".

WCAG 2.0 Level AA is the standard now, but so we will have WCAG 2.1 (they are dropping the W as they won't just apply to web anymore) and 3.0 is already being worked on and codenamed Silver.

[ghost]

I would like to help with this, I can spend the time to study the standards and recommendations, and can also use SiteSort program to examine the pages once there is something to look at.

[jpdevries]

Thanks @sottwell. I'm so excited you would like to help!

[jpdevries]

Some info on how WordPress audits theme accessibility
https://twitter.com/webaxe/status/878598825073664000

[jpdevries]

Some feedback from cielt on A11ySlackers
https://web-a11y.slack.com/archives/C042TSFGN/p1498675767559949

hi @jpdevries: glad MODX is taking this step 👍 from a quick read, there are a couple of items i think bear elaborating on, namely:

While MODX has acknowledged the importance of accessibility, to date the project hasn’t been able to accurately define accessibility – let alone a path towards it. It would be unrealistic to expect MODX Contributors to become accessibility experts capable of following the latest accessibility success criteria and other best practices over night. This is why supporting documentation, examples, and human resources will be needed to make accessibility best practices accessible to contributors.

is this document a place in which it makes sense to define accessibility (since the need to do so was made plain) and / or mention some guidelines (e.g., WCAG) to which software makers should aspire? for myself (especially if i am more in the novice category), specifics that define web a11y would be enormously helpful.

And re the aforementioned “supporting documentation, examples, and human resources” the intent to provide support in individuals’ efforts to build a11y into the software is clear, but would this be a place in which some of these resources could be named? the document goes on at some length about certified MODX Accessibility Advisors (what their role is, the importance of access) but it seems that, even before an expert need be called in, some resources, readily available and free of cost, could go a long ways toward enabling devs and product teams to understand, build and test for a11y. would this be a place to list out some links to guidelines, tutorials, examples, testing software, etc.?

Just a thought from the perspective of someone who is still trying to learn and has found it helpful to talk about a11y in concrete terms re:

• what it means for a site / app to be accessible (e.g., provides as semantic / clear / operable a screen reader experience as possible; allows users to interact with the entire app using a keyboard only; includes captions / transcripts if there is video content, etc.)
• what kinds of design and dev decisions will ensure accessible UX in a product.

Getting access to an accessibility advisor sounds amazing, but even before that point it seems worth highlighting that many resources exist that will help folks equip themselves with knowledge to start building and testing for a11y. Maybe worth spending some time on these bits? Good luck!

https://web-a11y.slack.com/archives/C042TSFGN/p1498751564643459?thread_ts=1498675767.559949&cid=C042TSFGN
Good stuff, @jpdevries! Couple of thoughts:

• if it’s potentially useful, i would encourage you to include something about what it means to be accessible (and linking to a more substantial document / section of a document) would be fine. but this will probably inform any further info about how to audit / build / test for a11y
• about which, yes, it is tricky to define what this means, but i think that may be what you and your board are helping to do. i think in this sort of leadership role for the project, you have a say in what a11y standards you would like your devs / product folks to strive for. and, once you do, it will be important to articulate this in specific terms because all of the building, testing, etc. will be in response to these standards as a kind of goal. Not sure if WordPress has documentation for their standards, but i would think so — definitely a good resource to check / learn from!

[jpdevries]

Some great feedback on the Forums
https://forums.modx.com/thread/102411/accessibility-mandate#dis-post-553154

@christianseel some German documentation is mentioned that hasn't been translated to English yet