Time estimates for accessibile development

A common complaint from developers is that they haven’t been allotted time for accessible development. The problem is, accessibility is an inherent component of quality software development, no different from things like performance/efficiency, readability/maintainability, documentation, and security. To non-technical colleagues and managers, these details are not their concern, only their expectation. It’s up to the developer to articulate the time needed to do the job well. Just as you make time for these other things, make time for accessibility – only you can. As the developer, you are in the position to defend accessibility as an important part of your work; refuse to make a product of inferior quality.

Calculating time estimates

• You need to give yourself enough time to test for problems and remediate your code/discover solutions/rearchitect your work to accommodate different user behaviors.
• Experience will make these time estimates easier, as you become more familiar with the most routine accessibility problems and fixes.
• In the meantime, there are some red flags that you can watch out for and know that they’ll immediately require less or more time:
  • If a client wants a simple list of links, you’ll probably be testing for easy, basic things, such as <ul> structure and appropriate link text.
  • But if a client wants a highly customized interface that doesn’t use standard web elements and/or requires custom Javascript, you’ll probably need more time to make sure screen readers can navigate the interface.