“Thanks for the great training! I learned quite a bit and I am sure that our developers gained a better knowledge of the 508 standards.”
When discussing Section 508, eventually the discussion will turned to the "W3C". This acronym is a quick way to say "The World Wide Web Consortium". This consortium was created in October 1994 to lead the World Wide Web to its full potential by developing common protocols that promote its evolution and ensure its interoperability. W3C has approximately 450 member organizations around the world and has earned international recognition for its contributions to the growth of the Web.W3C's Web Accessibility Initiative (WAI) in coordination with accessibility experts and organizations around the world, advance accessibility of the Web through five primary areas of work: technology, guidelines, tools, education & outreach and research & development.
More information: http://www.w3.org/WAI/ WAI is supported in part by: the U.S. Department of Education's National Institute on Disability and Rehabilitation Research; European Commission's Information Society Technologies Programme; Canada's Assistive Devices Industry Office and a number of technology and telecommunications companies.
The WAI office is responsible for the World Wide Web Consortium's commitment to Web accessibility for all people. WAI is involved with the creation of international guidelines for content design publishing tools and other user agents like web browsers. It is these guidelines that form the basis for most mandated IT accessibility laws throughout the world.
The W3C Web Content Accessibility Guidelines are the backbone of most international Web page and/or software accessibility legislative mandates. There are fourteen guidelines that are considered general principles of accessible design. These guidelines not only make pages more accessible to people with disabilities, but also have the additional benefit of making Web pages more accessible to all users, including users using different browser and users of emerging handheld or voice-based computers.
More information: http://www.w3.org/TR/WAI-WEBCONTENT/ Each guideline is associated with one or more checkpoints describing how to apply that guideline to particular features of the Web page. The checkpoint definitions in each guideline explain how the guideline applies in typical content development scenarios. Checkpoints are quite literally a checklist of criteria to check Web pages against in order to determine the level of accessibility for each page. For example: Checkpoint 2: Ensure that all information conveyed with color is also available without color, for example from context or markup. [Priority 1] Each checkpoint has a Priority Level assigned by the WAI Working Group based on the checkpoint's impact on accessibility.
A Web content developer must satisfy this checkpoint. Otherwise, one or more groups will find it impossible to access information in the document. Satisfying this checkpoint is a basic requirement for some groups to be able to use Web documents. In the example above, content using color must be available without color. As a Priority 1 Guideline this would be a requirement for Conformance Level A through AAA certification. (See Conformance Levels below)
A Web content developer should satisfy this checkpoint. Otherwise, one or more groups will find it difficult to access information in the document. Satisfying this checkpoint will remove significant barriers to accessing Web documents.
A Web content developer may address this checkpoint. Otherwise, one or more groups will find it somewhat difficult to access information in the document. Satisfying this checkpoint will improve access to Web documents
A Web page's "Conformance" level is generally displayed as an "A", "AA" or "AAA" rating. The levels of conformance are defined as follows:
Conformance Level "A": All Priority 1 checkpoints are satisfied;As with so many other things in life that are rated, the more A's the better!
NOTE: Although the WAI guidelines were created within the context of creating "Web" accessibility, it is these same guidelines that are applied when analyzing the accessibility compliance of software applications that are not Web-based.
The guidelines are written for a variety of audiences, including people who are designing Web sites; people who are checking existing Web sites for accessibility; organizations that wish to require a given level of accessibility for their Web sites; and others who are interested in ensuring that people with disabilities can access information on the Web. The real "art" in creating accessible Websites or software is in "how" these guidelines are implemented. Some of the guidelines are as straight forward as adding and alt_tag for each image on a Web page. But what about designing the page so that someone who uses a screen reader doesn't need to sit through 39 renditions of your navigation links by the time they finish viewing your entire Website?Before identifying the solutions to this problem, (Hint: skip_nav) the realization that this is even an issue must be realized. Utilizing these guidelines without understanding accessible software and hardware technology, or the way people with disabilities utilize them, will ultimately lead to technically accessible, but very unusable, Web pages.
People with different kinds of disabilities can experience difficulty using the Web due to a combination of barriers presented by the information on Web pages, and barriers in the "user agents" (browsers, multimedia players, or assistive technologies such as screen readers or voice recognition). The WAI Web Content Accessibility Guidelines deal specifically with the reduction of barriers on Web pages. For some people with disabilities, barriers can mean lack of access to information needed for educational programs; lack of access to employment-related information or workplace Intranets; lack of access to information on civic activities or programs; inability to participate in eCommerce; or lack of access to information on the Web in general.