PaperlayerView exact revision on arXiv

Source-linked AI summary

Accessibility in Software Practice: A Practitioner's Perspective

Tingting Bi, Xin Xia, David Lo, John Grundy, Thomas Zimmermann, Denae Ford

arXiv:2103.08778v1cs.SE

TL;DR

How accessibility is incorporated into software projects and addressed across development remains unclear, despite its importance to everyday software use. The authors combine practitioner interviews and a survey to examine accessibility practice. Respondents reported accessibility challenges, including inadequate resources and expertise, and identified organizational factors as important.

  • Problem

    Empirical evidence about how practitioners perceive accessibility and how software projects incorporate accessibility features remains limited, despite accessibility’s importance in software development.

    Source: §1 · p. 2

  • Method

    The authors used a mixed-methods study combining interviews with 15 practitioners and an online survey of 365 respondents.

    Source: §1 · p. 3, §2.2 · p. 4

  • Results

    45% of survey respondents said their projects faced accessibility-development issues, including inadequate resources and experts; 54% agreed or strongly agreed organizational factors were critical.

    Source: §4 · pp. 20–21

  • Takeaways & Limitations

    The authors advocate treating accessibility as a first-class consideration throughout software development and provide guidelines to help practitioners recognize accessibility challenges.

    Source: §1 · p. 3, §7 · p. 25

    The 15 interviewees may not be representative of all practitioners, despite the follow-up survey’s broader international reach.

    Source: §5 · p. 22

Abstract

from arXiv · show

Being able to access software in daily life is vital for everyone, and thus accessibility is a fundamental challenge for software development. However, given the number of accessibility issues reported by many users, e.g., in app reviews, it is not clear if accessibility is widely integrated into current software projects and how software projects address accessibility issues. In this paper, we report a study of the critical challenges and benefits of incorporating accessibility into software development and design. We applied a mixed qualitative and quantitative approach for gathering data from 15 interviews and 365 survey respondents from 26 countries across five continents to understand how practitioners perceive accessibility development and design in practice. We got 44 statements grouped into eight topics on accessibility from practitioners' viewpoints and different software development stages. Our statistical analysis reveals substantial gaps between groups, e.g., practitioners have Direct v.s. Indirect accessibility relevant work experience when they reviewed the summarized statements. These gaps might hinder the quality of accessibility development and design, and we use our findings to establish a set of guidelines to help practitioners be aware of accessibility challenges and benefit factors. We also propose some remedies to resolve the gaps and to highlight key future research directions.

1 INTRODUCTION

Although accessibility needs attention throughout software development, it remains unclear how it is incorporated into projects and products. This study examines practitioners’ perspectives and identifies challenges, benefits, and gaps to inform guidance for practice.

1 INTRODUCTION

  • The paper frames accessibility as relevant to a wide range of users and as a software quality tied to usability and acceptance.It describes universal design as approaches incorporated into a product so end-users can access software applications.Source: §1 · pp. 1–2
  • Accessibility should be considered throughout the development life cycle, since omitting it can lead to poor usability, negative user feedback, and substantial re-engineering.The paper argues for treating accessibility as a first-class consideration in software development.Source: §1 · p. 2
  • Prior research has examined accessibility for specific disabilities and Android apps, but empirical evidence about practitioners’ perspectives and project practices remains limited.The authors argue that understanding practitioners’ views could support more tailored accessibility design and implementation.Source: §1 · p. 2
  • The study combines 15 detailed interviews with an online survey of 365 respondents from 26 countries.Its contributions include identifying challenges and experience-group gaps and offering practitioner guidelines and suggestions.Source: §1 · p. 3

2 STUDY DESIGN

The study asks how practitioners perceive accessibility and how it fits into the software life cycle. It uses interviews to develop accessibility statements and a worldwide survey to examine those statements and group differences.

2.1 Objective and research questions

  • The research questions examine practitioners’ perceptions of accessibility and how accessibility needs fit into the software development life cycle.The questions cover accessibility understanding, work characteristics, organizational factors, requirements, design, implementation, testing, and evaluation.Source: RQ1: What are practitioners’… · pp. 3–4

2.2 Methodology

  • The sequential mixed-methods study used 15 practitioner interviews followed by an online survey with 365 validated responses.The survey was intended to confirm, refute, or extend the interview findings.Source: §2.2 · p. 4, Figure 1 · p. 4

2.2.1 Interviews.

  • The semi-structured interviews gathered practitioner views, and thematic coding produced 44 accessibility statements grouped into eight topics.The interviewees specialized in accessibility design and averaged nine years of professional experience.Source: §2.2.1 · pp. 5–6

2.2.2 Survey.

  • The online survey presented the 44 interview-derived statements for scoring and comments, and compared responses across practitioner groups.Of 431 responses, 365 were retained for analysis; the authors report 15 statements with statistically significant group discrepancies after applying a multiple-comparison correction.Source: §2.2.2 · pp. 6–8, Figure 2 · p. 7

3 STUDY RESULTS

The results organize practitioner views around accessibility understanding, work characteristics, and organizational factors. Respondents broadly endorsed accessibility while also reporting challenges across requirements, design, and testing.

3.1 RQ1: What are practitioners’ perceptions of accessibility development and design in practice?

  • Respondents rated “Accessibility needs to be incorporated into all software projects” (S1) 4.25 and “Accessibility should be integrated with all software activities” (S3) 4.19.Source: §3.1 · p. 9
  • Respondents characterized accessibility as intertwined with multiple activities and dynamic, while also associating it with innovation and goals of easy-to-use software.The reported mean scores were 4.19 for S8, 4.01 for S9, and 3.92 for S6.Source: §3.1 · p. 9
  • Practitioners identified organizational and requirements challenges, including limited demand, unclear documentation, expense, and insufficient company resources for requirements elicitation.The statements also describe accessibility as context-dependent and report that large companies may treat it as a key task.Source: §3.1 · p. 9
  • Design concerns included front-end focus, time-consuming iterative detailed design, difficult design decisions, and potentially outdated accessibility standards.The statements also mention using multiple views to address trade-offs among user groups and applying ML and AI to accessibility design.Source: §3.1 · p. 9
  • Testing concerns included a long list of accessibility tests and difficulty engaging end-users for feedback, while respondents also viewed automatic testing tools as useful.The reported mean scores were 4.25 for S36, 4.19 for S37, and 4.19 for S38.Source: §3.1 · p. 9

T8. Accessibility Evaluation

Accessibility evaluation requires human judgment and substantial effort, while practitioners describe accessibility as a broader, iterative concern shaped by skills, communication, and organizational support.

T8. Accessibility Evaluation

  • No single tool can determine whether a project meets accessibility guidelines; human evaluation is always required, and standards are helpful.The evaluation statements also identify a need for more comprehensive evaluation.Source: T8. Accessibility Evaluation · p. 9
  • Accessibility evaluation takes extra effort, and practitioners report difficulty obtaining end-user feedback.The statements also call for more comprehensive evaluation.Source: T8. Accessibility Evaluation · p. 9

3.1.1 Understanding accessibility.

  • Practitioners described accessibility as dynamic, with requirements extending beyond disability to general users; some viewed it as a potential competitive feature, such as voice-assistant functionality.The authors report that eight interviewees said accessibility matters for every project and should target general end-users.Source: §3.1.1 · pp. 10–11
  • Only 30% of participants had direct accessibility-related work experience, and projects often addressed accessibility lightly, such as through interface colors and layout.Practitioners also said accessibility should be intertwined with development activities from requirements elicitation through testing; 72% agreed.Source: §3.1.1 · pp. 10–11

3.1.2 How do work characteristics impact accessibility development and design in practice.

  • Thirty percent of survey respondents agreed or strongly agreed that interacting with outside stakeholders about accessibility is difficult.Interviewees also reported challenges communicating with clients.Source: §3.1.2 · p. 12
  • Accessibility work requires specific skills and knowledge, yet practitioners reported limited systematic training and difficulty planning tasks, eliciting requirements, consulting, and testing.Some interviewees also reported that accessibility work can require more effort and make it harder to control progress toward completion.Source: §3.1.2 · pp. 11–12

3.1.3 How do organizational factors impact accessibility design and development in practice.

  • Accessibility implementation is context-dependent, while practitioners identified limited resources, expertise, time, budget, and company support as constraints.The authors summarize these organizational factors as strongly impacting accessibility design and development in practice.Source: §3.1.3 · p. 13

3.2 RQ2: How does addressing accessibility needs fit into the software development life cycle?

The section examines accessibility across requirements, design and implementation, testing, and evaluation, finding recurring resource, expertise, and end-user involvement challenges throughout the development life cycle.

3.2.1 Software requirement elicitation for accessibility.

  • Accessibility requirements take substantial effort to collect and are often ambiguous, while time, resource, and strategy constraints hinder their elicitation.Practitioners cited user and task analysis, checklists, ML or AI techniques, and attention to domain and technological context as ways to identify requirements.Source: §3.2.1 · pp. 13–15

3.2.2 Software design and implementation for accessibility.

  • Accessibility can require richer hardware, feature, and model design, yet projects may lack upfront architectural planning and later refactoring is more challenging and time-consuming.Interviewees also recommended separating accessibility requirements for low coupling and reuse.Source: §3.2.2 · p. 15
  • Accessibility innovation and implementation models identify organizational processes that resist or support implementation.The reported implementation process is iterative and includes aligning the project team on accessibility requirements and preparing the implementation environment.Source: §3.2.2 · p. 16
  • Accessibility design is often short-term and UI-focused, with many projects requiring iterative refactoring after release and standards posing barriers for less experienced developers.Interviewees also described limited upfront architectural planning and business pressures favoring short-term goals over accessibility work.Source: §3.2.2 · pp. 15–17

3.2.3 Software testing and quality assurance for accessibility.

  • Accessibility testing must cover functional and non-functional requirements, but dedicated test suites are uncommon, existing suites can be weak, and recruiting end-users for manual testing is challenging.Participants valued automated tools while also emphasizing manual testing and user feedback.Source: §3.2.3 · pp. 17–18

3.2.4 Software evaluation for accessibility.

  • Evaluation combines technical standards with end-user involvement, but obtaining sufficient user feedback and investing the necessary time remain challenges.Practitioners favored iterative, user-centered evaluation; no single tool could determine whether a project meets accessibility guidelines.Source: §3.2.4 · p. 18

3.3 Gaps differ across demographic groups

Survey responses differed across practitioner groups, with the differences varying by accessibility-related experience, organization size, and development platform.

3.3 Gaps differ across demographic groups

  • Practitioners with direct accessibility experience more often supported addressing accessibility across projects, while indirect-experience practitioners more often reported low demand and a lightweight, front-facing focus.Six statements differed significantly between the groups.Source: §3.3 · p. 19
  • Small-organization practitioners more often reported lacking resources and support, while large-organization practitioners more often supported comprehensive accessibility evaluation.Four statements differed significantly between organization-size groups.Source: §3.3 · p. 19
  • Mobile practitioners more often viewed accessibility standards as unclear and time-consuming and accessibility work as non-core, while web practitioners focused more on basic functionality design and testing.Seven statements differed significantly between web and mobile development groups.Source: §3.3 · p. 19

4 DISCUSSION

The study finds accessibility is considered across software life-cycle stages, but practice often remains simple and short-term amid resource and expertise constraints. Its discussion recommends earlier, organization-wide integration alongside stronger standards and education.

Accessibility awareness and challenges of accessibility development

  • 45% of survey respondents reported project issues affecting accessibility development and design, including inadequate resources and expertise.The authors also report that addressing accessibility across development phases takes considerable effort and time.Source: §4 · p. 20

Exploring the new success criteria; Education for accessibility knowledge

  • The authors argue that existing accessibility standards need updating as technology changes and encourage comprehensive success criteria for different accessibility levels.They also recommend greater higher-education coverage of accessibility knowledge, life-cycle integration, documentation, testing, and evaluation.Source: §4 · pp. 20–21

Organizational factors are vital for accessibility development

  • Organizational factors ranked highest among interviewees, and 54% of survey respondents considered them critical to accessibility incorporation and design quality.Large companies tend to have more resources, while small companies face expertise, schedule, or management-support constraints.Source: §4 · p. 21

Accessibility-driven development

  • Participants described accessibility as increasingly useful beyond disability support, including making projects easier to use in particular scenarios.Examples include voice assistants and more natural interfaces.Source: §4 · p. 21

General recommendations for accessibility development and design in practice

  • The paper recommends a general set of practical challenges and recommendations for incorporating accessibility into projects.It is based on the discussion and implications of RQ1 and RQ2 and is presented in Table 3.Source: §4 · p. 21, Table 3 · p. 22

Organizational factors and People - RQ1

  • Stakeholders should agree on accessibility requirements, their priority, and how to address and document them, while recognizing design trade-offs.The recommendations also call for team-based accessibility decisions.Source: §4 · p. 21

Process and Practices - RQ2

  • Accessibility should be addressed from early development phases through an iterative life-cycle process, with supporting approaches and tools.Recommendations include linking requirements to design and code, considering target users, and exploring machine-learning and AI support.Source: §4 · p. 21

5 THREATS TO VALIDITY

The study’s validity is qualified by possible limits in participant representation, survey interpretation, interview-derived statements, and the completeness and generalizability of its findings.

5 THREATS TO VALIDITY

  • Interviewees may not represent all practitioners, and survey respondents may conflate generally important skills with skills relevant to their projects or contexts.The interviews involved 15 practitioners from three companies in two countries; the survey had 365 respondents from 28 countries across five continents.Source: §5 · p. 22
  • Some survey respondents may have misunderstood statements, although only 5.3% selected “I Don’t Know”; the researchers also checked transcripts, results, and comments repeatedly.The survey was translated into Chinese to support respondents from China.Source: §5 · p. 23
  • The interview statements may be incomplete or reflect experts’ backgrounds and difficulty articulating their opinions.The researchers also prompted discussion of topics participants had not raised and surveyed practitioners to assess interviewees’ opinions.Source: §5 · p. 23
  • The findings may not represent all software engineers; most respondents were from China and the U.S.Participants came from various companies and open-source projects, but the authors identify geographic concentration as a boundary on generalizability.Source: §5 · p. 23
  • The 44 statements may not cover every accessibility concern, despite analysis of additional opinions from 176 survey respondents.The researchers categorized comments using closed card sorting and report that most supplemented the existing statements; they suggest adding two statements and recruiting more developers.Source: §5 · p. 23

6 RELATED WORK

Prior work examines accessibility in software processes and specific development settings, while this study elicits practitioners’ perspectives across mobile and other general software contexts. It also follows a mixed-methods approach used in earlier practitioner-opinion studies.

6.1 Software design and development for accessibility

  • Paive et al.’s literature review examined accessibility methods and gaps in software engineering, while this study seeks practitioners’ opinions and differences across demographic groups.The review motivated the present study’s focus on how accessibility fits into the development life cycle.Source: §6.1 · p. 24
  • Prior work analyzed accessibility issues in over 1,000 Android apps and surveyed 66 practitioners, whereas this study covers mobile and other general software development scenarios.Other cited work evaluated nine accessibility testing methods in agile processes.Source: §6.1 · p. 24
  • Other accessibility studies addressed disability-aware process models, shallow U.S. faculty teaching, and challenges faced by blind developers, including inaccessible IDEs.The teaching study identified faculty knowledge as a critical barrier to clear, discipline-specific learning objectives.Source: §6.1 · p. 24

6.2 Studies on developer expertise

  • Earlier practitioner-opinion studies examined coding proficiency and identified 38 skills across nine categories, including 21 critical skills.Other examples studied differences in video-game and machine-learning development, and release-note production and use.Source: §6.2 · pp. 24–25
  • This study likewise uses a mixed-methods approach to investigate accessibility challenges, issues, and benefits from practitioners’ opinions.The authors frame the approach as helping teams identify essential skills to acquire for accessibility practice.Source: §6.2 · p. 25

7 CONCLUSION

The study groups practitioner statements about accessibility across software-engineering topics and development stages. It uses those findings to identify challenges and recommendations, while arguing for accessibility as a first-class consideration throughout development.

7 CONCLUSION

  • The study groups practitioner statements across software-development stages and uses them to describe accessibility obstacles, benefits, challenges, and recommendations.The authors state that this organization can help researchers and practitioners better understand accessibility in software projects.Source: §7 · p. 25
  • The authors advocate treating accessibility as a first-class consideration throughout software development.They conjecture that accessibility needs further exploration from perspectives such as end users.Source: §7 · p. 25
Loading 2103.08778v1…