FodnessMemo22

=Speaking Subject: Disabled Individual=


 * **Catalysts** || **Statements** || **Corrosions** ||
 * IT can enable individuals with disabilities to interact with the world more easily. Speech recognition technology, for example, allows people who cannot use their hands to write more easily. || IT is easy for me to use. || In many ways, IT has put up additional barriers for individuals with disabilities to overcome. ||
 * Many aspects of IT usage assume a fully-abled user and are not adequately programmed for individuals with disabilities, thus making the software and/or hardware difficult to use. || IT is difficult for me to use. || In many ways, IT has made the lives of individuals with disabilities easier, so they may be reluctant to protest too much. ||
 * Many assistive technologies, such as JAWS text to speech, are expensive ($1000), and the burden is shouldered by the individual with the disability. Technologies like JAWS could be integrated into operating systems, but aren't. || Assistive technologies are expensive. || Society shouldn't have to pay for the disabilities of others, there is too much of a burden already imposed by the ADA, individuals with disabilities shouldn't get free software, and/or operating system makers shouldn't be forced to integrate functionality. ||
 * Software is difficult to use for individuals with disabilities, and the intuitive and powerful interfaces are saved for the fully abled. || Software could be designed better. || Software is already designed just fine, the majority of users are not disabled and the concentration on the majority is justified, as long as individuals with disabilities can use the software who cares if they can use it as easily as someone who is fully abled? ||
 * Software is quite obviously designed for the fully abled first and the disabled second, and that choice is reflected in the usability of the software by individuals with disabilities. || Programmers don't have people like me in mind when they write software. || Programmers are often required to include a modicum of accessibility in software, and/or that is what assistive software is for - programmers of the original software don't need to concern themselves with programming for accessibility. ||

=Speaking Subject: Software Developer=


 * **Catalysts** || **Statements** || **Corrosions** ||
 * Many developers (perhaps most) have a desire to create the best software possible, but are constrained by money and time. || I would design accessible software if it weren't for time and money constraints. || Software developers themselves rarely have any level of control over budget or time allocation - that is the job of software managers. Software release cycles rarely have time for developing accessible software because it isn't prioritized. ||
 * Developers may have never learned how to create accessible software during the course of their education, and/or have not received continuing education in designing for accessibility. || I don't know how to design accessible software. || Education limits the ability of software engineers to design for accessibility if accessibility was not a core component of the educational process. Additionally, since technology is changing so rapidly, ongoing training is required for developers to stay current. Ongoing training does not often include accessibility training. ||
 * Developers may believe that their software is already accessible by believing that someone else coded the accessibility component, or they don't understand the needs of the disabled community to know where their software falls short. || Our software is accessible. Isn't it? || Developers may not know whether their software is accessible and may believe that someone else is in charge, but they themselves should be concerned with accessibility throughout the process, regardless of function. ||
 * Many developers may believe that the onus is not on them for designing for accessibility and that they can "pass the buck" to other actors, including individuals with disabilities themselves. || I don't need to design accessible software because independent companies have created accessibility software like JAWS. || Accessibility software rarely solves problems of accessibility as well as a built-in solution that is core to the overall system design. For example, JAWS is a kludge compared to what an OS-level built in text to speech engine could be. Accessibility software usually has a cycle of "catching up" to do with current software, and is prone to bugs. ||
 * Developers may use userbase data to determine that the userbase of disabled individuals is too small to warrant their attention. || Such a small percentage of our users are disabled that it doesn't make sense to design the software for them. || Statements like these are what laws like the ADA are aimed to prevent. If this was the prevailing viewpoint and there were no laws to prevent it, there would be very few accessible buildings. Since there are no laws to prevent it, there is very little accessible software. ||

=Speaking Subject: Educator=


 * **Catalysts** || **Statements** || **Corrosions** ||
 * If accessibility isn't valued by the institution and/or department, it won't get taught in all classes. If individual professors aren't motivated by the subject or don't think it's important, it will end up as a unit in a class instead of a core component of good programming. || We teach accessibility, but it is a separate course and/or a unit in a core course. || Accessibility should be taught as a core component of all software engineering courses, because bolting it on later results in a kludge of a system. ||
 * If there is an extremely low institutional or department level disregard or lack of knowledge about the importance of programming for accessibility, then it will not be incorporated into the required curriculum, despite what individual professors may want. || We don't teach accessibility at all or it is not required for graduation. || Accessibility should be required material in all courses, and should certainly be required for graduation. Statements like these demonstrate a disconnect between the userbase and the educational system. ||
 * Some educators may believe that it is not a core component of a software engineer's degree to be able to program for accessibility in all software suites, and that it is better addressed by independent third party programs that are dedicated to accessibility. || Such a small portion of the population is disabled that it doesn't make sense to teach accessibility to all software engineers. It can be accomplished by third party programs. || Software that is not designed to be accessible turns out to not work very well when individuals with disabilities try to use it, even if they are using third party software. ||
 * Even if there is a high level of commitment to good programming practice and accessibility in the educational environment, real world pressures of time and budget may eliminate the good programming habits and accessible code that were taught in college or trade school. || We teach accessibility as a core component of good programming, but we find that most software engineers don't end up incorporating it into their software. || In this case, the educators are doing their best, but the problem lies with the managers in the software companies. ||
 * There may be a real or perceived lack of space in the curriculum to teach good programming practice, including accessibility training. Some professors may view it as superfluous. || We don't have enough time in the curriculum to teach accessibility. || Administration pressures have resulted in departments not teaching things that they ought to be teaching, such as designing accessible software. ||

=Speaking Subject: Software Development Company Manager=


 * **Catalysts** || **Statements** || **Corrosions** ||
 * Managers are under pressures to deliver a product on time and under budget, and accessibility and standards compliance are often the first two items to go off of the wish list for a project. || There isn't enough money or time in the schedule to design for accessibility. || If accessibility and standards compliance are integrated into the process in the beginning, and if the developers actually know what they are doing with accessibility and standards compliance instead of having to learn on-the-fly, the difference in time to market is negligible, if any. ||
 * Given that requirements come from clients and development shops are held to the agreements, if a development shop can't convince a client that accessibility is important, it gets cut. || Accessibility isn't on the list of requirements from the customer, so we won't include it. || Here is a situation where regulation would be very helpful, since it would force customers to include standards compliance and accessibility on their list of requirements. ||
 * The cost-benefit analysis rules out individuals with disabilities. || The market share of individuals with disabilities is so small that it isn't financially viable to program for individuals with disabilities. || Again, regulation can help here, since from a purely monetary perspective, the manager's argument is correct. ||
 * Educational deficiencies are deemed the problem of educational institutions and individual programmers, and the company won't pick up the slack for something that it doesn't consider to be a priority anyway. || Our programmers were never taught how to program for individuals with disabilities, and the company won't pay to send them to training, because it isn't a priority. || If legislation is introduced that requires a baseline of accessibility, programmers would have to learn how to code for accessibility, and the burden would be shared amongst companies and educational institutions. ||
 * Companies that do adhere to standards and code for accessibility end up often creating a better product, albeit with a slightly higher up-front cost. || We use standards-compliant code, program for accessibility, refuse to back down on our standards for any customer, and end up creating better, faster, easier to update programs than anyone else on the market. || There is a perception in the industry that doing things right and doing them quickly or cheaply are mutually exclusive. There is a saying in IT: "You can have it done quickly, cheaply, or well. Pick any two." ||