On February 15, 2012 I provided my testimony before the Maryland State Senate and House of Delegates in support of two bills: Senate Bill 287 and House Bill 183 (both links are PDF documents). The below is the testimony I submitted:
My name is Karl Groves. I made my first website nearly a decade-and-a-half ago while working in the music industry. I later transitioned to a full time career in web development, first as sub-contractor for Baltimore-based web design firm Silverpoint. In 2003, I became E-Commerce Manager for NASA Federal Credit Union, a financial institution with more than $650,000,000 in assets, based in Bowie, MD.
Later, I was hired by a usability consulting firm as their Director of Web Development. During that time, I did web design and development for the National Cancer Institute, Aerospace Medical Association, Sprint Nextel, Food & Drug Administration and more. Due to requirements that these sites comply with Section 508 of the Rehabilitation Act, I took ownership of developing in-house expertise in web accessibility.
In 2007 I chose to transition into a career focused solely on accessibility consulting. I made this choice because I found the nature of the work extremely satisfying: As an accessibility consultant, I could leverage my technical expertise to solve real problems faced by users with disabilities in trying to use the Worldwide Web.
Since that time, I’ve enjoyed a very rewarding career doing accessibility consulting and training in accessibility for more than 5-dozen companies and federal government agencies including Bank of America, HSBC, Humana Healthcare, Lockheed Martin, Internal Revenue Service, Maryland Department of the Environment, and more. Perhaps most relevant to the matters of today is the fact that over the last 18 months, I’ve also trained more than 500 web development staff on the various topics of web accessibility.
Why should the web be accessible? For all of us, regardless of whether or not we’re disabled, the Web is an increasingly important resource in many aspects of life: education, employment, government, commerce, health care, recreation, and more. All of us in this room have conducted commerce online. The web is central to our day-to-day work. Many of us handle our finances online. Furthermore, some of us have also taken advantage of online classes delivered over the web. The ability for a person with disabilities to perform these same tasks on the web is predicated upon there being an accessible Web. The accessibility barriers to print, audio, and visual media can be much more easily overcome through Web technologies as can the logistical challenges posed by conducting commerce, banking, education, and interacting with government services in-person. I’d like to take the rest of my time to focus on four important topics related to the matters at hand today:
- Accessibility’s Impact on Design, Content, Structure and Operation of Websites and Web-based Systems
- Accessibility’s Impact on Budgets and Resources Devoted to Websites and Businesses that Operate them
- Requirements on the part of Development staff
- Common Barriers to Adoption of Accessibility
For new development work, the organization would be most successful in creating an accessible system if they place a focus on accessibility early and often in the development lifecycle. Doing so properly will reduce accessibility’s impact on timelines and budgets for web projects. For remediation of existing systems, the impact is a bit more difficult to determine. A variety of factors, such as platform limitations, severity of current accessibility errors, and more may have an impact on the organization. In both cases, the primary variable determining success and cost impacts will be the skill level of the development staff. Staff members who are uninformed or unskilled in accessibility will, naturally, take longer time to include accessibility in their projects. This is not a trait unique to accessibility. Advocates for privacy & security will echo similar sentiments. Any time development staff must implement a new requirement, the time necessary to add the new requirements will – at least initially – add additional time (and therefore cost) onto the project.
The Web Content Accessibility Guidelines (WCAG), version 2.0 was developed by the Web Accessibility Initiative of Worldwide Web Consortium – the standards body for web technologies. WCAG Criterion are segmented into three levels, named ‘A’, ‘AA’, and ‘AAA’. These distinctions reflect, at least at a high level, the impact upon the interface design, operation, structure, and content of the system. Level A requirements, for instance, would not impact the interface. To put it more simply: A large set of accessibility best practices exist which provide guidance on creating an accessible system in ways which will not fundamentally alter the design, structure, or operation of the site.
It stands to reason that additional requirements require additional resources to implement – and those additional resources require the expenditure of additional money. How many additional resources and how much additional money can vary quite considerably, depending upon the nature of the system and knowledge level of the development staff. Overcoming existing platform limitations may be quite costly and time consuming and may cause significant strain on internal resources. The converse is also true. As stated before, an organization is most successful in accessibility when it is integrated early and often. A knowledgeable developer can implement the vast majority of accessibility best practices with little-to-no impact to budget and timeline.
When an organization is new to accessibility, there may be a small handful of expenses incurred when adding accessibility to their processes. They include:
- Determining accessibility requirements for final deliverables
- Developing internal style guides and best practices
- Training staff
- Finding new toolsets
- Modifying existing codebases
- Additional QA time & resources
- Consultant Fees/ Salary for an internal Subject Matter Expert
The majority items are one-time expenses that become a permanent part of how the organization does its work. The impact of these costs can be offset by taking an iterative approach rather than taking them all on right out of the gate.
There is one significant exception to the above: The inclusion of captioning for online video. While it is expected that the increases in development time will diminish as developers grow and use their new skills, captioning of video will always be an added expense. Thankfully, a number of high-quality, inexpensive services exist to take on the captioning tasks.
To implement the vast majority of accessibility best practices, development staff require little more than knowledge of basic web development techniques. In most cases, training on accessible web development takes about two days to go over the basic requirements. For highly interactive development, an additional two full days is required to go over advanced topics. Like any new skill, it will take more than just a few days before developers are proficient in using what they’ve learned. Consequently, we also recommend that developers have resources at their disposal they can turn to with specific questions or concerns. These resources can be formal or informal, internal or external. The accessibility community is a highly generous one and numerous high-quality resources exist online to assist those who are new to accessibility.
By far the most common barrier to the adoption of accessibility is the impression that accessibility is some nebulous thing, difficult to grasp. It is perceived as overly complex, burdensome, and expensive, yet every day organizations are successfully integrating accessibility into their processes and working toward creating accessible systems. It is my belief that the true common barrier as to why more websites aren’t more accessible is ignorance. Ignorance exists at all levels of organizational structures regarding what accessibility is, why it is important, and how to manage it. If such ignorance was lifted, we would see a much better outlook for accessibility.
To summarize, developing and maintaining an accessible site requires specialized knowledge on the part of development staff and effective integration into development processes. None of this is unique to accessibility. Adding any new requirements, such as those requiring better security or privacy, will add additional demands for time and resources. Like privacy and security, once accessibility has been integrated into process and once staff members have been educated, impacts are minimal. Furthermore, the payoffs for doing the right thing make the extra effort well worth it.