Accessibility Tutorial
A Recommendation
It is often imagined that coding a site to facilitate accessibility requires extra time and effort. The truth is that there is generally little extra effort required in coding a site to make it accessible if the site is coded correctly to begin with. That is to say, the difficulty with making a site accessible is not development time but retrofitting time.
I say "generally" because there are some exceptions to this rule. It is a recommendation that all video be captioned for the deaf. Obviously, this could be a large undertaking, but it can be done in parallel with development since the development team would not likely handle captioning. Extra testing time is also required, though it too can be done in parallel with other testing. Unfortunately, such testing does require the purchase of tools, such as a screen reader, which can be costly.
Since most web developers are not trained sufficiently in accessibility issues it is my recommendation that at least one developer who is an Accessibility Subject Matter Expert (hereafter Accessibility SME) be assigned to every User Experience project. This Accessibility SME would ideally be a front-end development team lead who performs related tasks such as code review. The skills of the Accessibility SME are especially critical in the earliest stages of development when HTML mockups are created for development.
The first task of the Accessibility SME would be to examine the visual design mocks and the proposed site structure to determine if there are any design or usability issues that might impair accessibility, on the premise that bad design and bad usability are bad accessibility for all users. The Accessibility SME would then communicate those concerns to appropriate teams. This might be the most painful part of the Accessibility SME's duties since these teams may not appreciate the importance of accessibility. Branding concerns and the placement of "upsell" links may outweigh accessibility and usability concerns in the implementation of an ecommerce site. Upstreaming standards becomes more difficult in companies where teams vie for resources instead of working collaboratively.
Secondly, the Accessibility SME would train the front-end development and QA teams in accessibility. This can be done in a few sessions. It is the experience of this author that few developers understand these issues, and it is thus anticipated that all development teams will need this training. The Accessibility SME would be tasked with supervising the creation of the HTML templates that are later used for development, and would manually review all such pages.
Because accessibility cannot be strictly measured with validation tools, the Accessibility SME would perform the role of QA lead for the mockups, by visually examining the code, testing the code in a suite of accessibility tools, and running the code through a screen reader. This investment of time up front will potentially eliminate many hours of refactoring code.
Thirdly, the Accessibility SME would perform code reviews of all developed pages since code review is standard practice in many development efforts.
Lastly, the QA team would have access to testing software such as JAWS, Window-Eyes, etc. to QA the final developed product before launch.
If it is not possible to assign an Accessibility SME to every project, then one can be assigned to assist in an advisory capacity. If the front-end developer lead lacks subject matter expertise in accessibility it is recommended that senior developers take a course in accessibility. I wish to emphasize again that accessibility cannot be achieved by a novice with textbook in hand, since there are no reliable and thorough tools for developing accessible sites, nor comprehensive validation tools to test them.