Social Networking Application Business Case

From WAI-Engage: Web Accessibility Community Group
Revision as of 09:12, 8 September 2012 by Pthiessen (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Navigation: WAI-Engage wiki main page > Promoting web accessibility



Writing and receiving approval for a business case can be a challenge, especially when the return on investment (ROI) is not clear to management. The landscape of my social networking company is one of high competition and a business model based on receiving revenue from online advertising. We're constantly pushing to innovate new and often complex features, and fix the most pressing bugs.

The big challenge comes from attempting to innovate and maintain features across a large number of platforms. In our case, this is presently big and small screen Web, J2ME, iOS, Android, Blackberry, WP7/8, and Nokia applications. For any change to the code base, it must be truly justified because of the amount of work to update and maintain our cross platform application. Additionally, a majority of our revenue comes from online advertising and in particular from our Web app. We rate whether we're successful by revenue from ads and to a lesser extent user growth. Ad revenue occurs when showing an ad impression to a user, showing a targeted ad to a user, and when a user activates an add. The most valuable users from the revenue side are targeted users that click on ads. As a result any business case must show a potential increase in this user group.

With this environment in mind, I spent two years attempting and failing to make a business case for accessibility. This was before I changed my strategy and finally receiving approval.

Armed with the WAI Business Case, I attempted to receive approval to add a level of accessibility to our apps, with an emphasis on web apps. For each business case I wrote, I went through the 4 main WAI factors: social, technical, financial, and legal. A bullet point summary of proposal and response is below.

  • Social: improved PR from being a good corporate citizen, giving all users an equal ability to chat and participate online, and simply because it's the right thing to do.

Response: Management expressed an interest in making the world a better place but that this could not be done without a clear ROI. Since our app is developed primarily by programmers under 30, and our primary user demography consists of teens and young adults, the demographics mentioned in the social factor of the WAI Business Case do not match.

  • Technical: An increase in code maintainability and SEO may be achieved by adding more semantically rich HTML and following best practices.

Response: There is no clear ROI beyond making developers happy. The SEO bit did get some interest but since our app is consistently showing in the top 3-5 search results, this was not seen as a priority.

  • Financial: An increase in new users could give us a competitive edge to reach users that our competitors were not.

Response: What management really cared about was users that click ads. It is possible that disabled users do click Web ads but I could not find any studies to back this up. (This would be a great/impactful paper topic).

  • Legal: I briefly mentioned the possibility to move into the public sector and have our apps viewed as a communication tool where legal requirements for accessibility exist in organizations.

Response: We provide a free Web service that is not legally bound to any accessibility requirements and we do not intend to enter into the public sector.

The business cases I presented were turned down because I could not demonstrate a clear potential for ROI. Over time, I became more and more frustrated with my company's need to justify ROI, but I kept looking for new ways to show the value of accessibility. Over time, the mobile Web became more and more important to our company, so I thought I'd try throwing this into my business case for accessibility. I kept the social and legal factors in the business case as potential long term benefits.

I emphasized technical and financial benefits using mobile design best practices, and how, with a redesign, we could serve our Web client to mobile users. I took this a little further and also emphasized our cross platform issues and following best practices like the MWBP and WCAG as a solution to have one an adaptable app serve all users over all platforms via the Web.

Response: Approved. The mobile Web is seen as the new big area for user growth and ad revenue. By focusing on this proposal, I showed a clear ROI for accessibility. By including accessibility as a side benefit to create an app to serve all users on all platforms, we could drop the cross platform madness. This was seen as a sign of hope in reducing development costs and increasing quality by focusing on one application.

Management was really excited by this business case and gave it approval. The main reason for acceptance is the incredible growth of the mobile Web with the potential to reach more users in new markets, and the ad revenue that would hopefully follow. So it seems that anything pro mobile is seen as a ROI. Additionally, a more adaptable Web client could potentially be our solution to an ever increasing number of devices to support. It took about three years to write a successful business case, and it seems the key is in understanding your company's business focus and adapting your business case using the WAI four factors with an appropriate emphasis.

by Peter Thiessen



(This page is protected from editing. Feel free to post comments, questions, suggestions in the Business Case Examples section of the Promoting web accessibility wiki page.)