Important note: This Wiki page is edited by participants of the EOWG. It does not necessarily represent consensus and it may have incorrect information or information that is not supported by other Working Group participants, WAI, or W3C. It may also have some very useful information.

Business Case

From Education & Outreach
Jump to: navigation, search

This page provides the structure for the Q3 2017 review and rewrite of the suite of documents linked from the current page Developing a Web Accessibility Business Case for Your organization

GitHub repo for Business Case, Open Issues

Editor's request for Case Study/Data

In support of making the argument for businesses to invest in accessibility, editors are seeking data and/or case studies to illustrate those arguments in the real world. Please share any information that can be made public. If the source is to remain anonymous, that is OK as well. Thank you!

[Add name here]

Submitted by:

Date of case study or data collection:



  • Primary purpose: encourage people in organizations of all types and sizes to understand and promote business benefits of web accessibility
  • Secondary purpose: to provide tools to persuade others and link to resources for further exploration of the topic


  • From that document, these considerations:
    • Primary audience - people who are trying to "sell" accessibility to their organization, or get "buy-in" from an organization to start a Web accessibility initiative, adopt a Web accessibility policy, etc.
    • Secondary audiences include reporters, trainers, ... All types of organizations, including commercial/industry, government, education, non-profit, etc.
    • Direct audience for this document could be varied, such as technical Web developer, business analyst, outside accessibility advocate, etc.
    • The indirect audience is the people reading the organization's customized "business case" which is often managers and others who are responsible for allocating time and money resources to Web projects. These people may not understand the technical aspects of the Web.

Current Documents

To be addressed separately, later: "Web Accessibility is Smart Business" Presentation

Recommended Approach

  1. Request GitHub repository for Business Case (can this be done in format of new site?)
    — [done] (yes, you can do it in the new format :) ~SLH
  2. Request metrics for these pages, how often are they accessed and what is the difference in the access rate of the different "Factor" pages?
    — [done] sent to Editors ~SLH
  3. Analyze whatever data there may be and review content in that context.
  4. Confirm findings and conclusions. Share edit/tersification plan with review group and all of EOWG.
  5. Re-think existing structure and length of content. Is it necessary, repetitive, useful? Create streamlined version. Circulate to Review team (and any in EO who have interest.) In email to EO archive list, Vivienne suggests the following:
    • content is dense, hard to find what you need
    • would benefit from more current case studies
    • understanding/presentation of business methodology needs updating
  6. August 23 addition Based on data analyses and preliminary comments, the approach has been modified as follows:
    • Five page tabbed interface will be modified to be only one page.
      — Given this is a significant proposed change, I think it would be good to bring a detailed outline &/or an early rough concept draft to all of EOWG for review before finalizing approach and polishing wording. ~SLH
    • Case studies developed
      — Are you envisioning that the case studies will all be that one page, too? I think that gets away from what some were thinking of having smaller chunks of info per page. (not me, btw -- I usually prefer related info on one page, rather than lots of small pages :) ~SLH
      — In 1 I proposed that these are lower priority than other work. ~SLH
    • Post by September 1
    • Accept and address GitHub comments for two weeks and post how issues are addressed.
    • Once team agrees, bring to EO for final approval via survey.

Target Delivery date

Revised 09 November:

  • Draft to circulate to editorial team - 23 January
  • Review discussion in EO meeting - 01 February
  • Review comments due - 06 February
  • Editor's Draft for editorial team approval - 10 February
  • Approval to Publish to planning team - 14 December
  • Approval Survey - 16 February

Current references and notes

Discussion of these references and notes at the 07 November face to meeting at TPAC led to the following conclusions:

  1. Editorial team will not rely on the current method of organizing sub topics and categories.
  2. Will introduce more iconography, attempt to minimize wall of text.
  3. will include a number of supporting resources from the links and materials below.
  4. Will make first attempt at a one page structure but be open to breaking into sub pages if needed.

Revised Approach

  1. Frame the questions/answers about web accessibility in terms relevant to the industry you work within: What is it that is most important to the person making the decisions?
    • Can accessibility save them money?
    • Can it reduce legal risk?
    • Can it increase their income?
    • Can it increase their market share (and can it be demonstrated?)
    • Can it increase their institutional profile/reputation?
    • Does it align to their stated values, commitment statements (diversity and inclusion for example)
  2. Identify and address what is it that particular organizations/companies want that accessibility provides. Create a template that allows them to map the ways that accessibility benefits them to get to adoption more easily.
  3. Point to case studies (and/or testimonials) in support of statements made. Explore permission to use Barclay's Making Your Business Accessible and similar. W3C testimonial Guidelines

Questions EO participants can use to gather data

The following questions were brainstormed at an EO meeting and can be used as a place to start. Feel free to ask other, more relelvant questions to the situation that has the most meaning to those you interview:

  • What was the primary driver for your implementation of a digital accessibility program?
  • What (if any) were secondary ones?
  • At what stage is your accessibility program (for example would you say you were just getting started, mid-implementation, mature, etc)
  • What were/are the biggest hurdles to overcome?
  • Have their been any unexpected benefits? If so, please describe.
  • Overall how would you rate the ROI (low, acceptable, good, great)


  • Disability as Diversity in Fortune 100 Companies Published online in Wiley InterScience ( DOI: 10.1002/bsl.62 May, 2005
  • Diversity and Internationalization International Business Review, online publication.
  • "Understanding your users and their needs is not a ‘nice to have’. It’s a strategic imperative in software design." Hasso Plattner, Institute of Design, Stanford University. Intro to Design Thinking
  • 2016 Ikeda Forum: Democracy, Inclusion, Community Dr. Caesar McDowell at IKeda Forum, new perspective on curb cuts from 1945!
  • How Designing for the Disabled is Giving Google an Edge
  • Haben Girma on Linked In on how People with Disabilities Drive Innovation
  • Neil Lenane, Business Leader of Talent Management at Progressive Insurance “If you do not intentionally include, you unintentionally exclude."
  • Forbes Global Diversity and Inclusion Report found that:
    • Diversity is a key driver of innovation and is a critical component of being successful on a global scale.
    • A diverse and inclusive workforce is crucial for companies that want to attract and retain top talent.
    • Nearly all top performing respondents reported that their companies have diversity and inclusion strategies in place.
    • Responsibility for the success of company’s diversity/inclusion efforts lies with senior management.
    • Significant progress has been made to build and retain diverse workforces, but there are still some impediments to companies’ efforts. Understanding and retaining workers with disabilities was an area recognized as needing improvement.