Case Study: Accessibility in Software Development

- Sarah Horton*

AllTogether’s web-based collaboration tool is popular and versatile, used by community groups, non-profits, schools, agencies, businesses, and tech companies around the world to manage project planning and communication. With the rise in remote working, the product has gained popularity as a platform for remote teams to monitor timelines, share documents, track tasks, and communicate. “I couldn’t do my job if it wasn’t for AllTogether,” reported a UX designer who uses the tool to collaborate on projects with team members.

For a recent release, the product team implemented a new design pattern to provide inline access to the edit feature using hidden controls. With the inline edit feature, hovering the pointer over an element, like an event in the calendar or an item in a task list, displays a pencil icon button that the user can click to make the element editable. Moving the pointer away from the element causes the button to disappear. This hidden control design pattern replaced previous edit functionality provided using a visible edit text button and modal dialog, with the aim of greater convenience and less clutter.

AllTogether’s product team was well into implementing the new feature when they realized they had overlooked some key accessibility requirements. Consequently, the pattern had significant accessibility issues. Results from QA testing showed that the inline edit feature could not be focused or operated using keyboard keys, such as TAB to focus, ENTER to activate, and arrow keys to navigate. Since the pencil icon button only displays on pointer hover, the feature was essentially nonexistent for people who cannot point-and-click, including blind people and people with mobility impairments. QA also noted that people with cognitive disabilities may have difficulty finding the hidden controls, people with vision loss who use screen magnification may have difficulty locating and operating the controls within a magnified viewport, and people with limited mobility or dexterity may have difficulty interacting with the dynamic show/hide controls using a pointer device or speech.

AllTogether has a Diversity Advisory Board, established to help the company steer clear of discriminatory practices in technology development, including disability discrimination. To that end, company accessibility policy specifies conformance with the Web Content Accessibility Guidelines (WCAG) for all web and mobile content and products produced by the company. AllTogether’s staff are required to comply with company policies, including the accessibility policy, as a condition of employment. AllTogether’s Office of Risk and Compliance includes nonconformance with WCAG on the company’s risk register. The results from QA testing represent nonconformance with requirements related to keyboard accessibility and predictable interaction.

Nevertheless, the product owner was being pressured to launch the new version despite the accessibility defects, with leadership asking, “How many blind people use our product, anyway?” In consultation with Risk and Compliance, company leadership decided that customers who use AllTogether could provide accommodations to any of their employees who would be affected by the new feature’s accessibility issues. The product owner went ahead with the release as scheduled and worked with the accessibility team to add details of nonconformance with Success Criterion 2.1.1 Keyboard to AllTogether’s Accessibility Conformance Report. The accessibility team made note to provide details of nonconformance with Success Criterion 3.2.7 Visible Controls with the release of the next version of WCAG. They also partnered with customer service to establish an accessibility webpage with a dedicated support email and to support any users who encountered accessibility barriers with the new version.

The next months revealed the impact of the new feature. In addition to responding to queries from keyboard users who were suddenly unable to use the edit feature, customer service was busy helping users overcome the other accessibility barriers caused by the hidden controls. Many users had trouble learning and remembering the new pattern. At first, they thought the edit feature had been removed altogether. When directed to the feature, they had trouble remembering which elements were editable and which were not. Several users reported difficulty showing and activating the edit feature with a mouse due to the need for manual dexterity. And for screen magnification users, the edit button would sometimes appear off-screen, and they had difficulty activating the button and accessing the functionality. Given the productivity costs and risk of disability discrimination of using the updated version with accessibility defects, some customers decided to roll back to the previous version and wait for AllTogether to fix the accessibility defects and release a new version.

Analysis

Company leadership decided to release the application with the inaccessible feature, despite the costs and risks to the company, its customers, and disabled users. On the positive side, the product owner responded by working with the accessibility team and customer service to document the accessibility defects and to ramp up support for impacted users. Customer service responded to support requests from users who had difficulty with the new feature and worked with customers who opted to roll back to the previous version. However, disabled users encountered accessibility barriers that prevented them from performing tasks using the edit feature. Customers who updated to the new version risked discriminating against their disabled staff, customers, and community by using a tool with accessibility defects. AllTogether also risked causing disability discrimination, as well as reputational damage by producing defective software. The company’s operating costs increased as a result of the increase in customer support requests and the need to maintain two versions of the software — costs greater than the costs of addressing accessibility requirements in feature development.

This case demonstrates how the Code of Ethics and Professional Conduct could have guided actions and decisions toward developing better software at a lower cost, minimizing harm to the company and its customers and users. The company had in place both an accessibility policy and well-established accessibility guidance and best practices. Had members of the product team considered Principle 2.3 (Know and respect existing rules pertaining to professional work) during design and development, they would have not spent time implementing what turned out to be an inaccessible feature.

While their Diversity Advisory Board and accessibility policy evidence AllTogether’s intent to benefit all people, including disabled people, some of their actions and decisions were inconsistent with that intent. Had company leadership been guided by Principle 1.1 (Contribute to society and to human well-being, acknowledging that all people are stakeholders in computing), they would have prioritized resolving critical accessibility defects over sticking to the launch schedule. Leadership would have directed the product team to repair accessibility defects before doing any additional feature development, reaffirming the company’s commitment to accessibility and disability inclusion, thus producing a more positive product and enhancing their own reputation.

AllTogether’s investment in Risk and Compliance and customer service demonstrates a commitment to safeguarding the company and its customers and users. Principle 1.2 (Avoid harm) directs us to follow best practices as a way of minimizing negative consequences. Had AllTogether’s product team adopted accessibility best practices, accessibility requirements would have been included from the start of feature development, with accessibility needs illustrated in user stories, specified in acceptance criteria, and validated in unit tests. Accessibility issues would have been surfaced well before the feature went for QA testing, and the product owner would have had support from leadership to dedicate time to addressing accessibility defects. On the positive side, the company updated AllTogether’s Accessibility Conformance Report with details about accessibility defects and established a dedicated avenue for reporting accessibility issues, supporting Principle 1.3 (Be honest and trustworthy) by disclosing potential problems to customers and offering help. Providing a credible account of accessibility issues and a plan for redressing them is a step toward addressing negative consequences.

Various roles at the company played a part in unnecessarily limiting disabled people’s ability to work by releasing inaccessible software onto the market. Had professional practice been guided by Principle 1.4 (Be fair and take action not to discriminate), everyone involved would have redirected efforts toward an accessible approach and implementation, in their own work and the work of their colleagues. With consideration of accessibility needs and adherence to accessibility standards from the start, the feature might have been implemented without accessibility defects. Done right, a simplified, streamlined interface would have benefited people with disabilities and improved usability overall.

When we uphold ACM’s Code of Ethics and Professional Practice, accessibility becomes a core marker of quality and competence, a badge of honor, an indicator of good practice. It allows us to put aside the debate over whether computing professionals have accessibility obligations. We do. And when we meet our obligations and avoid creating barriers, we make room for accessibility to drive innovation by exploring new technologies that promote autonomy and participation and provide excellent user experiences for everyone.

Get involved in advancing accessibility through ACM’s Special Interest Group on Accessible Computing (SIGACCESS) and Special Interest Group on Human-Computer Interaction (SIGCHI).

*Sarah Horton is a member of the research team working on Teaching Accessibility in the Digital Skill Set at the University of Southampton. The development of this case study is funded by UK Research and Innovation Future Leaders Fellowship MR/S01571X/1.

---

These case studies are designed for educational purposes to illustrate how to apply the Code to analyze complex situations. All names, buisnesses, places, events, and incidents are fictious and are not intended to refer to actual entities.