Web Accessibility

http://office.microsoft.com/en-us/access-help/about-accessibility-for-people-with-disabilities-HP005270024.aspx

Microsoft article on the accessibility of MS Access. The UC is considering the use of  “Point-and-Click” software for it’s system wide database. Will need to do some further investigation to validate it’s accessibility to all disabilities.

Content Editor’s Guide – http://www.oit.uci.edu/computing/wcg/cmsCE/index.html

Cascade Developer’s Guide – http://www.oit.uci.edu/computing/wcg/cmsdev/index.html

It includes information and resources like:

• WCG supported services

• Sites@UCI

• Faculty Websites

• iTunes U

• CMS Resources

• Cascade Server

• WordPress

• Drupal

• Writing for the Web

• Code Snippets

• Accessibility

• User Interface/User Experience Help
It is available on our OIT website at: http://www.oit.uci.edu/computing/wcg/index.html

University of Texas Beginning Tutorial of CSS – http://www.utexas.edu/learn/css/

Article verifying the inaccessibility of Google Apps:

http://jebswebs.net/blog/2011/03/nfb-questions-google-apps-accessibility/

Still no improvement to date.

Shawn Foster’s Blog on Google Apps

Visit Just Creative Design’s Site at http://justcreativedesign.com/2008/07/18/how-to-make-your-website-more-accessible/.

EXERPT:

One of the biggest mistakes I see from web designers is making accessibility more complicated than it actually is. Most designers think of creating accessible content as something that will take weeks of exaggerated tagging, designing tab-browsing and hot keys for every minute function of a site, and writing over-descriptive metadata, so most people just give up and don’t even bother. However, by using some simple techniques and following some basic guidelines, you can make your website accessible to a wide audience of users without spending too much time and energy.

I define web accessibility as:

Making web content available to a wide audience regardless of physical abilities, web clients, and personal preferences.

To simplify our tasks as accessible web designers, there a few specific categories that can be helpful as we evaluate some of the different types of users:

• Visually Impaired: Those with low or no vision. These users may use screenreading software or may use the browser’s functionality to increase text size and contrast.
• Hearing Impaired: Those with low or no hearing. These users will need to be able to see a textual representation of any audio that is part of the site.
• Physically Impaired: Those who lack the physical dexterity to use a mouse or a traditional keyboard. These users may use a variety of interface devices, many of which parallel the functionality of the traditional [TAB] key.
• Alternative Web Client Users: Those who may be using a mobile device, tablet PC, specialty browser (such as a retail point-of-sale device), or gaming console. The dimensions and orientation of the browsing window on these devices may be unconventional
• Technologically Limited: Those who may have low bandwidth or low network reliability, such as users in remote locations or in developing countries. These users may turn off the presentation layer to have better access to content.

To design an accessible site, one of the most important things you can do is to separate content from presentation. Remember, people are visiting your site for the content. By separating the presentation from the content, you are giving your users the ability to use whatever client is appropriate to access your content, whether it is a screenreader, mobile device, or tablet PC.

University of California
Policy on Accessibility in the Electronic Environment
June 14, 2007

BACKGROUND

The University of California is committed to facilitating an electronic environment that is accessible to all, including individuals with disabilities. In his August 10, 2001, letter to Chancellors, President Richard Atkinson established as principle the University’s commitment that administrative applications and instructional technologies should be in compliance with the current standards for accessibility.

This Policy formally acknowledges the University’s commitment to acc3essibility in the electronic environment and sets forth guidelines that provide appropriate information on tools and accessibility standards consistent with developments in federal and state laws and regulations. This Policy recognizes the dynamic nature of technology; therefore its supporting Guidelines will be updated as University information technology planning and architecture strategies evolve.

POLICY ON ACCESSIBILITY IN THE ELECTRONIC ENVIRONMENT

The University is committed to providing equal access to information provided by means of information technologies to all members of the University community and to members of the public seeking information about University programs and services. Providers of University programs and services should follow the supporting Guidelines for Accessibility in the Electronic Environment to ensure that their information technology resources meet University standards for accessibility. The Guidelines are based on current industry standards and applicable federal and state laws.

AUTHORITY AND RESPONSIBILITY

This Policy is issued by the President of the University of California.

The Executive Vice President for Business Operations, Chancellors, Medical Center Directors, and uC Managed Laboratory Directors, are responsible for designating a coordinator to administer and implement this Policy. The coordinator shall ensure that a campus (1) oversight committee is established for evaluating compliance with this Policy in accordance with the supporting Guidelines.

The Associate Vice President-Information Resources and Communications at the Office of the President is responsible for issuing and updating the Guidelines that support this Policy. Information Resources and Communications shall facilitate regular communications among campus oversight committees to address consistent implementation of this Policy through the University system.

(1) The term “Campus” is used in this Policy to refer to all University locations.

ESSENTIAL COMPONENTS OF WEB ACCESSIBILITY

• http://www.w3.org/WAI/intro/components.php

UCOP

• Resources for Designing Accessible Web Sites – http://www.ucop.edu/irc/itaccessibility/resources/
• UCOP Recommendations – http://www.ucop.edu/irc/itaccessibility/resources/standards.html

DISABILITY SERVICES CENTER

• Web Accessibility Resource Page – http://www.dsc.uci.edu/other_links/web_accessibility.html

UC IRVINE ADMINISTRATIVE POLICIES & PROCEDURES

• UC IRVINE ELECTRONIC COMMUNICATIONS – Section 800-16: World Wide Web Policy – http://www.policies.uci.edu/adm/pols/800-16.html

WEB CONTENT ACCESSIBILITY GUIDELINES (WCAG)

• WCAG 2.0 (Current) Quick Reference Techniques – http://www.w3.org/WAI/WCAG20/quickref/ (WCAG 2.0 Succeeds WCAG 1.0)

12 Guidelines into 4 Principles – http://www.w3.org/TR/2008/REC-WCAG20-20081211/#contents

§  Perceivable

• 1.1 – Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.
• 1.2 – Provide alternatives for time-based media.
• 1.3 – Create content that can be presented in different ways (for example simpler layout) without losing information or structure.
• 1.4 – Make it easier

§  Operable

• 2.1 – Make all functionality available from a keyboard.
• 2.2 – Provide users enough time to read and use content.
• 2.3 – Do not design content in a way that is known to cause seizures.
• 2.4 - Provide ways to help users navigate, find content, and determine where they are.

§  Understandable

• 3.1 – Make text content readable and understandable.
• 3.2 – Make Web pages appear and operate in predictable ways.
• 3.3 – Help users avoid and correct mistakes.

§  Robust

• 4.1 – Maximize compatibility with current and future user agents, including assistive technologies.

3 Levels of Testable Success Criteria

§  A

§  AA

§  AAA

• WCAG 1.0 – http://www.w3.org/TR/WCAG10-TECHS/

o   Priority 1 – 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 to be able to use Web documents.

o   Priority 2 – A Web content developer SHOULD satisfy this checkpoint. Otherwise, one or more groups will find it somewhat difficult to access information in this document. Satisfying this checkpoint will remove significant barriers to Web documents.

o   Priority 3 – 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.

o   Techniques located at: http://www.w3.org/TR/WCAG10-TECHS/#Techniques

SECTION 508 STANDARDS CHECKLIST – http://webaim.org/standards/508/checklist

LIST OF WEB ACCESSIBILITY EVALUATION TOOLS – http://www.w3.org/WAI/ER/tools/complete.html

• Recommendations

o   A-Checker

o   A-Prompt

o   WAVE (http://wave.webaim.org)

• ***High Tech Center Training Unit Distance Education Guidelines (California Community Colleges)
• First Steps: Accessible e-Learning
• CATEA Grade A+ Project – Georgia Tech Univ.
• Stanford Online Accessibility Program
• CSU Professional Development for Accessible Technology
• University of Central Florida
• Johnson County Community College
• Adobe
• EASI Online Course Book Overview (Video) – Book: _Making Online Teaching Accessible_ by Norman Coombs
• Moodle – Using Open Source – Software to Deliver Accessible Online Courses – Presentation from CSUN AT Conference March 2011 (Carroll Tech Homepage)

Other Resources to Consider:

• A is for Access… Blog with blind user experience

http://www.w3.org/WAI/WCAG20/quickref/

This document lists all of the requirements (called “success criteria”) from Web Content Accessibility Guidelines (WCAG) 2.0. It also lists techniques to meet the requirements, which link to more details. The “Understanding” links go to descriptions, examples, and resources.

AChecker 1.1 has been released. AChecker is a free open source Web content accessibility evaluator used to assess Web pages for conformance with international accessibility standards. This release adds a number of significant new features. Thanks to the Department of Computer Science at the University of Bologna, Italy, for their contributions to this release.

*Use the Public AChecker to evaluate your Web site*:

http://www.achecker.ca

*Download AChecker to install a copy of your own*:

http://www.atutor.ca/achecker/download.php

*AChecker Details*

http://atutor.ca/achecker/

New in this release:

• CSS Validator*: Access the validity of external stylesheets, embedded stylesheets, and inline styles while evaluating the accessibility of a Web page.
• Colour Contrast Evaluation*: Ten new accessibility checks have been added to evaluate foreground and background colour contrast to ensure text is readable by everyone.
• Paste HTML from Clipboard*: Evaluators can now paste the source HTML of a Web page into AChecker to have it evaluated. This makes it possible to assess pages that are not accessible from the Web, such as those on an Intranet, or on a local personal computer.
• Updater*:  Administrators can now keep their AChecker installation up to date in between releases with the AChecker Updater. The Updater lets them apply patches to fix bugs, to add new features as they become available, and to add new accessibility checks as they are created.
• AChecker Translator Site*: There are currently English and Italian translations of AChecker.  Sign-up for a translator account on atutor.ca, if you do not already have one, and help translate AChecker into your language.

AChecker Translation

http://atutor.ca/my/translate_acheck.php