I had this blog post written last week but didn’t publish because it felt wrong. It wasn’t until earlier today, when I was listening to one of my favorite public speakers, that I realized it was because I was talking at you, not to you. In truth, whenever I’ve discussed this document I keep talking about the what its purpose is and how it could bring value to our Drupal community but not why you should care. So, just for today I’ll set aside my talk of prom dresses past, my Munster life and try to focus on why the Accessibility Rights and Responsibilities Document I’ve been working on with others came to be. It’s not only about web accessibility, it's also about business. Hopefully you’ll find this document will become important to you too.
Accessibility! Accessibility! Accessibility!
Accessibility talk is everywhere, at least if you’re looking for it. From code, to legal, to Slack channels, to my talk at Design4Drupal Boston this past June; if you want to read, hear, or chat about accessibility online - it’s out there.
But there’s a problem…
You see in Boston the night after I spoke, I was lucky enough to look around the table to find myself sharing hot peppers and nachos with project managers, writers, front end developers, sales and UX designers. And maybe it was the fact I was starving and inhaling nachos that had me be quiet long enough to listen, or maybe it was the enthusiasm of those with whom I sat, but I heard things I hadn’t heard before. They all wanted to grow and were looking for ways to incorporate accessibility into their everyday workflows but there was so much confusion as to who would ultimately be responsible for what.
And as we spoke it occurred to a few of us, why would companies feel empowered to make this change if the various groups involved were not clear on who needed to do what?
Let me break for a moment to say that the W3C checklist is detailed and incredibly well thought out. This is a tool developed by people far more educated in this than I and it will tell you every detail I could think of.
But we were seeing a problem…
It wasn’t translating.
We had a table full of experienced, accomplished professionals and it was difficult for them to sort it all out into simple business language to help their organizations make an agreement internally that “if I need help with X, I can go to team Y.” Some needed to know that as an agency acting in the role of their clients creative and/or technical arm, that they could hand the site over to content editors who’d been educated and encouraged to continue to meet the requirements moving forward.
In short, I began to care about a document because there was a need for it.
Accessibility wasn’t accessible to the businesses who wanted to adopt it.
The next day a few of us started building a Rights and Responsibilities document. Our only goal was to meet that need and to clearly state, in common/business friendly language what teams are responsible for what when it comes to accessibility issues.
At first, we tried to take a more granular approach but that would have steered us away from our goal. Instead we had broken out responsibilities into two groups; the Design and Development Team, and the Content Authors/Managers.
Why? Because these were the people around the table who said they had the greatest need.
As stated in the document itself, the goal is not to determine at whom we point a finger at if something is not fully accessible but rather to help guide communication to the right source for solutions and ease businesses into making this a part of their standard operating procedure.
...ya know, “Just What We Do” and all that.
Our Rights & Responsibilities Documentation is Slowly Growing
Since those days in Boston a few of us have continue to work on this as we have been able. Last week at Drupal GovCon I had the privilege of meeting some amazing people who also want to help. A GitHub repository has been made and we have tentatively scheduling a zoom meeting with a large MeetUp group to see who there wants to contribute.
At the time of this blog post, the document is not at the stage where someone will copy and paste it into their department’s operations, but it’s got a good start.
So, why should you care?
Because we all need support.
- Technical teams need to be confident that the content authors are enabled to keep a site accessible after launch.
- Content managers need to know that their authoring UX was set up to support them.
- And project stakeholders needed to know where to ask for help if they needed.
The days of one person sitting down to just ‘build a website’ are gone. Today building a website is about collaboration, knowing where to turn for support, and where to find the education to better ourselves.
I encourage you to read the Rights and Responsibilities document and Tweet me your feedback (@dbungard).
It’s not about a document.
It’s another way for us to make this “just what we all do.”
Accessibility Best Practices for Content Editors | eBook
Web Accessibility Terminology | Blog
Friday 5: 5 Ways to Incorporing Accessibilitylity Into Your Digital Strategy | Video
Friday 5: 5 Takeaways from Design4Drupal | Video