The vast majority of work that I’ve done on the web building websites and apps has been for government agencies. For government sites, accessibility isn’t just a best practice, it’s legally required. In spite of this, a lot of websites still don’t meet the minimum requirements. When I first started working on government projects, I inherited a portfolio of over twenty sites, all in various states of accessibility noncompliance. I made it my mission to make all of the websites meet accessibility standards within a year, and I challenged myself to learn as much about web accessibility as I possibly could.
It ended up taking longer than a year, considering that I had other work as well, but that was how my passion for web accessibility began. I read the Web Content Accessibility Guidelines (WCAG), took as many online classes as I could find, and watched videos from previous years of axe-con. I also started working with Nik Petersson from Miles Access Skills Training. His business primarily provides training with assistive technology for blind users, but he also does accessibility user testing. Nik himself is blind, and his testing has been absolutely invaluable for understanding the screen-reader experience on websites.
These days, I don’t just work on government projects, but I’m still passionate about bringing my web accessibility expertise to everything I work on. During our first year as Garnet, I dutifully added a line item for accessibility to nearly every proposal and bid we put out. In my mind, this would show clients how easily (and affordably) accessibility could be added to the project, whether it was in their initial scope or not.
In many cases, what actually happened is that clients asked if they could opt out. Most viewed accessibility as a nice-to-have, and not necessarily a priority for the given budget. Some wondered if we could have accessibility as part of a potential phase 2, if everything went right in phase 1 and it stayed in or under budget. What also happened is that it didn’t matter whether they opted in or out.
One of the things people often get wrong about web accessibility is that they think it’s something you do at the end of a project—once everything is said and done, you do a review and remediation of any problems. That is one way to do it, but it’s also the most expensive and least effective way to create an accessible site. I’ve trained myself to think about accessibility at the beginning of any project, and what that generally means is that it doesn’t add any extra cost or time. It turns out that whether a client asked for accessibility or not, the work I did still ended up taking accessibility into account.
In cases where there are glaring accessibility issues outside the scope of what I’m working on, I’ll recommend a full accessibility audit and remediation. The unfortunate truth is that fixing accessibility issues on an existing website or app that has been putting off thinking about accessibility for a while can become a serious undertaking, and in those cases, it deserves its own project. In all other cases, I won’t be offering accessibility as an add-on to proposals anymore, because I’m not willing to make accessibility optional. It’s always a part of the work that I do, and hiring me means that clients get that expertise.
