A Modest Proposal for Accessibility-Driven Web Development within Government

I have never been a developer specifically tasked with making web applications accessible to users with disabilities, but I still find myself engaged in conversations about web accessibility with my friends employed by government agencies here in Washington, D.C. There is always some new service or technology or design that government employees would love to bring in, but they’re not legally allowed to because it’s not “Section 508-compliant.” This inevitably sparks a conversation about making technology accessible, and it’s all too often sparked by non-developers who can’t understand why developers just can’t make their products accessible. It’s one of the most misunderstood problems facing the accessibility community, and it shows no signs of being resolved any time soon.

I would be remiss if I tried to solve the entire web accessibility problem in a blog post, but I can hopefully shed some light on how the problems start - now that I’ve had the opportunity to fix a few of my own.

Recently, my team was tasked to make some changes to a web site with a map that showed text content when a user hovered over it. I can’t show the site itself, but this page gives a decent representation of what we added. It’s a red-flag accessibility problem because it implies that sight is required to operate the web application, and not every possible user can see the screen. Some are navigating it through screen readers. I’ve had some training in how to spot these sorts of things, though, and I realized that we could easily just head off the user by placing aria tags within the map when a user stumbled upon it, and we could also place the tooltips in the HTML document such that a user could still read them. This was about five minutes worth of extra work, and all I needed to do was organize my HTML in such a way that a screen reader could figure it out.

I can do this because I’m not just thinking about accessibility (which would have caused me to forego the map idea altogether), and I’m not just trying to hammer out a task in a hurry (which would have caused me to skip the HTML rearrangement). I’ve got time and training to notice the problem and creatively solve it. That happens at every level with our team at APCO Worldwide. Our team members developing wireframes and user interfaces have accessibility in the back of their mind, our designers are thinking about color contrasts and font choices, and our developers are sorting through their HTML to make sure we don’t make some sort of confusing error in our code. We’re not accessibility professionals, we’re creative professionals who happen to know that not every user has the same experience with a computer that we do.

We also plan our designs and our development in a holistic manner, and we iterate through multiple rounds of feedback to get it right. We decide who gets to have feedback and who doesn’t. And we don’t just say “yes” to any change that comes down the pipe: we weigh changes through our creative expertise before we implement them, and we push back on our clients if they make changes that will be problematic. If a client requests something that’s going to impact the accessibility of the site (such as a color contrast issue or a font change), we discuss it internally and propose alternatives before we just start coding.

What Government Gets Wrong

Government has recently taken an interest in good design, which is all for the best. But it has focused heavily on simply hiring individual designers rather than focusing on a creative process that emphasizes excellent, accessible design throughout. This requires a commitment to a management style that is inherently at odds with how government develops and deals with IT solutions.

Government tends to want to shift all the blame for bad, inaccessible design on contractors, but I don’t think that’s the whole of the problem. We pull off accessible design well and we’re a contract-based shop. Our team is fortunate enough to be trusted to do our jobs and left to work, relatively uninterrupted, for decent blocks of time. Despite my contractor nature, my clients trust me to get my job done and don’t particularly care where or how I do it, so long as the end product is exactly what they asked for. Any government contractor will testify that this is typically not the case in the government.

Rather, you’re in an environment where the agency’s security office has insisted that you must work in their office on their machines at the time of day that they specify, you’re confronted with at least six half-hour to one-hour meetings per day from every project manager trying to use the same contractors for their own projects, and your design sensibilities will be whittled away by the occasional SES manager who just loves the color orange and really can’t understand why you can’t incorporate some orange into the design. Trust me, government project managers, I know that none of you is individually that bad. Collectively, however, there is a management culture within government that does not tolerate the daily structure required to consistently execute excellent, accessible design.

I know how we address this issue within our firm, and I imagine that the government solution to this problem is quite similar. We employ a “traffic manager” whose job is strictly to keep the designers on task and away from distractions by handling all of the overhead and scheduling that tries to plague them. Invoices, client meetings, rush projects - the traffic manager handles it all, and gives the designers direction on where to go each day. If a designer needs time to finish a deliverable, they tell the traffic manager about it before going offline - and if you happen to have some rush project that absolutely needs doing that day, you go through the traffic manager first.

The traffic manager is there to put a halt to one of the most basic problems with organizational culture: individually, no one is really a problem in the way of creative work. It’s when we all individually have problems at the same time that we become a collective, pervasive problem. The traffic manager is there to put a bottleneck to that collective problem. Can government bring in that sort of management style to fix its accessible design issues? Absolutely.

What About Externally-Developed Products?

Government agencies make use of Facebook, Twitter, and a host of other services that were not put together by contractors. Those services are all too often inaccessible to their detriment. But after thinking on where these products are developed, it doesn’t surprise me. Washington, D.C. confronts accessibility issues every day while other tech capitals rarely face it.

Growing up in the Southeast, I went my entire life never regularly interacting with vision- or hearing-impaired individuals. The city has almost no public transportation, which makes it difficult for the vision-impaired to independently get around. It’s a little bit easier on the hearing-impaired - but nothing compared to living near Galludet University where the bartenders know sign language. This is the environment for much of the country, and it’s certainly the environment where these web services are being constructed. If we want accessible web services built by default, we have to constantly remind those developers if they aren’t going to regularly interact with users who can’t fully see the screen or hear a video.

And, to be honest, we’re going to have to make a case for it. Less than 3% of all Americans have some form of vision impairment that can’t be fully corrected. Of that group, most are over the age of 65 - hardly the target market for Twitter’s developers if we’re trying to convince them of a large new market out there. We must instead focus on the concept of access to information, and the importance of the information we want to convey. When Egypt’s access to many Internet services was shut down during a wave of protests, Google and Twitter stepped up to provide access to Twitter via standard phone connections. Access to information is in these companies’ DNA, and that’s where we have to focus our accessibility efforts. Section 508, WCAG, etc., etc., don’t matter - what matters is that we have users who cannot access important information, and only these externally-developed services can help us get those messages out.

Can these problems be solved? I think so. We need only break outside of our bubbles - both within Washington, DC government culture and without - and realize that there is a different way of doing business outside of our walls.