| 
View
 

Assistive Technology -- Making Web Pages Accessible Part 1

This version was saved 9 years, 11 months ago View current version     Page history
Saved by Ryan S. Overdorf
on January 3, 2015 at 10:29:20 am
 

Introduction to Web Accessibility 

 

Other "Making Web Pages Accessible" parts: Part 2, Part 3, Part 4.

 

Origin

 

Unlike other situations other CS-SIS members may commonly encounter, web accessibility awareness does not usually begin with a memo from a University Disability Resource Center.  The Justice Department will be issuing proposed regulations on web accessibility and state and local governments in the coming months.  It will issue proposed regulations on web accessibility for private institutions.  For more information about the law, refer to Assistive Technology -- Understanding the Law and the section on web accessibility.

 

Identifying the Right Standard

 

Most readers (to the extent that they have heard of web accessibility at all), have heard of the Section 508 standards.  The Section 508 standards with respect to web pages are essentially a checklist of eleven items meant to address common concerns at the time the regulation was drafted.  They were expressly based on the Web Content Accessibility Guidelines (WCAG)  1.0 developed by W3C.  Those standards are outdated.  While a web page that meets Section 508 standards would be more accessible  than one that does not, the gold standard for accessibility is WCAG 2.0.

 

Summarizing WCAG 2.0

 

WCAG 2.0 is organized by Principles, Guidelines, and Success Criteria.  The principles are general objectives and each of the four principles can be summarized in a single word: perceivable, operable, understandable, and robust.  Each of the 12 guidelines is a plain English one sentence statement of what needs to be achieved.  The 25 Success Criteria relevant to "A" level conformance and the 13 additional Success Criteria relevant to "AA" level conformance provide highly technical testable criteria by which to measure conformance.

 

Not all of the criteria are likely to apply to every page.  Some of the criteria can be conformed to without much conscious thought or effort because most webmasters/developers/content creators do certain things anyway.  Many can be conformed to with a relatively modest amount of effort.  A few require considerable time and effort.

 

The Structure of These Pages

 

 The Committee will not attempt a detailed explanation of how to conform to each of the 38 Success Criteria applicable to either "A" or "AA"level conformance.  Instead, the Committee will briefly summarize each criterion in non-technical language, rate the difficulty level of achieving conformance, assess the impact of non-conformance for that criterion, discuss how to validate for that criterion (including links to web-based validators, if applicable) and provide links to detailed third-party information regarding how to conform to the criterion.

 

Every criterion is potentially time consuming depending on the structure of the web page.  A "low" degree of difficulty means that conforming to the criterion requires a minimum amount of training and that the criterion can be validated with AChecker or another automatic tool.  A "medium" degree of difficulty means that conforming to the criterion requires significant training and manual review, but should be achievable without requiring  outsourcing to a third party.  A "high" degree of difficulty  means that conforming to the criterion requires extensive training, must be validated manually, and most institutions will outsource conformance to third parties. 

 

The Free AChecker Web Accessibility Tool

 

AChecker is a free web accessibility tool that can be used to check conformance to some but not all of the WCAG 2.0 Success Criteria.  It divides violations into three categories: known, likely, and potential problems.  In the Committee's experience, "known problems" are reliable indicators of problems, "potential problems" are less reliable indicators, and "potential problems" usually aren't.  In addition, potential problems are usually generated in numbers too high to check in any reasonable period of time.  

 

The primary limitation of AChecker is that it can check only one page at a time.  It works by checking for proper use of HTML and other markup language tags.  While one does not need to be an expert on HTML to use AChecker, understanding how HTML tags are structured is very useful in understanding AChecker's results.  Because it depends on markup language tags to find errors, it only detects errors created by improper use of those tags.  Many errors (e.g., lack of closed captions during live video) are not due to improper tag use and therefore go undetected by AChecker.

 

See the entire list of WCAG 2.0 Level AA non-conformance error conditions checked by AChecker. 

 

 

[end part 1]

 

Part 2, Part 3, Part 4

 

Load Sidebar links in this window

Comments (0)

You don't have permission to comment on this page.