���app

The ���app has adopted the����version 2.0, Level AA Conformance (WCAG 2.0 Level AA) and��technical specifications as its goal for accessible University Websites.

On January 18, 2017, the U.S. Access Board issued an����guidelines to standardize the application of WCAG 2.0 to all electronic information and communication content. In addition to web pages, Section 508 guidelines apply to any and all electronic documents that will be posted online or distributed via e-mail, whether it’s an internal or an external document. Of special interest to web content editors and developers are the guidelines for PDF, Word, Excel, PowerPoint, and other multimedia files.

To help ensure compliance with Section 508 guidelines, the U.S. Access Board has provided guidelines checklists for the following media types:

Understanding Degree Of Accordance: WCAG

There are three levels of conformance: Level A, Level AA, and Level AAA

• Level A:��For Level A conformance, the������all the Level A Success Criteria, or a����is provided. All University website pages must satisfy a Level A conformance.
• Level AA:��For Level AA conformance, the Web page satisfies all the Level A and Level AA Success Criteria, or a Level AA conforming alternate version is provided. All University website pages must satisfy Level AA conformance.
• Level AAA:��For Level AAA conformance, the Web page satisfies all the Level A, Level AA and Level AAA Success Criteria, or a Level AAA conforming alternate version is provided. When possible the University looks to fulfill Level AAA compliance, however, this is not possible as a general policy as it is impossible for entire sites to achieve Level AAA as not all content is capable of satisfying this level of compliance.

Note 1: Although conformance can only be achieved at the stated levels, authors are encouraged to report (in their claim) any progress toward meeting success criteria from all levels beyond the achieved level of conformance.

Note 2: It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA Success Criteria for some content.

Achieving conformance to “Level AA” standards relies on four principles which perpetuate and facilitate access and use of web content by users with disabilities. Adherence to these principles entails developing and updating website content that is:

1. Perceivable -��Information and user interface components must be presentable to users in ways they can perceive.
2. Operable -��User interface components and navigation must be operable.
3. Understandable -��Information and the operation of user interface must be understandable.
4. Robust -��Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

Implementation Guidelines

The ���app utilizes a “self-serve” process of managing website content. Reality dictates that conformance to WCAG 2.0 Level AA guidelines may be an undue burden due to the nature of the content, the purpose of the resource, the lack of accessible solutions, or an unreasonably high administrative or financial cost necessary to make the resource meet that goal. However, these difficulties do not relieve University programs or activities from meeting applicable legal obligations to provide reasonable accommodations to Users in regard to access to the content and services provided on ���app Websites.�� Managers of University programs and activities must be prepared to provide content and/or services in a suitable alternative format (e.g., electronic text file or audio description) or manner upon request
Some considerations of implementation include, but are not exclusive to:

1. New Development:��New ���app Website development, including development for major revisions and updates of existing University Websites, should conform to WCAG 2.0 Level AA.��
2. Accessibility Monitoring: While the it is expected that programs and activities created and disseminate content that conforms to WCAG 2.0 Level AA standards, IT will continue to test ���app websites for accessibility and report accessibility issues to the content managers for that website.
3. Images and Animation:��Use the alt=“text” and title=“text” attributes to provide text equivalents for images. Use alt=“” for images that do not convey important information or convey redundant information.
4. Image Maps:��Use client-side image maps and alternative text for image map hot spots. If a server-side map is needed, provide equivalent text links.
5. Graphs and Charts:��Summarize the content of each graph and chart, or use longdesc attribute to link to the description or data.
6. Audio/Video:��Provide captions or transcripts of important audio content. Provide transcripts, captions or audio descriptions of important video content.
7. Scripts:��Ensure the functionality of scripts is keyboard accessible. If the content affected is not accessible, provide an alternative.
8. Applets, Plugins and Non-HTML Content:��When an applet, plug-in or other application is required to be present, provide a link to one that is directly accessible, or provide alternate content for those which are not directly accessible.
9. Forms:��Make forms accessible to assistive technology.
10. Skip to Main Content:��Provide methods for slipping over navigation links to get to main content of a page.
11. Frames:��Provide a title for each FRAME element and frame page. Provide an accessible source for each frame.
12. Table Headers:��Use the TH element to mark up table heading cells. Use the headers attribute on cells of complex data tables.
13. Cascading Style Sheets:��Web pages should be readable without requiring style sheets.
14. Color & Content:��Ensure that all information conveyed with color is also conveyed in the absence of color.
15. Blinking, Moving or Flickering Content: Avoid causing content blink, flicker or move.
16. Time Responses:��When a timed response is required, alert the user, and give sufficient time to indicate more time is required.
17. Text-only page:��If accessibility cannot be accomplished in any other way, provide a text-only page with equivalent information or functionality. Update the content of the text-only page whenever the primary content page changes.
18. Verify accessibility:��Test the accessibility using available tools.

WAI-ARIA Compliance Objective For ���app Web Applications

Accessible Rich Internet Applications (ARIA) defines ways to make Web content and Web applications (especially those developed with Ajax and JavaScript) more accessible to people with disabilities. For example, ARIA enables accessible navigation landmarks, JavaScript widgets, form hints and error messages, live content updates, and more.

ARIA is a set of special accessibility attributes which can be added to any markup, but is especially suited to HTML. The role attribute defines what the general type of object is (such as an article, alert, or slider). Additional ARIA attributes provide other useful properties, such as a description for a form or the current value of a progressbar. [ARIA. (n.d.). Retrieved July 12, 2016, from����]

The ���app has adopted WAI-ARIA compliancy as its goal for accessible University Websites. The ���app provides reasonable accommodations to Users in regard to access to the content and services provided on ���app Websites. Steps towards WAI-ARIA conformance involve the following employment efforts.

• Add WAI-ARIA properties to rich internet widgets to communicate name, role and value information to assistive technologies.
• Implement WAI-ARIA arrow key navigation code to mimic desktop widget navigation. Example of this include but are not exclusive to:
  • Set tabindex="0" to the current active descendant in the widget while setting tabindex="-1" on all the other child elements of the widget
  • As the user navigates (e.g. arrows) away from an item, the old item gets a tabindex="-1" and the new item gets tabindex="0".
  • Use the javascript method to set focus, using its JavaScript focus() method, on the item whose tabindex="-1"
• Use appropriate WAI-ARIA landmarks, in conjunction with HTML5 elements, to enable easier page navigation:

*Widget = A small element on a Web page or in a Web-based application, such as a text box, button, slider control, or other item that can be changed by the user.

Accessibility Resources: Page Validation And Disability Access Checkers

��- WebAIM offers complete web accessibility services including the��

��checks the markup validity of Web documents in HTML, XHTML, SMIL, MathML, etc. If you wish to validate specific content such as RSS/Atom feeds or CSS stylesheets, MobileOK content, or to find broken links, there are other validators and tools available.

-- installing this software will allow you to explore how your pages sound to someone without sight (a very valuable education)

��for evaluating and testing accessibility

��shows you what your page looks like to the colorblind.