• Skip to content
• | Change text size or colors

WAI: Strategies, guidelines, resources to make the Web accessible to people with disabilities

Site Navigation

W3C Home

Web Accessibility Initiative (WAI) Home

1. Introducing Accessibility
2. Guidelines & Techniques
3. Managing Accessibility
   1. Policy Resources
   2. Business Case
      1. Social Factors
      2. »Technical Factors
      3. Financial Factors
      4. Legal & Policy Factors
   3. Implementation Plan
   4. Developing Training
   5. Technical Papers
4. Evaluating Accessibility
5. WAI Groups
6. About WAI

Technical Factors in Developing a Web Accessibility Business Case for Your Organization
[Change-marked version of 23 June 2009 incorporating WCAG 2.0 and Older Users]

This is an old draft. The published version of this document is at www.w3.org/WAI/bcase/.

Editors Draft: 8 June 2009 [changelog]
Status: This document is a draft and should not be referenced or quoted under any circumstances. Please send comments to wai-eo-editors@w3.org (a publicly archived list). The current published version of this document is at www.w3.org/WAI/bcase/.

end of note

Introduction

This page is part of a resource suite that describes the social, technical, financial, and legal and policy factors relevant to developing a customized business case for Web accessibility for a specific organization.

Implementing Web accessibility solutions often results in improved technical performance. The [relative] importance of various technical benefits of Web accessibility is different for specific organizations and situations. For example, reducing server load might be most important to an organization with a large, mission-critical, high-traffic site; whereas another organization that focuses on cutting-edge technology might be more interested in interoperability and being prepared for advanced Web technologies. {Yet} [However,] these same technical benefits might not be very important for organizations with small, simple sites; [they might be more interested in simplifying site maintenance].

This page provides guidance on addressing technical factors in a business case for Web accessibility.

Identifying Technical Factors for a Specific Organization

The following questions {can} help identify how the technical aspects of Web accessibility apply to the organization:

• Is the organization starting a new Web development or redesign effort?
  If so, the business case can emphasize the technical benefits of incorporating accessibility early in the project. See Reduce Site Development and Maintenance Time.
• Does the organization change {s} site content or design frequently?
  If so, the business case can emphasize that Web accessibility can reduce maintenance time. See Reduce Site Development and Maintenance Time.
• How important is it to the organization to reduce bandwidth use or server load?
  For example, if it is important for the organization to reduce the need for additional servers or increase the download speed, the business case can emphasize these factors. See Reduce Bandwidth Use and Server Load.
• Does the organization want its website to work in different configurations?
  For example, if the organization wants its website to work on multiple operating systems, Web browsers, and devices, the business case can show how Web accessibility contributes to interoperability and device-independence. See Enable Content on Different Configurations.
• How important is it to the organization to be prepared for advanced Web technologies?
  For example, if the organization is interested in taking advantage of advanced Web technologies, this factor can be included in the business case. See Be Prepared for Advanced Web Technologies.
• Does the organization want to have high-quality websites that meet standards?
  If so, the business case can point out the overlap between Web accessibility standards and other standards. See Have High Quality websites.

See Web Content Accessibility Guidelines (WCAG) Overview for more information about the WCAG {1.0 Checkpoint} references below.

Reduce Site Development and Maintenance Time

Incorporating accessibility usually increases site development time initially, as discussed in Financial Factors. However, in the long term Web accessibility can reduce the time an organization spends on site development and maintenance, as follows:

• Reduce time and effort needed to change presentation across a site by defining presentation through a style sheet and using proper markup (for example, in XHTML) for structure.
  {(WCAG 1.0 Checkpoint 3.1, 3.3, 3.5, 3.6, 3.7, 5.4)}
  Presentation includes design and style such as font size, font face, and background color. If the presentation is defined in an external style sheet, it can be changed throughout the site by making the change to that one style sheet. However, if the presentation was improperly defined throughout the HTML, the presentation markup would have to be changed in every instance on every Web page.
  ([WCAG 2.0 Success Criteria 1.3.1, 1.4.5, 1.4.9, 2.4.10; WCAG 1.0 Checkpoint 3.1, 3.3, 3.5, 3.6, 3.7, 5.4)]
• Facilitate efficient debugging with automated validation tools by conforming to standards and identifying a DOCTYPE. Facilitate efficient human debugging by simplifying markup and using style sheets to define presentation.
  ([WCAG 2.0 Success Criteria 1.3.1, 4.1.1, 4.1.2;] WCAG 1.0 Checkpoint 3.2, 3.3, 11.1, 11.2)
• Reduce redesign and translation time and skills needed by using standard markup and style sheets to style and format text, instead of using bitmap images of text or math.
  {(WCAG 1.0 Checkpoint 3.1)}
  Site designers often use bitmap images for stylized text. In such cases, to change or translate text content or style, each image has to be manipulated. If instead the text was not in an image and the style was provided in a style sheet, then the text can be [easily] changed or translated[. To change the design is a simple style sheet change instead of restyling images of text.] {without touching the image, and likewise the style can be changed in the style sheet.}
  [(WCAG 2.0 Success Criteria 1.4.5, 1.4.9; WCAG 1.0 Checkpoint 3.1)]
• Reduce development and maintenance by having one accessible version of a site, rather than multiple versions, as described in "Enable Content on Different Configurations" section below.

Reduce Bandwidth Use and Server Load

Web accessibility techniques can reduce the server load, [which increases the download speed and can reduce the need for additional bandwidth or servers,] {thus reducing the need for additional servers and increasing the download speed,} as follows:

• Reduce the size of each page served by defining presentation in style sheets (which are only requested once per session) rather than the markup of each page, and by using text rather than bitmap images of text.
  ([WCAG 2.0 Success Criteria 1.3.1, 1.4.5, 1.4.9;] WCAG 1.0 Checkpoint 3.3, 3.1)
• Reduce downloading of large image and multimedia files by including alternative text for images and transcripts for multimedia files. {, which, for} [For] example, [this] lets users with low bandwidth connections browse with images off[, and lets users preview the information and decide whether or not to download it.].
  ([WCAG 2.0 Success Criteria 1.1.1, 1.2.8;] WCAG 1.0 Checkpoint 1.1)
• Reduce unwanted page downloading, and thus server requests, by providing clear and consistent design, navigation, and links
  ([WCAG 2.0 Success Criteria 2.4.4, 2.4.9, 2.4.5, 3.2.3, 3.2.4, 2.4.1, 2.4.6, 3.2.3, 3.2.4;] WCAG 1.0 Checkpoint 13.1, 13.3, 13.4, 13.5, 13.6, 13.7, 13.8, 14.3)

Enable Content on Different Configurations

Many organizations are increasingly interested in Web interoperability and {device-independence} [device-independence, such as making their websites work well on mobile phones]. Web accessibility can enable Web content to be rendered and interacted with on different configurations[,] {--} including different devices, operating systems, and {user agents (such as} Web browsers{) --}[,] as follows:

• Allow users and user agents to access content for different configurations, and servers to provide content for different configurations by using current versions of {W3C} technologies [with built-in accessibility support]{. Technologies} such as XHTML, XML, RDF, SMIL, CSS, XSL, XSLT, and PNG{ have accessibility support built-in}.
  ([WCAG 2.0 Success Criteria 4.1.1, 4.1.2 and Conformance Requirements 1, 4;] WCAG 1.0 Checkpoint 11.1, 3.2)
• Render {stylized information} [styled text] across a wide range of configurations by providing information as text and using style sheets to define presentation, rather than using bitmap images of text.
  ([WCAG 2.0 Success Criteria 1.3.1, 1.4.1, 1.4.3, 1.4.4, 1.4.5, 1.4.6;] WCAG 1.0 Checkpoint 3.1, 3.3)
• Facilitate interaction with different input devices by designing for device independence[.]
  ([WCAG 2.0 Success Criteria 2.1.1, 2.1.2, 2.1.3, 2.4.3, 2.4.7;] WCAG 1.0 Checkpoint 6.4, 9.1, 9.2, 9.3, 9.4, 9.5)
• Allow users and user agents to request content in a way that suits their capabilities by using markup for structure and style sheets for presentation.
  ([WCAG 2.0 Success Criteria 1.3.1, 2.4.10;] WCAG 1.0 Checkpoint 3.3)

Be Prepared for Advanced Web Technologies

Web accessibility can help organizations take advantage of advanced Web technologies and be prepared for future Web technologies, for example:

• {Allow content re-use by using metadata and representing it using resource description framework (RDF), such as is described in "What is RDF?".
  (WCAG 1.0 Checkpoint 13.2)}
• [Allow content re-use by enabling tools to extract and present information to users in different modalities.
  (WCAG 2.0 Success Criteria 1.3.1, 1.4.3, 1.4.4, 1.4.6, 4.1.2)]
• Simplify forward migration and backwards-compatibility by defining presentation in a style sheet, using proper markup structure, and using the latest standards.
  ([WCAG 2.0 Success Criteria 4.1.1, 1.3.1, 1.4.8, 1.4.4, 1.3.1, 2.4.10;] WCAG 1.0 Checkpoint 11.1, 3.2, 3.3, 3.5, 3.6, 3.7, 5.4)

Have High Quality Websites

Some developers and organizations pride themselves on producing high quality websites that meet technical standards. {Web accessibility guidelines such as the Web Content Accessibility Guidelines (WCAG) 1.0 The} [Web Content Accessibility Guidelines (WCAG) and other accessibility specifications ] from the World Wide Web Consortium (W3C) Web Accessibility Initiative (WAI) are widely-recognized international standards. {Several} [Additional] resources addressing the business case for Web standards in general are available on the Web {and in print}.

[ Previous Page - Social Factors | Top of Page | Next Page - Financial Factors- ]

Document Information

This is an old draft. The published version of this document is at www.w3.org/WAI/bcase/.

Version: {1.0 Up-to-date as of August 2005} [Version 2.0 - June 2009]
Editor: Shawn Lawton Henry [and Andrew Arch. Previous editor: Judy Brewer (until 2003)]. Acknowledgements lists additional contributors. [Updated as part of WAI-AGE, a project of the European Commission FP6 IST Programme.]

[Contacting WAI] Feedback welcome to wai-eo-editors@w3.org (a publicly archived list).

{File (not content) last updated on $Date: Tuesday 31 January 2006 - 11:15:01$ by $Author: shawn $}