The worst way to do accessibility is to ignore it.
The second worst way to make something accessible is to do it after the product has been coded
1) An already-coded product might have features or integrations with third-party vendors that can’t be made accessible. In that case, extra features that provide equivalency might need to be added.
2) An already-coded product might have chosen inaccessible color themes
3) An already-coded product won’t have given any thought to shortcuts that improve the assistive technology experience.
4) An already-coded product will need a second full QA cycle after the accessibility changes have been made
5) An already-coded product that has done user testing (you did do user testing, right?) will need to repeat the user testing with disabled individuals
6) An already-coded product will have an ACR/VPAT full of “doesn’t supports” which will limit your ability to sell to organizations that come under Section 508, the Accessible Canada Act, or EN 301549 and the European Accessibility Act just to name a few.
7) An already-coded product that doesn’t include accessibility is indicative of an organization that really doesn’t care about disability diversity.
If you have limited development resources, retrofitting accessibility into an existing product will delay other feature implementationDid I miss any? Comment below.
Takeaway from this post: Make it accessible from the outset.
Alt: a professor standing in front of an enormous blackboard filled with an overwhelming number of complicated mathematical equations written in chalk.