Accessibility

Northern California Indian Development Council, Inc.
Web Accessibility Policy

(Revised 07/22/2011; Draft Date 08/01/2011)

Purpose:

NCIDC’s purpose in researching, developing, and administering social and economic development programs for Native American communities in California is increasingly reliant on the internet and World Wide Web. The information and programs found on our web site extend to all Native Americans, including those who have physical challenges that can create barriers to the internet. We are committed to ensuring equal access to information and programs for all our constituencies. This policy establishes minimum standards for the accessibility of web based information and services considered necessary to meet this goal and ensure compliance with applicable state and federal regulations.

Scope:

All official web pages and web-based services published by NCIDC, its departments and programs. Web sites, pages, or files created by other entities and hosted on other servers are encouraged to adopt accessibility standards, but fall outside the jurisdiction of this policy.

Policy:

All new and redesigned pages published by NCIDC, its departments and programs, published after August 1, 2011 must be in compliance NCIDC’s Minimum Web Accessibility Standards (MWAS). Web pages published prior to August 1, 2011 are considered Legacy Pages, and are exempt from the NCIDC MWAS.

Upon a specific request for access by an individual with a disability, legacy pages must be updated to be in compliance with NCIDC’s MWAS or the content must otherwise be made available to any individual requesting access in a timely manner. (Timeliness should be considered in the context of the type of information or service a page provides and generally considered to be within 10 business days.)

Priority must be given to creating accessible Web pages for core institutional information such program and contact information. Priority will also be given to pages based on time sensitivity of function and frequency of use.

Implementation Priorities:

  1. All new and redesigned Web pages published after August 1, 2011.
  2. Pages that individuals must access in a limited time frame in order to effectively participate in a program, to utilize a service or benefit from information offered by any department of NCIDC.
  3. Annually convert the top 10% percent of the pages (based on frequency of hits) to meet the current standards.
  4. Remaining Legacy Pages.

Exceptions:

  1. Web pages, including those in legacy or archive status, that are specifically requested to be made accessible as an accommodation for an individual with a disability shall be made accessible or an equally effective alternative shall be provided within 10 business days. For information based pages equally effective means that it communicates the same information with a comparable level of accuracy.  For interactive or service pages equally effective means that the end results (e.g. registration in a program) is accomplished in a comparable time and with comparable effort on the part of the requestor.
  2. Certain forms for Contractors and Suppliers must be in Microsoft Word or Excel formats when returned to NCIDC. Accessibility aids for these forms must be provided at the user’s end.
  3. Video files hosted on YouTube are student projects and will not be required to have captions or audio descriptions.
  4. Audio files hosted on NCIDC’s site are in Native languages that are spoken by only a handful of individuals. Screen readers will have a difficult time parsing the text. For these reasons, audio files hosted on NCIDC’s site will not be required to have transcripts.
  5. Where compliance is not technically possible or may require extraordinary measures due to the nature of the information and the intent of the web page, exceptions to this policy may be granted by the ADA Coordinator.  Request for such exceptions must be made in writing and must be based on issues other than cost alone.

Review:

NCIDC will initiate a review of this policy at least once every three years.

 

Minimum Web Accessibility Standards

(Revised 07/22/2011; Draft Date 08/01/2011)

The following NCIDC standards were developed using the U.S. Access Board’s Section 508 standards, supplemented by The Web Content Accessibility Guidelines developed by World Wide Web Consortium (W3C) as a benchmark for access to web based information and services.

Equivalent facilitation

Nothing in these standards are intended to prevent the use of designs or technologies as alternatives to those prescribed in these standards provided they result in substantially equivalent or greater access to and use of a web site for people with disabilities

1) A text equivalent for every non-text element shall be provided (e.g., via alt tags, "longdesc, or in element content).

Examples:

  • Non-text elements (images, java applets, flash files, video files, audio files, plug-ins, etc.) have alt tag descriptions that convey the purpose or intended meaning of the object (e.g. Alt Tags for images used as links describe the link destination).
  • Complex graphics that summarize information (graphs, charts, tables, etc.) are accompanied by text conveying the information providing a meaningful narrative of the information.
  • Decorative graphics with no other function have empty alt descriptions (alt= "") not missing alt descriptions.
  • When descriptions are lengthy or refer to other resources or sites, a longer description will be made available using a link or supported "longdesc".

2) Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation.

Examples:

  • Multimedia files on a department posted to a department page has synchronized captions.
  • A web page presents multimedia files and provides a separate statement about requesting captioning.

3) Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup

Example:

  • If color is used to convey information alternative indicators, such as an asterisk (*), are used in conjunction.

4) Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on black and white screen. 

Example:

  • Blue on Blue, using different saturations of the same color for background and foreground

5) Documents shall be organized so they are readable without requiring an associated style sheet.

Examples:

  • When a document is rendered without associated style sheet, it must still be possible to read the document. 
  • Provide a text equivalent for any important image or text generated by style sheets (e.g., via the 'background-image', 'list-style', or 'content' properties).

Note: WCAG 3.3 Recommends using style sheets to control layout and presentation.  This method is strongly preferred over the use of tables due to wider compatibility with end user devices

6) Client-side image maps shall be provided instead of server-side image maps except where the regions cannot be defined with an available geometric shape.

Example:

  • Use standard HTML client-side image maps with appropriate alt tags for the image and hot spots.

7) Redundant text links shall be provided for each active region of a server-side image map.

Example:

  • Separate text links are provided outside of the server-side image map that provide the same to the content that image map hot spots access.

8) Row and column headers shall be identified for data tables.

Examples:

  • Tables used only for layout do not have header rows or columns.
  • In data tables, column and row headers are identified using the tag.

9) Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers.

Example:

  • Table cells are associated with the appropriate headers (e.g. id, headers, scope and/or axis HTML attributes).

10) Frames shall be titled with text that facilitates frame identification and navigation.

Example:

  • Each frame has a title that describes its purpose or the type of information contained within the frame.

11) Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz.

12) When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.

Examples:

  • Within scripts information is text-based or a text alternative is provided.
  • All scripts (Javascript, pop-up menus, etc.) work with keyboard-accessible alternatives (either within or outside of the script) that provide equivalent functionality.

13) When a web page requires that an applet, plug-in or other application be present on the client system to interpret page content, the page must provide a link to a plug-in or applet that complies with standards 1-9 of this document.

Examples:

  • When applets, plug-ins or applications (Java applets, Java scripts, Acrobat PDF files or PowerPoint files) are not accessible to assistive technologies you must provide an alternative means of accessing the content within the applications (e.g., a mirror HTML file for a PDF file).
  • When an applet, plug-in or application is utilized you must provide a link to a an accessible page where the plug-in can be downloaded

14) When electronic forms are designed to be completed on-line, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.

Examples:

  • Form controls have text labels adjacent to them and keyboard access to control functionality.
  • Form elements have explicitly associated labels in the markup (i.e. the id and for, HTML elements).
  • Dynamic HTML scripting of the form does not interfere with assistive technologies.

15) A method shall be provided that permits users to skip repetitive navigation links.

Example:

  • A link is provided to skip over lengthy lists of links (e.g. navigational menus).

16) When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.

Example:

  • Do not automatically forward, refresh, or otherwise alter pages, unless you provide the user with a method to adjust the timing of these content changes.

17) Do not change the current window without informing the user. 

Example:

  • Do not cause pop-ups or other windows to appear (until typical user agents allow users to turn off spawned windows)

18) Clearly identify the target of each link. 

Example:

  • Multiple links called the same thing (e.g., "more info . . . ", "results", or "click here") are problematic.

19) An accessible mirror page (e.g. text-only or non-flash) with equivalent information or functionality, can be provided to make a web site comply with this policy, when compliance cannot be accomplished in any other way. The content of mirror pages must be updated whenever the primary page changes.

Examples:

  • A mirror page is acceptable when there is no other way to make the content accessible, or when it offers significant advantages for ease of navigation.
  • The content for primary and mirror pages should be updated simultaneously.  For example, using a common database to generate content for multiple versions of the site.
  • Instead of static alternative pages, set up server-side scripts that generate accessible versions of a page on demand.
  • Mirror pages must be the functionality equivalent to primary pages (e.g. provides alternatives for applets, scripts, plug-ns and similar applications that are not directly accessible).
  • "Text-only" and "accessible" are not synonymous; designers must incorporate all of the above standards when designing mirror pages.

 

Software Applications and Operating Systems

Web based systems do not exist in a vacuum. When licensing or purchasing operating systems and software consider their impact your choices will have on the resources and effort necessary to provide accessible web based services and information in accordance with NCIDC policy and applicable state and federal regulations. The following standards from Section 508 provide guidance in considering these purchases. Software applications and operating systems that meet or exceed these standards provide the most efficient platforms for implementing and designing accessible web based services and applications.

  1. When software is designed to run on a system that has a keyboard, product functions shall be executable from a keyboard where the function itself or the result of performing a function can be discerned textually.
  2. Applications shall not disrupt or disable activated features of other products that are identified as accessibility features, where those features are developed and documented according to industry standards. Applications also shall not disrupt or disable activated features of any operating system that are identified as accessibility features where the application programming interface for those accessibility features has been documented by the manufacturer of the operating system and is available to the product developer.
  3. A well-defined on-screen indication of the current focus shall be provided that moves among interactive interface elements as the input focus changes. The focus shall be programmatically exposed so that assistive technology can track focus and focus changes.
  4. Sufficient information about a user interface element including the identity, operation and state of the element shall be available to assistive technology. When an image represents a program element, the information conveyed by the image must also be available in text.
  5. When bitmap images are used to identify controls, status indicators, or other programmatic elements, the meaning assigned to those images shall be consistent throughout an application's performance.
  6. Textual information shall be provided through operating system functions for displaying text. The minimum information that shall be made available is text content, text input caret location, and text attributes.
  7. Applications shall not override user selected contrast and color selections and other individual display attributes.
  8. When animation is displayed, the information shall be displayable in at least one non-animated presentation mode at the option of the user.
  9. Color coding shall not be used as the only means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.
  10.  When a product permits a user to adjust color and contrast settings, a variety of color selections capable of producing a range of contrast levels shall be provided.
  11. Software shall not use flashing or blinking text, objects, or other elements having a flash or blink frequency greater than 2 Hz and lower than 55 Hz.
  12. When electronic forms are used, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.