As part of my work, I often find myself spending significant amounts of time trying to determine whether a given module meets all the accessibility criteria. More often than not, flaws are discovered, which leads to more work in order to make the module usable. Many times this is not an easy process, as it involves a lot of research.
I can't help but think that a lot of people go through this process, yet I cannot seem to find a good source of information on which modules might already have been vetted by someone else concerned with accessibility.
I was wondering if there has been any discussion around creating some sort of badge system for evaluating the accessibility compliance of contributed modules. Something akin to the ubiquitous security advisory statements. Great would also be a list of modules that are maintained by people for whom accessibility is a priority and not an afterthought.
Even a set of simple modules that are compliant, would be great to have as a starting point for some things (some modules try to do too much, which makes it difficult to assess).
If this is already in discussion, perhaps someone could point me to where I might find it. I would love to contribute in some form.
Comments
Guidelines?
I think if there are no Drupal module developer guidelines specifically around accessibility, it would be even better for Drupal.org or the Drupal community to post those somewhere for developers to see. The expectations then are clear and hopefully bring forth more accessible modules.
Apple has a good example of documentation for developers about creating apps that are accessible: https://developer.apple.com/ios/human-interface-guidelines/app-architect...
If Drupal has documentation like this, it'd be great to know.
Some documentation available, needs more
We have some, but the D8 developer guide in particular needs more. Contributions welcome!
Tools and best practices (D7)
Creating accessible themes (D7)
User interface standards - some of these have notes about accessibility issues/
Accessibility (D8)
WCAG 2.0 AA
Just glancing at these, it would be great for these, before jumping into specifics, to state that the minimum goal is to meet WCAG 2.0 AA (if that is indeed the minimum goal). It might also be good to mention in the same breath that there are new things on the radar that were discovered as issues after 2.0 was set as a results of technical "advances", e.g., vestibular disorders discovered as an issue once parallax, smooth scrolling, and video behind text became popular.
Charles Belov
Webmaster
San Francisco Municipal Transportation Agency (SFMTA)
Guidelines from the WordPress handbook
The WordPress handbook has a lot of guidance for developers + themers. See Best practices - Make WordPress Accessible and the child pages.
Their guidance is much more extensive than ours. Their outline would be a good starting point for expanding Drupal's accessibility documentation. (Heck, a lot of their actual content would suit us too. I couldn't find specifically what license their documentation uses.)
A moving target
There are problems with a badge for accessibility compliance. Things can change quickly, and formerly-accessible functions can be broken without people noticing.
Way back whenever, there was the #D7AX pledge that maintainers could add to their project pages. I just found it again, and it's been updated for D8: https://groups.drupal.org/node/66323. General info about Drupal accessibility is at https://www.drupal.org/about/features/accessibility.
I get your point, and I agree
I get your point, and I agree with you, however, I think that the solution would be for "Drupal" to establish a standard by which development is to be held. "Open Source" is not a synonym for "Free-for-all". Just as a fast example, look at Apple and the AppStore. You can't just throw together any old thing that happens to run on an Apple Device, and throw it up on the AppStore, and have people download it. There are Standards. Before an app is made available it has to meet established criteria. If it doesn't, it doesn't go up. I realize that Drupal.ORG is a different animal, however even there, they have the... I'll call it the "Production Area", and the "Sandbox Area". We've got the "This project is not covered by Drupal’s security advisory policy." notices. Could we not, in the same manner, have "This project does not meet Drupal's established Accessibility Standard..." notices?
Would there be those who "don't care" and wouldn't follow the standard? Sure. And their projects would be marked as such. Establishing a Standard would be helpful to everyone, as it would allow everybody to be working in the same direction. While I'm not currently developing modules, etc. for Drupal, you can't make me believe that there aren't already standards of various types for Drupal. Things that are to be done in a particular way. With over 40,000 modules alone (not including Themes and Distributions), I can't believe that everybody is just doing their own thing their own way. I know enough about development to know that a project the size of Drupal would be utter chaos without standards in place for its development and progression.
OK, thank you for letting me vent. Stepping off the soapbox now.
Although having such a
Although having such a standard would be great, accessibility is still not completely standardized itself and is constantly changing. Having a standard policy in place I think would need constant updating as the standards themselves change.
It's possible that the Drupal community or accessibility team picks a steadfast moment when they say 'This is the current standard that we are going to go with. Anything that we approve has to follow at LEAST this standard, or it won't be considered accessible.' That way, if the actual guidelines or standards do change, which they will, there isn't a rush to adapt the standards and update thousands of modules to meet the new standards.
With something like that in place though, frequent updating of the drupal standards would still need to be in-place, as for example milestones. Keeping the standards the same for 2-3 years at a time probably isn't a good idea if the guidelines or standards themselves are changing every 6 months.
Just my two cents.
EDIT: Drupal does have standards, but they are coding standards. Tab spacing, comment standards, spacing etc. AFAIK, there are no accessibility standards that are monitored and checked, nor would there be an easy way to do so. They have tests that check the modules to ensure that coding standards are followed, but not sure the same types of tests could be done automatically. The only way it could be done is a team manually reviewing every module for code, or allowing the developer themselves to mark it as 'accessible' (Which may not always be the case, but they will do it anyways).
Vetting on the Apple App
Vetting on the Apple App Store happens because Apple can pay lots of engineer-reviewers. Our community volunteers are like 1% of that level of availability.
I can. It's really common for for people using any open source software to make bug fixes privately, and then say done. Filing a public bug report, patch, or pull-request, adds an extra half-hour after you;ve fixed your own website. A huge part of open-source advocacy is convincing people that spending that extra half hour is in their own interest. I just assume lots of organizations make private accessibility tweaks without reporting issues, too.
Discussed informally but no concrete plan yet.
Thanks for raising this. It has been mentioned before - discussed informally on Slack, and in the hallway at events. But it hasn't turned into an actionable plan as yet.
A good first step would be to encourage anyone vetting contrib modules to post their findings in the module's issue queue. That way (a) other people can at least see what other reviewers have found, and (b) the module maintainer is alerted to issues. Likewise for themes, and maybe profiles and distros too. Tagging issues with "accessibility" will help the existing accessibility contributors to find them.
As for a badge - well that would need some agreed level of review, so it's clear what the badge represents. It would also need quite a lot of volunteer effort and momentum, to achieve a reasonable level of coverage, and relevance. The biggest challenge comes from the fact that the Drupal accessiblity "team" is pretty small. Too small to sustain a formal ongoing review process, in my view.
The Wordpress community has carried this out for a good number of their themes, but I'm not sure how formal their method is, or whether the accessibility-vetted status has any official weight. It would be good to learn more about how they do it. Their emphasis seems to be on reviewing themes, whereas we probably want to be more focused on modules.
@andrewmcpherson The
@andrewmcpherson
The wordpress accessibility team, or 'Lets make wordpress accessible' is a community group of members, but have been officially acknowledged by the wordpress core developers. The items that are marked as 'accessible ready', although not assigned by an official wordpress core developer, still hold some pretty significant weight in the fact that it's been vetted by an acknowledged group of members, not just anybody.
AFAIK, and from what I remember of Wordpress, only the team members can mark the items as 'accessible ready', although others can report on issues or fix issues. I think it's essentially up to the team itself to review and mark it as 'compliant'.
Thanks. Sounds like the
Thanks. Sounds like the "accessible ready" badge there amounts to "a vetted accessibility team member has looked at this". That's a reasonable level of confidence, so long as they're choosy who gets that role. Doesn;t solve the issue about needing a lot of volunteer time though.
Half-way steps
There are a couple of steps we could take, which fall in between "reviewers leave stuff for others to find" and a formal "accessibility vetted" process.
Accessibility experts in the community can say they are willing to provide a review and/or tech advice for contrib modules and themers. That's something we might be able to manage with the small numbers of active contributors we currently have, subject to people having available time(!). The tricky part is how we promote this, so people will know who to ask.
A few years ago, the usability contributors used to hold a "usability happy hour" on IRC every few weeks. The idea was that contrib maintainers could get a quick expert walk-through. This could be a good way to attract more accessibility participants and contributors in the community, because it'll be fun to hangout and review and learn stuff together, right?
The maintainers accessibility pledge idea is good, but needs promoting more.
From time to time we see a rush of new issues being filed for Drupal core in a short space of time, by new user accounts. Typically these refer to section 508, and it's clear that they're doing paid work to review Drupal accessibility. I try to respond to these as quickly as I can, because (a) we've had some actionable issues we can fix, and (b) in many other cases I know we already have a plan underway for a particular issue. I'd love to bring these contributors further into the project, but often all I know is a username. I suspect some are working for a testing company, who would benefit from building a profile in the Drupal community.
Note, I'm thinking these ideas are about providing support for people who are already contributing to the project, like contrib maintainers, because we trust they'll "pay it forward" somehow. As for providing on-request reviews to evaluators outside the community... well I'd want to know they were going to get involved and give something back to the community. In general they should be paying professionals to review stuff for them.
(Aside: module and theme maintainers have to ask nicely. Just sayin'.)
I agree that already
I agree that already maintained or contributed modules/themes would benefit from this, but I do think that new contribs also need to have some guideance going forward.
If new developers or contribs don't have any guidance on guidelines and are just relying on others to review them, I think the community will just be spinning it's wheels. If something can be put in place to help new contribs or developers start with accessibility in mind to begin with, I think eventually the need for vast community review would be reduced, resulting in only reported issues coming up.
I do believe some
I do believe some documentation or guidelines like outlined by apple is a great first start. If enough people could pool together to develop something like that, it would give a great start for the community to jump in and help with reviewing things for accessibility.
Is it possible that the accessibility team focuses some of their efforts on establishing some documentation/guidelines that will help the community review and critique modules and themes that are put on the Drupal community? Perhaps another issue status like 'needs accessibility work' or 'needs accessibility review' to help accessibility people quickly find things that need reviewed or fixed.
I would be interested in helping put something like that together, if enough of the Drupal higher-ups and officers were interested in doing that.
Compliance.
There are plenty of compliance standards. The Drupal community just has to make the choice to adopt them. It's frustrating having to rework output from contributed modules to make them compliant. Some of the big no-nos are amazingly ubiquitous. For example, href=# is not compliant its baked into almost everything.
https://www.w3.org/WAI/WCAG20/quickref/
Withhold your right to be critical while pursuing compliance
A toilet in your kitchen is "compliant" with building codes if it has sufficient distance in front of it. But the user experience is awful.
Standards are a guide. They were written at a time in the past and the authors attempted to predict the future. As folks who now live in the future, we have a responsibility to interpret those standards. They aren't rules, they are guides. For instance, href=# is fine in practice. When we force developers through hoops, they'll find new ways to break the UI.
Prioritize good user experiences, not conformance.
The only problem is that In
The only problem is that In 2017, plaintiffs filed at least 814 lawsuits based on the ADA standards. Some places like the university that I work for have no choice but to adhere to these standards. There are quite a few ways that basic compliance could be baked in without getting in the way of design. I for one have a hard time with many of the compliance recommendations that I find make UX worse for everyone else, but some of the request especially around properly forming links for readers and pretty reasonable.
I agree that UX should be the
I agree that UX should be the primary consideration. Clearly, the worst UX results when the information that we try to transfer is inaccessible for whatever reason.
I don't believe that WCAG rules interfere with good UX, nor do I believe that they are a guarantee for good UX, but they do provide a workable baseline for MVP. Like you, I believe we should aim to go beyond WCAG, and provide a good experience no matter on which device users might try to access our information. The only way to be better than just compliant is to be compliant to begin with.
Your compliant toilet might not be the best experience, but it is still better than one you cannot use at all.
The Ultimate Question
That really is the big question then. Would you rather: a) have a toilet with a better UX in its own bathroom, but not really compliant with code or truly functional; or b) have a toilet that is compliant with all necessary codes, but can only go in the kitchen with the food while everyone else's toilet gets to be in their own bathroom?
I think the scenario is more
I think the scenario is more like: we need a a functioning toilet (really badly).
Do we choose the one we can use or the one that has its lid nailed shut but looks like the kind of parking space your bottom might like to spend the rest of its life on.
Let's choose the one we can use and improve it, but let us make the choice more obvious.
Again, I don't think accessibility rules prevent good UX, in the same way that coding standards don't prevent functional code.
It should be noted that
It should be noted that accessibility should never be sacrificed for user experience. If anything user experience should be sacrificed for accessibility. Just between the two is that user experience affect everybody whereas accessibility only affects certain people.
This is an endless well. The
This is an endless well. The contrast needed by some gives others a headache. The layout that makes it easier for one person makes it harder for another. When you account for learning and cognition issues you can quickly find your accessibility needs working against each other. Good UI/UX shouldn't be in conflict with accessibility, but you can quickly get there when your design focus ignores the largest portion of your audience. When you make it harder to use for most because you are making it easier to use for some, you have gone too far. Not all improvements have a unilaterally beneficial effect.
This highlight the need for personalizaiton
The best tool I've come across so far now has D7 & D8 code for it and we're trying to put out a full release for both (just have to get maintainer-ship) https://www.drupal.org/project/fluidui
Lots of good stuff in the preference framework here https://fluidproject.org/projects.html
We've adopted it here and explained why in our blog https://openconcept.ca/blog/mike/personalization-accessibility-drupal
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
This highlight the need for personalizaiton
The best tool I've come across so far now has D7 & D8 code for it and we're trying to put out a full release for both (just have to get maintainer-ship) https://www.drupal.org/project/fluidui
Lots of good stuff in the preference framework here https://fluidproject.org/projects.html
We've adopted it here and explained why in our blog https://openconcept.ca/blog/mike/personalization-accessibility-drupal
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
As I've read over the
As I've read over the discussion, I've mentioned Standards, and others have said: "Accessibility Standards are always changing." Perhaps true, but I think "Always" isn't entirely accurate... I mean, programming standards are changing too, things being added, things being deprecated, things being removed as we move from one version to the next (HTML, CSS, JavaScript, PHP, etc. etc.) does this mean we use no standards when we program? No, of course not. So why should this be different with Accessibility Standards? Even Drupal itself changes. Are developers doing things the same way on Drupal 8 that they did on Drupal 6 or Drupal 4, or for that matter, how they will on Drupal 8.6 or Drupal 9? Standards of one thing pair with those of another.
Here's my suggestion.
Draw the proverbial line in the sand. "OK, We're on Drupal 8.5.x and as of today, the current Website Accessibility Standard is ______. So anyone developing for Drupal 8.5.x should utilize the _______ accessibility standards in their processes. " When a major update comes out (Drupal 8.6, Drupal 9, etc.) we look at that time, and say, "Ok, now _____ is the current accessibility standard..." and use that. In the event that some accessibility standards update introduces a major change, that can be addressed on a case-by-case basis. "OK, we're working with Drupal 8.7.3, and {this big change in accessibility standard] has been put in place... " and we look at what it means... whether we decide that it isn't going to break anything, and we use it in the new minor revision, or perhaps we decide that we're better staying with the old way until Drupal 8.8 or even Drupal 9 are released. But this way, there is some form of standard that everyone is gauging their work against.
This is an endless well.
This is an endless well.
What we need to make this happen is volunteers
Without new volunteers (or agencies/departments willing to sponsor this) this probably isn't going to happen. Our little team is pretty overwhelmed with existing projects.
This is a good idea. It could work great. But, we need new people to get engaged to help make it a reality.
The #Accessibility Channel in the Drupal Slack is a great place to get started. https://www.drupal.org/slack
Join the group and talk about it there. Lots of good examples and people to help. But we do need more people to make it their priority.
Mike
--
OpenConcept | Twitter @mgifford | Drupal Security Guide