Skip to main content

Blog Post

Accessibility Hackathon, Part 1

Preface: Most of the blogs I write at Mediacurrent are technical in nature, but sometimes it's important to take a step back and talk about what motivates us and why we do the things we do. This blog is more personal.  It’s about what gets me out of bed in the morning and why I love working at Mediacurrent.  It’s about how amazing it is to get to work with people who are passionate about their craft and excited to learn new things.

In May 2015, I attended Knowbility’s AccessU accessibility conference.  It was all things web accessibility for four days in Austin, Texas.  I was in my element and soaked up every ounce of knowledge I could.  I’d been out of the accessibility world for several years and needed some refreshers and updates.  

While at the conference, I learned about Knowbility’s annual “accessibility hackathon” - a website building event focused on accessibility. Teams of web designers and developers are paired with participating nonprofits in need of a site and over the course of a month, the teams build a site for their paired non profit.  The sites are then judged on their level of accessibility. Now that’s something I could get into.  

Every single project I’d ever worked on, no matter how “committed” the client was to accessibility, it was the first thing that went by the wayside when there were design differences and budget concerns and time constraints.  As a consequence, accessibility never fully gains equal ground with things like performance and security.  This project would be different - it would be a project first and foremost focused on accessibility.  Not accessibility as an add-on.  Not accessibility where it fit.  Not accessibility if it didn’t interfere with other things.  But a project dedicated solely to making a website as accessible to people with all (dis)abilities as possible.

In addition, I had ulterior motives.  I saw the hackathon as a way to:

  1. Get staff members who have little knowledge about accessibility some training and hands-on experience in building with accessibility in mind. The more people with accessibility knowledge and experience, the less reliance on those who do have it.
  2. Document the process for incorporating accessibility throughout the design/theming process.

I came back from the conference and posted some information about the hackathon on our internal accessibility chat channel to gauge if there would be enough interest to put a team together.  Preliminary results showed yes. I took my idea to Dave, one of the partners of Mediacurrent, to get approval to use our dedicated weekly internal time toward the project.  He was in full support!  

A few months later, when registration opened, I started recruiting in earnest.  “Ok, people.  It’s time to sign up.  Who’s in?” I was up front in telling them that while we had company support to use some of our work hours for the project, it would require a bit of personal time as well. To my surprise, the max number of people allowed on a team and with the exact distribution of skills needed for the project signed up. Everyone but myself were accessibility newbies and all were interested in learning. Perfect! That was exactly what I was looking for.  We had:

  • UX designer: Cheryl Little
  • Frontend developers: Carie Fisher, Mario Hernandez
  • Backend developers: Mark Casias, Matt Goodwin, Michelle Williamson
  • Project manager: Tia Durham

In addition, one member of the team knew of a non profit in need of a website with a cause we could all get into - The Grey Muzzle Organization.  The Grey Muzzle Organization helps homeless senior dogs by providing funding and resources to animal welfare organizations.  Everyone on the team was a major dog lover. It was a perfect fit.  

Kick-off day finally came.  We attended the kick-off meeting virtually.  There would be 15 teams, each with an assigned/chosen non profit and an assigned accessibility mentor.  We’d have one month plus five days to build this puppy (<-- see what I did there? Puppy?  Dog website?).  Our lives were a flurry of internal and client meetings, rapidly designed wireframes and mockups, and simultaneous development and theming using styleguide-driven design.

Website projects are rarely fast or easy and this project would be no exception - especially considering the timeline and complexity of the website! At the start, Mediacurrent intended to donate a generous 48 hours per week for the project (all of our hours combined) and donated even more when possible. In order to achieve the vision we had as a group, the project ended up requiring copious amounts of the team’s personal time in the evenings and on weekends, much more than I originally anticipated and alerted them of. No one complained. We were doing this for a purpose. Instead, this group of people, most of which I’d never worked with on a project before, were bonding by sharing pictures of our pups in the group chat, heckling each other, and one week even passed around a flu from one to another in the video chats.

And then the magic started. The team members started out with little accessibility experience but their desire to learn was impressive. As the color scheme was being determined, I directed Cheryl to the book, A Pocket Guide to Colour Accessibility and showed her how to determine color contrast ratios.  To my delight, she bought the book AND read it!  “That color book Mickey suggested, I bought and wow what an eye opener,” I read in a chat shortly after.  They started using various tools to determine color contrast ratios to check whether they passed WCAG guidelines.

I saw team members begin to think about accessibility outside of the project.  For instance, I get pinged anytime someone mentions the word “accessibility” in any of the internal chat threads I’m subscribed to.  And I caught Carie post in other Slack channels:

“Only thing that jumps out to me on a quick review, is this font is hard to read. Not sure if it’s the color or letter spacing, but probably not accessible”

and later in another channel:

“Can we roll some accessibility into the auto testing?”

and then from Cheryl:

“I found this to be an interesting read… and wondering why am I just now realizing the significance of learning disabilities and how it impacts page layout?”

And after reviewing a boatload of content that our Project Manager for the hackathon had copied and pasted into the site, I was pleasantly surprised to discover she’d automatically improved the accessibility of the content during the copy/paste process without specific instruction from me.  I was like a proud mama watching her children learn to crawl, and walk, and run!

And then the ultimate happened.  The WCAG guidelines are not standards the average developer/designer spends much time reading.  In an effort to keep them as technology agnostic as possible, they can seem rather vague and cryptic.  Most web folks rely on an accessibility expert to have good knowledge of them.  So I was pretty excited when I discovered Cheryl researching WCAG guidelines to determine whether a link needed to be underlined or not and posting her findings in a ticket!  Cheryl had learned to fish.  My work was done here.

Along with the rest of the team, I was also able to learn a few valuable nuggets from some feedback we received from our team mentor, Dylan Barrell from Deque, which are in The Accessibility Toolbar blog post.

I also asked members of the team to share what they learned around accessibility that had the most impact on them as a designer or developer.  Here are their responses:

“For me it’s learning about the 'aria-label’ attributes.”

“Can we just say :allthethings:?”

“I think the contrast related things was a real eye opener. And also I would note that there is no replacement for testing in a screen reader.”

“Accessibility is not just about improving your website for those who are blind or hearing impaired, but cover a wide range of disabilities – both functional and clinical cognitive. How your content is written, presented and displayed plays a huge role in helping those who might struggle with reading (ex, dyslexia), linguistic, and verbal comprehension as well as memory, problem-solving and attention deficits understand the information you want to convey.”

The project was a success.  We built a website that I am proud to point to as a good example of how accessibility does not have to mean boring or limited in design. We documented what the quick gains in accessibility are that using Drupal gives us and learned some of the pain points.  And more importantly, I can’t tell you how exciting, refreshing, and motivating it is to work with fellow web folks who love and embrace new ways of doing things.  

Stay tuned for Part 2 which outlines the specifics of how we accomplished the accessibility of the site in Drupal.

[Edit: Part 2 is out!]

Additional Resources
Building an Accessibility Toolbar with Drupal | Blog Post
Don't Rely on the Title Attribute for Accessibility | Blog Post
Accessibility Best Practices for Content Editors | eBook

Access icon Up arrow icon Drupal 8 icon Facebook icon - white Facebook icon - blue outline Facebook icon - yellow Hollow right arrow icon Hollow right arrow icon - white LinkedIn icon - white LinkedIn icon - hollow LinkedIn icon - blue outline LinkedIn icon - yellow Mediacurrent wordmark Quote icon Twitter icon - white Twitter icon - hollow Twitter icon - blue outline Twitter icon - yellow Youtube icon - white Youtube icon - yellow