Case Study: Brandon Travis

I love to hear from people who have read my book or used Wuhcag.com and used their new skills to make their projects more accessible or meet the Web Content Accessibility Guidelines (WCAG). From time to time, readers are kind enough to answer a short questionnaire case study (feel free to request one).

Today, I’m featuring the experience of Brandon Travis.

Tell me a little about yourself and/or your organisation

My name is Brandon Travis, and I’ve been a front-end developer for a total of about six years. I recently got back into the industry after leaving a career in retail leadership. I am the Director of Web Services at Between Pixels, a video production and marketing firm located in North Metro, Atlanta. We have only been formally offering websites for about a year, when I was brought in to help expand the company’s capabilities and services.

How much did you know about WCAG 2.0?

To be perfectly honest, even though I thought I knew ‘the basics’, it wasn’t until a project brief came across my desk that listed ‘WCAG 2.0 Level AA Compliance’ that I really bothered to learn it. I think that, like many developers, I waited to really learn about creating accessible web pages and applications until a project required it.

What problems were you facing with web accessibility?

My organization was hired to create an entirely new website for a local university. While we had done websites with a similar scope and size in the past, we hadn’t really had a project that specifically dictated WCAG compliance in the project brief.

We faced many challenges with this project that made it unique with a fairly high level of risk. For one, our team was still very small and relatively new to working with each other when we began this project. Additionally, as I’ve already mentioned, we never would have considered ourselves experts in accessibility before we began this project, and often fell victim to the ‘we’ll do it later’ mentality that so many teams face when under the gun.

So, for this project, we had a completely new frontend system that we didn’t design with accessibility at the forefront of our minds, and were now under the gun to deliver a finished product – including WCAG 2.0 AA Compliance.

When we first started to really dig in and audit our new site, we found numerous issues. We had chosen to use some pre-built plugins for areas like sliders and galleries, and learned early on that those developers didn’t build their products with accessibility in mind, either.

At the end of the day, we were left with a product that was well built and very performant, but had many different developers who had all implemented partial WCAG compatibility, but it was all over the map.

What was the impact of these problems on your (or your client’s) business?

Luckily, we started working to correct the issue early enough that we never had any real complaints about accessibility. Before the site went live, we ran an open beta and invited all of the university’s faculty, staff and existing students to review and provide feedback.

By the end of the beta period, roughly 5% of all the comments we had gotten could directly be related to the lack of accessibility in certain areas. For example, one thing we learned while using the WordPress Gravity Forms plugin was that we had some very unpredictable results with tabindex, depending on what other components might be on the page. In areas where we had a third-party slider or a gallery and a form created by Gravity Forms, we were almost guaranteed to have keyboard navigation issues.

How did you diagnose the problem?

To be perfectly honest, we knew that accessibility was a concern on the day we launched the Beta, so it wasn’t hard for us to know where to start looking.

What expertise did you need?

Ultimately, we still didn’t have an expert on staff that we could rely on to give us reliable information around creating accessible web applications. We needed to get someone up to speed quickly on all three levels of WCAG 2.0, and knew that we needed to get a solid grasp on things like WAI-ARIA before we could really put this one behind us.

How did you solve the problem?

Honestly, I reached out to some people in my network around where to even begin. I had purchased a few books on the subject, and looked into video courses offered on sites like TeamTreehouse.com, but we needed to start making traction rapidly. I was directed to the Wuhcag.com website via a response on Twitter, and after reading some of the first few articles on the site, I immediately bought the book.

What process or strategy did you use?

Over the next few days, I immersed myself in WCAG 2.0 using a combination of Luke’s book, website, and the W3C spec on the subject. After I considered myself to have a relatively solid theoretical understand of the ways to implement the WCAG guidelines, I put together a working session with my developers where we would examine the site within the context of one to two guidelines at a time, and determine what a particular fix would be.
We discovered that about 80% of our accessibility problems could be solved by correctly implementing about 20% of the rules that we either:

• didn’t know about when we began working on the site; or
• incorrectly built somewhere along the way.

What were the technical challenges and achievements involved?

Ultimately, I would say that nearly all of our problems were either related to a design element or to a third-party tool or plugin. Of course there were the random one-offs that don’t fit into these broad buckets, but those cover the bulk of the issues we faced.

Design-based challenges were honestly probably the hardest to fix, as it meant needing to go back to the university team to get approval on redesigned elements. One particular example is how we utilize video on the site as it relates to overall design. We created many background ‘b-roll’ videos to help create an immersive experience. Ultimately, these videos had no critical content or message, but were a design choice that we believed would help convey the overall atmosphere and culture of the campus. There are a number of WCAG 2.0 guidelines that relate to audio and video and what we found is that, while most of the standards were relevant to our project, not all of them directly related to how we were using video.

Additionally, one major challenge we faced was the ability to pause / pause all / pause all for good. We knew we needed some control buttons, however couldn’t use the built in controls, as these videos were basically treated like full screen backgrounds. So we had to solve a lot of problems, just with that one particular component.

When it came to third-party plugins and software, we really felt as if we had hit a major roadblock. All of the ‘rules’ say that you shouldn’t modify other people’s plugins or core source unless you are building your own version, which we weren’t. We ended up getting a pretty long way into this journey before realizing that we had critical functionality built into software that simply wasn’t accessible. For most of these tools, we were able to find relatively accessible alternatives. Where we couldn’t, we were faced with tough business / quasi-ethics related decision: do we ignore the accessibility issues and attempt a Band-Aid fix, or do we spend the time and money now to build these in-house, even though we were rapidly approaching a ship date?

Ultimately, we opted to rebuild any tools that were not deemed salvageable by our development team. Even though this introduced other challenges around hitting key dates, ultimately we felt very strongly that having a fully accessible site was the right move and would pay off in the long run.

Did you work with a team?

Absolutely! We were dealing with nearly a thousand pages, all with varying degrees of non-compliance. Ultimately, we had three developers, a designer, and a content strategist that worked in conjunction with the university to get the site to a state that we were all happy with.

How will you stop the problem coming back?

That’s the real challenge, isn’t it? During this project, we implemented a code review process that had been lacking before, and it has worked very well for us thus far. Additionally, all of our developers are fully trained in creating accessible sites and applications, and we consider it a mortal sin to push code that isn’t accessible. We also have spent a lot of time with our User Interactive (UI) Designer to make sure that she is up-to-speed on how to design for accessibility.

At the end of the day, I think we made all made a mental shift during this particular project, and realized that accessibility isn’t something you can just ‘throw in’ during deployment, and it has to be part of the conversation from day one. We make sure that we include WCAG 2.0 Compliance (at different levels, as each project dictates) as a deliverable in all of our contracts, regardless of whether or not the client has specifically asked for it. For all of our clients where we are providing any kind of ongoing support, we include a monthly or quarterly accessibility audit, depending on how active the sites are.

What was the result of your work?

We are only ninety days past our launch, so we are still working on quantifying some of our results, however initial feedback has been very positive. There were some decisions made in partnership with the university to delay certain items, as we knew that that system was either being redesigned or rebuilt over the next few months, but with the exception of those known issues, we have been able to keep things on track during our review process that I mentioned above.

Did your project find a new audience or grow its existing audience?

That’s hard to say, as this was really part of a much larger marketing project for the university. I would say that we are certainly much better equipped to cater to an audience that has special browsing needs because of the work that has been done.

Did your work increase sales?

While we don’t ‘sell’ anything on the site, per se, we do have a ‘Request Information’ form on our homepage for new students. We have seen significantly more submissions on that form since we corrected the accessibility issues that were on the homepage. Again, this could be due to a number of factors, as I’ve stated above, however I personally believe that is partially a result of having a more accessible site, as we did have several issues with this form and the page it is on before we began working to correct accessibility on the site.

Share your personal insights from the project

My biggest ‘a-ha!’ moment during this work was the realization that I had to make this a priority at the beginning of every project. This meant not just reviewing a design comp to make sure that they were aesthetically pleasing, but also making sure that what our designers wanted us to build was possible within the WCAG requirements for the project.

I also learned that I simply cannot be the only one thinking through this on every new project. If a prototype gets to me for review without my architect, designer, or developer intentionally taking accessibility into account, it could very well cost us days trying to backtrack and correct the problems. We have incorporated accessibility as a non-negotiable sign-off into every major stage of our project calendars, and would encourage every other agency out there to do the same.

Do your team have any additional insights?

While many people on my team worked together to correct the issues on the site discussed above, I had one developer that completed the majority of the work. After the project was completed, we spent some time discussing his experience and how to make the process smoother as we moved forward as an agency. His largest piece of insight was around the need to begin working on accessibility at the start of every project. As I mentioned above, we have added several accessibility checks during our development stages, and complete a full audit at least quarterly with our clients. These practices came directly out of the insight and experience that he gained while working on this project.

What worked well for you?

We utilize the checklists provided on Wuhcag.com on every single project. Those checklists, along with the book, have become a critical reference point that we utilize dozens of times on any given project.

What would you do differently next time?

I’ve mentioned it before, so I won’t go into detail, but there are two key things I will do differently moving forward.

First, we absolutely will plan for accessibility from the very beginning of every project. This means that we will define the requirements as we scope the project, and build review points into every stage of the project to make sure that we are delivering against the requirement.

Second, we will seriously audit any third-party tool or plugin before we make a decision to include it in a project, regardless of its rating or popularity. We ended up spending several days trying to make plugins work that we had already committed to earlier in the project, and that is a mistake that I am not willing to make again

What were your doubts?

Honestly, I think that, like most front-end developers, we thought of WCAG as a somewhat restrictive construct that we would ‘do our best’ with. It made it easier on earlier projects to say, ‘Well, it wasn’t really defined as a deliverable on the project, and we just never got to it inside of the timeline. Maybe during the next revision, we’ll take a look at accessibility more in depth.’ It created some serious anxiety about correctly implementing the WCAG 2.0 standards, and ‘accessibility’ had almost become this big overbearing monster that we were afraid to deal with.

Until there is a specific, billable reason to learn it, I think most developers treat accessibility as an added bonus, and we were no exception.

What surprised you?

First, it’s not as hard as one would think when first setting out to learn it.

Second, one of the mental roadblocks that I had to address is that there are several guidelines that aren’t clearly black-and-white. As a developer, I’m used to there being a generally accepted ‘right way’ to do something and, conversely, a generally frowned upon ‘wrong way’ of doing the same thing. When dealing with web accessibility, much like Search Engine Optimisation (SEO), this just isn’t the case. Yes, there are several things that are clearly defined, but there are just as many things (if not more) that can’t be run through a validator or code linter.

Web Accessibility isn’t difficult to get right, but it takes work. If you start at the end and think that you can just ‘go look up how to do that’, you are in for a very bad experience.

Thank you for sharing Brandon!

You can read more about Brandon’s work on his blog at www.brandontravis.io.