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


  • 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


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 23 August:

  • Draft distribution delayed, new target 01 September
  • One week review cycle and feedback until 08 September
  • address comments, final draft on Tuesday, 12 September


  • When group receives metrics (done 24 July)
  • GitHub setup date (done 24 July)
  • response rate of review team