Accessibility

Accessibility is the extent to which an information resource is retrievable and understandable by all users, especially those with special needs and disabilities. Accessibility to users with disabilities is one of our key goals for the website and is part of ALA Policy 54.3.2, which calls for Level 2 Success Criteria as defined by the Web Accessibility Initiative (WAI).

User groups with special needs and disabilities include blind users who use screen reader software, low vision and/or colorblind users, users with low technology access or skill levels, and low-mobility users who use only keyboard controls.

W3C WAI Objectives

The Web Accessibility Initiative, in producing the Web Content Accessibility Guidelines (WCAG), has as its overall goal “to create Web content that is perceivable, operable and understandable by the broadest possible range of users and compatible with their wide range of assistive technologies, now and in the future.” ([1])

The WAI guidelines state that Level 2 Success Criteria have three main attributes:

  • Possibility of requiring content to be presented in particular ways;
  • Reasonable applicability to all websites; and
  • Machine testability in some cases.

Conformance to the guidelines includes, but is not limited to, the following:

  • Providing textual content that, when presented to the user, conveys essentially the same function or purpose as auditory or visual content;
  • Ensuring that text and graphics are understandable when viewed without color;
  • Preparing HTML documents with the proper structural elements; controlling presentation with style sheets rather than with presentation elements and attributes;
  • Using markup that facilitates pronunciation or interpretation of abbreviated or foreign text;
  • Ensuring that tables have necessary markup to be transformed by accessible browsers and other user agents;
  • Ensuring that pages are accessible even when newer technologies are not supported or are turned off;
  • Ensuring that moving, blinking, scrolling, or auto-updating objects or pages may be paused or stopped;
  • Ensuring that the user interface follows principles of accessible design: device-independent access to functionality, keyboard operability, self-voicing, etc.;
  • Using features that enable activation of page elements through a variety of input devices;
  • Using interim accessibility solutions so that assistive technologies and older browsers will operate correctly;
  • Using W3C technologies (according to specification) and following accessibility guidelines. Where it is not possible to use a W3C technology, or doing so results in material that does not transform gracefully, provide an alternative version of the content that is accessible;
  • Providing context and orientation information to help users understand complex pages or elements; and
  • Providing clear and consistent navigation mechanisms — orientation information, navigation bars, a site map, etc. — to increase the likelihood that people will find what they are looking for on the site.

The WC3 offers a Markup Validation Service ([2]) to help verify that code complies with its recommendations and other standards. Test pages using the validator to check for compliance and to pinpoint problems.

ALA Accessibility Standards

ALA requires all content on www.ala.org to meet level 2 accessibility guidelines as specified by the W3C. The following are particularly important:

  • Web content *must* conform to the Level 2 Success Criteria for coding presented in the World Wide Web Consortium (W3C) Web Accessibility Initiative’s (WAI’s) Web Content Accessibility Guidelines, version 2.0 ([3]).
  • The use of JavaScript *must* be restricted to enhancing the user experience, and *must not* be used as the only way of providing information or interaction. For example, JavaScript *may* be used to perform client-side validation of a form to be submitted, *only if* server-side validation is also performed. This is in case the user’s browser does not support JavaScript and therefore does not allow client-side validation.
  • Each link *must* clearly indicate its target, either in the link text or in a title attribute attached to the link. For example, “Click here” is inappropriate when used by itself.
  • A text equivalent *must* be provided for every non-text element such as a script, image, or audiovisual content.
  • All text equivalents *must* be kept up to date with their non-text correlates.

A number of the WAI guidelines are reflected in this style guide, for ease of reference by content providers. Consult the W3C website (above) for the complete list of specific information on preparing accessible web content.