Technical Assistance Document for Oklahoma’s Web-based Intranet and Internet Information and Applications
Draft – May 27, 2005
Overview - Oklahoma is one of many states that acknowledges the federal accessibility standards outlined in Section 508 of the Rehabilitation Act, as amended by the Workforce Investment Act of 1998.
In keeping with the spirit of that law, the Oklahoma legislature passed HB 2197 in April 2004, which requires state agencies to make electronic information technology accessible. In coordination of Section 2 of HB 2197, Oklahoma has developed state standards on accessibility for information technology, based on existing Section 508 standards, for the following areas: 1) Software Applications and Operating Systems, 2) Web-based Intranet and Internet Information and Applications, 3) Telecommunications Products, 4) Video and Multimedia Products, and 5) Desktop and Portable Computers.
Oklahoma's Technical Assistance Document (TAD) for Web-based Intranet and Internet Information and Applications offers additional assistance to those who need more detailed directions or advice for making their electronic and information technology compliant according to Oklahoma’s standards. It also offers a compliance checklist, examples, and instructions on how to achieve compliance with each standard. Supplemental sections provide resources and testing as well as a listing of organizations and additional information sources.
Oklahoma’s standards for Web-based Intranet and Internet Information and Applications closely mirror Section 508 standards. The standards use slightly modified language in six standards (a, c, j, k, l, and m) and add three additional standards (q, r, and s) to the Section 508 standards. These modifications, based largely on World Wide Web Consortium (W3C) accessibility standards, improve the clarity of some standards and add additional important guidelines for improved accessibility.
Reason/Purpose -Oklahoma’s Technical Assistance Document is provided as a resource and guide for agency personnel as well as vendors for the development of Web sites and Web applications in compliance with Oklahoma’s Web-based Intranet and Internet Information and Applications standards. This document can also serve as supplemental training for state agency, higher education, and career tech personnel. This document can also assist vendors to develop products or services that comply with Oklahoma’s standards or to determine if existing products or services already comply.
Definitions - The following definitions apply to these standards.
Flicker. A repeated, rapid, or fluctuating variation of brightness, contrast, or position on a display.
Key pages. Pages that represent the upper portions of a website’s hierarchy with respect to navigation including home pages of major subdivisions of content or services.
Meaningful text equivalent. Text that accurately and thoroughly conveys the content of a non-text element.
Modification. Alterations or deletions in a web page, document or component, except where the changes are the result of:
Automated retrieval of information from a database;
Content retrieved, framed or otherwise imported from an external site or web-based service;
Replacement of digital publications received from outside sources.
a) A meaningful text equivalent for every non-text element shall be provided (e.g., via "alt", "longdesc", or in element content) except for captioning of audio information which shall comply with (b) of this section.
What: When non-text elements including, but not limited to, images, graphs, video, and animations are created to convey information to the user, alternative methods to deliver the same information shall be provided.
Why: Individuals with vision impairments may be unable to read or perceive information presented in visual elements such as images, graphs, and videos. For images, screen reading software reads the alternate text instead. For more complex non-text elements, such as charts, graphs, and videos, a more thorough description is required to describe the content contained within the elements.
How: All images must have appropriate and meaningful alternate text. As a rule of thumb, consider what you might say if you were reading the web page to someone over the telephone. You do not need to include the words “photo of” or “graphic of.”
For images that contain words or letters – use alternate text that includes the same words or letters.
For image links – use alternate text that identifies the link’s destination or function. You do not need to include the words “link to.”
For graphics and photographs that provide information, provide alternate text that describes the information that the graphic or photo is intended to convey. Do not simply use “graphic” or “photo” as alternate text as they are not meaningful and do not describe the content contained within the graphic or photo.
For images that are invisible, purely decorative, or otherwise do not convey meaning – use alt=”” (two double quotes with no space between) to indicate that the image can safely be ignored by a screen reader.
For graphs, charts, or other images that require a more thorough written description for comprehension, the longdesc (long description) attribute of the img element can be used to provide a link to a full description. Also, a dlink (d-link) can be used to link to extended descriptions for images that are complex. Since longdesc is not supported by all current web browsers, it should not be used as the only method of providing a full description.
Ref: WCAG 1.1; 508 a
Difference between this standard and 508: The Oklahoma standard adds "meaningful" in front of "text equivalent" and specifies that audio information (considered a non-text element) is defined later in the document.
b) Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation.
What: Multimedia generally refers to recorded or live media containing video, audio, or both video and audio tracks. Equivalent alternatives that are synchronized with the multimedia presentation allow a user with disabilities to interpret the information conveyed by the presentation.
Why: Individuals who are deaf or hard of hearing may require captions or an alternate method to access the audio information of multimedia. Blind or low-vision individuals may require audio descriptions to access the visual information in multimedia presentations.
How: Whenever possible, captions should be implemented using Synchronized Multimedia Integration Language (SMIL) to synchronize the display of text from a transcript with the video. A less desirable alternative is to add captions through standard video recording before converting to a web format. Video captions should be synchronized with the action taking place on the screen.
Audio descriptions should be provided when they are necessary to present information displayed in a video format.
An alternative for audio presentations is a text transcription. Text transcriptions should be provided in HTML and linked from near the audio presentation.
Ref: WCAG 1.3, 1.4; 508 b
c) Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup. Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen.
What: Color is often used to indicate special functions or status. For example, required form fields are frequently indicated with red labels. Foreground and background colors can be specified by the web page author.
Why: Users who are blind, color-blind, or have limited or vision may miss information presented with color. Users with limited or low vision or color-blindness may have difficulty reading text that is similar in color to its background.
How: Whenever color is used as an indicator, use a non-color-based indicator as well. For example form fields could be identified with asterisks as well as color. For text, use dark colors on light backgrounds, or vice versa. Avoid combinations of red and green as well as busy background images.
Ref: WCAG 2.1, 2.2; 508 c
Difference between this standard and 508: The second sentence has been added to the original Section 508 standard.
d) Documents shall be organized so that they are readable without requiring an associated style sheet.
What: The positioning features of Cascading Style Sheets can be used to position elements visually almost anywhere on a web page.
Why: Screen readers read through the elements on a web page in the order in which they appear in the page code, regardless of how they are positioned using style sheets. It is essential that the reading order match the logical flow of the document so that a screen reader user would hear the document in the same order that a visual reader would read it.
How: Check the reading order by following the order in which elements appear in the page code. Reading order can usually be adjusted by rearranging the order in which elements are defined in the code. Methods to skip repetitive navigation, as defined in section (o) of this document, can also assist the user in reading the content on a page.
Ref: WCAG 6.1; 508 d
e) Redundant text links shall be provided for each active region of a server-side image map.
What: Server-side image maps use coordinates to specify active regions of the image. When a user activates an area of a server-side image map, the request is sent back to the server to be processed. Browsers cannot indicate to the user the URL that will be followed when a region of the server-side map is activated.
Why: Redundant text links are necessary to provide access to the page for any person not able to see or accurately click on the map.
How: Redundant text links should be placed in close proximity to the image utilizing a server-side image map. Whenever possible, use client-side image maps instead of server-side image maps. Server-side image maps should only be used when the map regions cannot be defined as client-side images maps with an available geometric shape.
Ref: WCAG 2.1; 508 e
f) 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.
What: Properly coded client-side image maps are more accessible than server-side image maps because each defined area can be given alternate text.
Why: Client-side image maps can provide the links related to the map in a text format which can be read with the use of assistive technology.
How: When using client-side image maps, provide an alternate text description to each active region of the client-side image map. Use alternate text that identifies the text equivalent of the active region as well as the link’s destination or function. The words “link to” do not need to be included in your alternate text.
Ref: WCAG 9.1; 508 f
g) Row and column headers shall be identified for data tables.
What: Headers identify the content of each row and/or column of a data table.
Why: A screen reader can use the table headers to provide row and column information while a user explores the data cells within a table
How: Identify content of data table by using column and row headings.
Use (th) (column header) elements to identify the content contained in table columns.
Alternately, the scope="col" (for column headers) can be used with either the th or td elements to identify column headings.
Use td (table data) elements scope="row" (for row headers) to identify cells that contained within that row.
Ref: WCAG 5.1; 508 g
h) 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.
What: Markup can be used to associate data cells with the appropriate header cells.
Why: Appropriate markup associating data cells and header cells in complex data tables allow users of assistive technology to better comprehend the information contained within the table.
When complex data tables are read by screen readers, users of screen readers may experience problems associating data with the appropriate row and column headers. Screen readers typically read tabular data in the order in which it is coded within the HTML source.
How: When possible, simplify complex tables by rearranging them or dividing them into separate tables. When a complex table is required, use advanced table markup, such as headers, axis, scope, col and colgroup, to fully indicate relationships between data cells and headers.
See W3C’s “Tables in HTML Documents” (http://www.w3.org/TR/html401/struct/tables.html#h-188.8.131.52) for complete details on how to markup complex tables.
Ref: WCAG 5.2; 508 h
i) Frames shall be titled with text that facilitates frame identification and navigation.
What: HTML frames are used to divide web pages into separate areas, each displaying a separate web page. Each frame is identified by a name attribute and each page contained within a frame is identified by its title element.
Why: To navigate pages with frames, users who are blind must be able to identify the different frames and understand the purpose of each frame. Most screen readers identify frames by speaking the name and/or page title of each frame.
How: Give each frame an understandable name that indicates the frame's function. For example, use name="Navigation" and name="Content" rather than name="nav" and name="right". Set the title element of each page contained within a frame to match the name attributes or to identify the current content of that frame.
Note: Traditionally, the "name" attribute is used for programming and should not contain spaces. The title attribute, which can contain spaces, can also be used to set a more descriptive name for each frame. However, this technique is not yet supported by all screen readers.
Ref: WCAG 12.1; 508 i
j) Pages and elements shall be designed so that screen flicker does not occur between frequencies 2 Hz and 55 Hz.
What: Animated graphics, Flash, Java and other techniques are often used to create a variety of animated effects.
Why: Flickering or blinking between 2 Hz and 55 Hz (cycles per second) can trigger epileptic seizures. In addition, elements that move may be more difficult to view by individuals who use screen magnifying techniques. Animation can also be distracting for individuals with cognitive or other visual impairments.
How: Do not cause elements to blink regularly between 2 and 55 Hz. Since there is not an easy method to measure the flicker rate of a flickering element, the best solution is to limit use of animation to only what is necessary in the web page.
Ref: WCAG 7.1, 7.2, 7.3; 508 j
Difference between this standard and 508: This standard is a minor change from Section 508 to improve clarity and does not change the meaning or intent of the original standard.
k) A text-only page, with equivalent information or functionality, shall be provided to make a web site comply with the provisions of these standards, when compliance cannot be accomplished in any other way. The content of the text-only page shall be updated whenever the primary page changes. The non-accessible version must be as accessible as possible.
What: Separate accessible or "text-only" versions are often offered instead of providing a single accessible site.
Why: Text-only pages can be used to provide equivalent information if accessibility compliance cannot be met in any other way. The content of the text-only page must be updated when the primary page is updated to keep information equally available to individuals who may not be able to interpret and read the primary page.
How: A text-only presentation of the content and functionality of the original page can be created. A link to the text-only page should be prominently placed to allow users and assistive technology to locate and navigate to the text-only portion.
Note: Manually developing and maintaining a separate "text-only" version of an entire site is tremendously demanding of time and resources. Given advances in accessibility techniques and assistive technologies, "text-only" sites are not necessary in most cases. Follow these standards to develop a single site that is universally accessible and efficient to maintain.
Ref: WCAG 11.4; 508 k
Difference between this standard and 508: This section has been modified from the Section 508 standard to include the last sentence.
l) When pages utilize scripting or other programmatic elements to display content, the information provided by the script shall also be provided in an equivalent text format that can be processed and interpreted by assistive technology. When pages utilize scripting or other programmatic elements to create user interfaces, user interaction shall be input device independent.
For user interfaces, scripting or programmatic elements can be used within a web browser to automate certain tasks and enable pages to change and respond to user input. Some events are triggered by either mouse or keyboard actions. For example, an image can change color when the mouse pointer hovers over it (the onmouseover event).
Why: Older assistive technologies and web browsers may not support client-side scripting at all. Even current assistive technologies may interact in unexpected ways with content that is displayed using scripts, such as by skipping text that is dynamically displayed or reading text that is dynamically hidden. Users need to be able to access the same essential content and functionality whether scripts are fully, partially, or not supported. It is not safe to assume that users with disabilities will have scripting support turned off.
Users with physical impairments may be able to use the keyboard but not the mouse. Individuals who cannot see the mouse pointer on the screen may use the keyboard or voice commands for all interactions. Scripts that can only be triggered by the mouse are not usable by these individuals.
How: Whenever scripts are used, it is the responsibility of the page developer to ensure that all information and functionality is accessible. There are several resources available as software downloads or as online applications (see appendix) to assist developers in testing for accessibility, but no computer software or application can determine full accessibility compliance. If there is any doubt, err on the safe side by ensuring that the essential elements of the page do not rely on scripts.
Note: One approach to ensuring accessibility with scripts is to include a back-up method of providing the same information and functionality that does not require scripts. For example, if a client-side script is used to check an entry in a form field, a server-side script could make the same check. Similarly, if scripts are used for "drop-down" menus, the same menu choices could be provided in an appropriate location elsewhere on the current or subsequent page. Additionally, scripting features that are purely decorative and do not present any significant information or functionality do not need to be made accessible. (However, remember Guideline 8.1 - Avoid flickering, blinking, and unnecessary animation.)
Whenever using a mouse-only event (e.g., onmouseover, onmouseout) to trigger a significant script action, also use the corresponding keyboard event (e.g., onfocus, onblur). Also make sure that keyboard events do not unintentionally trigger script actions. For example, keyboard users should be able to arrow through the choices in a select list without triggering each choice (e.g., onchange).
Ref: WCAG 6.3; 508 l
Difference between this standard and 508: This standard has been modified from the original Section 508 standard. The term "programmatic elements" has been added in the first sentence. “User interfaces” has been moved to a second sentence and information dealing with input device independency for user interfaces has been added.
m) 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 Oklahoma Software Applications and Operating Systems standards (a) through (l).
What: “Applets” and "plug-ins" refer to a variety of web technologies, such as Java and Flash, which can be used to create advanced, interactive content on web pages. Both require additional software to be downloaded, installed, and run before the content can be viewed or used. Applets and plug-ins also operate with their own user interfaces, which are separate and different from that of standard web pages.
Why: Because applets and plug-ins have their own interfaces, they must be accessible in and of themselves. If essential content or functionality is presented using an applet or plug-in that is not accessible, it will not be usable by individuals with disabilities. Users may not already have the plug-in or applet required to access the information contained, therefore a link to a location where the appropriate plug-in or applet can be downloaded must be provided.
How: Check with the manufacturer and/or developer of each applet or plug-in to determine if and how the technology is accessible. When an accessible applet or plug-in is available, provide users with a link to any special instructions or software that is necessary.
Wherever a link is provided to an inaccessible applet or object, also provide a link to content in an alternate, accessible format. Make sure that the information and functionality is completely equivalent and up-to-date. Be sure to consider whether the inaccessible version is actually necessary.
In cases where it is impossible to create an equivalent accessible version, such as with some geographical imaging and mapping systems, exceptions may be necessary.
Ref: WCAG 8.1; 508 m
Difference between this standard and 508: This standard has been slightly modified to refer to Oklahoma's software and operating system standards rather than Section 508's standards.
n) 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.
What: HTML forms include input elements such as buttons (input type="button"), text boxes (input type="text"), list boxes (select), and many others. Each field is typically identified by a text label.
Screen reader and keyboard users move between form fields (and links) using the Tab key. The order in which form fields receive focus is called the tab order. By default, the tab order follows the order in which elements appear in a page's HTML code.
Why: Screen readers cannot always determine which label belongs to which field based on positioning alone. The label element makes this association clear.
When screen magnification software enlarges a web page it also reduces the field of view. If form field label is positioned far away from its field, it may be impossible for a screen magnifier-user to view both the field and the label at the same time.
When filling out a form, screen readers typically read only the field's label. Screen magnifiers will focus on the field and its label, and instructions may be out of the field of view.
Depending on the design and layout of a page, the tab order may not match the visual (or logical) order of fields on a form. Reading fields out of their intended order can be disorienting for a screen reader or keyboard user.
How: Use the label for="" tag to label every form field.
Note: The value of a label's “for” attribute is the corresponding field's ID, not its name.
Position labels immediately adjacent to fields, preferably in standard locations, such as on the left or above text boxes and list boxes and on the right of checkboxes and radio buttons.
Use the “fieldset” element to group form controls into semantic units and describe the group with the “legend” element. Use “optgroup” to organize long lists of menu options into smaller groups.
Special instructions should be given before the form field and within the field label if possible. If instructions are too long to appropriately fit within the label, they should be given in an instructions section in advance of the form.
Make sure that fields appear in the HTML code in the logical order and/or use tabindex to set the appropriate order.
Note: Tabindex is not supported by Internet Explorer or Netscape versions 4 and below.
Ref: WCAG 9.4, 10.2; 508 n
o) A method shall be provided that permits users to skip repetitive navigation links.
What: Repetitive navigation lists or menus are commonly repeated on every page of a web site.
Why: By providing a method that permits users to skip repetitive navigation links, users that utilize a screen reader technology, keyboard navigation, or other assistive technology may access the content area of a web page without having to read or tab through the navigation each time they load a page. This significantly increases the efficiency and usability of web pages for users who depend on these assistive technologies for access.
How: Provide a link at the beginning of navigation lists that links to a target at the beginning of the main content area of the page. This link must be available to screen reader and keyboard users, and is recommended to be visible when the page is viewed normally.
Ref: 508 o
p) When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.
What: Some web pages, frequently those that require a user to log in with an ID and password, "reset" themselves after a certain period of inactivity. Typically, any form entries that have been partially completed are erased and the user must start over.
Why: Users with visual, physical, or cognitive disabilities may require more time than average to read and interact with a web page.
How: Provide a clear explanation of any time limits and offer the user a way to extend or remove the limits if necessary. Avoid using time limits unnecessarily.
Ref: WCAG 7.5; 508 p
q) Use valid, industry recognized web programming standards including a document type definition or the equivalent.
What: The World Wide Web Consortium (W3C) sets and publishes standards for most web programming languages, including HTML 4.01, XHTML 1.0, CSS Level 1 & 2, DOM, and SMIL. Programming code is considered "valid" when it follows all the rules and conventions specified in the published standards.
Why: Screen readers and other assistive technologies can more accurately interpret and interact with web pages that are built using valid, standard code. W3C languages are designed with accessibility in mind.
How: Indicate the programming language you are using by starting your code with a document type declaration such as:
!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
Use the W3C HTML Validation Service (http://validator.w3.org) and W3C CSS Validation Service (http://jigsaw.w3.org/css-validator) to check your code. Refer to the World Wide Web Consortium site (http://www.w3.org) for full specifications and documentation.
Ref: WCAG 3.2, 11.1
Difference between this standard and 508: This standard has been added to Oklahoma's standards and is not part of Section 508.
r) Identify the primary natural language of the document.
What: HTML uses the lang attribute to specify language in a web page. It can be set for any HTML element.
Why: Some screen readers and Braille devices are able to pronounce words in their appropriate language if it is specified.
How: Use the lang attribute on the html element to identify the primary language of each document. For example, html lang="en" identifies that English is the primary natural language for an html document.
Ref: WCAG 4.3
Difference between this standard and 508: This standard has been added to Oklahoma's standards and is not part of Section 508.
s) A link to the agency's website accessibility policy (if existing) and contact information for compliance issues related to the accessibility of electronic and information technology shall be included on home pages and other key pages.
What: An agency’s website accessibility policy as well as a contact person for accessibility issues should be identified and presented on the agency’s website. Contact information should include e-mail, telephone, TTY, and mailing address.
Why: The agency’s website accessibility policy provides valuable information to users of the website. Contact information for accessibility compliance issues allows individuals to report accessibility problems or request information in an alternate accessible format. These resources should be readily available on home pages and other key pages on the agency’s website to allow users to find them easily.
How: Provide a link to the agency’s website accessibility policy as well as contact information on home pages and other key pages on the agency’s website. Key pages include the agency home page, unit index pages, and pages that are common entry pages for users arriving at the site from search engines. Contact information may be listed directly or linked to from the home page or key pages. For best results, provide the policy link and contact information in site templates so that they appear on every page in a consistent location.
Ref: n/a Difference between this standard and 508: This standard has been added to Oklahoma's standards and is not part of Section 508.
a) Every image has meaningful alternate text describing the image.Images that contain words or letters, the alternate text includes the same words or letters Yes, No, N/A
Images that are invisible, purely decorative, or otherwise do not convey meaning, the alternate text attribute is set to null. (alt="") Yes, No, N/A
For graphs, charts, or other images that require a more thorough description, the content contained withing that non-text element is presented in a text format. Yes, No, N/A
b) Video captions are synchronized with action taking place on the screen. Yes, No, N/A
Audio descriptions are provided when necessary. Yes, No, N/A
c) Web pages are designed so that all information conveyed with color is also available without color, for example from context or markup. Yes, No, N/A
Foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen. Yes, No, N/A
d) Documents are organized so they are readable without requiring an associated style sheet. Yes, No, N/A
e) Redundant text links are provided for each active region of a server-side image map Yes, No, N/A
f) Client-side image maps are provided instead of server-side image maps except where regions cannot be defined with an available geometric shape. Yes, No, N/A
g) Row and column headers are identified for data tables. Yes, No, N/A
h) Markup is used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers. Yes, No, N/A
i) Frames are titled with text that facilitates frame identification and navigation. Yes, No, N/A
j) Pages and elements are designed so that screen flicker does not occur between the frequencies of 2Hz and 55Hz. Yes, No, N/A
k) A text-only page, with equivalent information and functionality, is provided to if compliance cannot be accomplished in any other way. Yes, No, N/A
The text-only page is updated whenever the primary page changes. Yes, No, N/A
The non-compliant page is accessible as possible. Yes, No, N/A
l) For pages utilize scripting or other programmatic elements to display content, the information provided by the script is also provided in an equivalent text format that can be processed and interpreted by assistive technology. Yes, No, N/A
For pages that utilize scripting or other programmatic elements to create user interfaces, user interaction is input device independent. Yes, No, N/A
m) For a web page requires that an applet, plug-in or other application be present on the client system to interpret page content, the page provides a link to a plug-in or applet that complies with Oklahoma Software Applications and Operating Systems standards (a) through (l). Yes, No, N/A
n) If electronic forms are designed to be completed on-line, the form allows 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. Yes, No, N/A
o) A method is provided that permits users to skip repetitive navigation links. Yes, No, N/A
p) If a timed response is required, the user is alerted and given sufficient time to indicate more time is required. Yes, No, N/A
q) Valid, industry recognized web programming standards including a document type definition or the equivalent is used. Yes, No, N/A
r) The primary natural language of the document is identified. Yes, No, N/A
s) A link to the agency's website accessibility policy (if existing) and contact information for compliance issues related to the accessibility of electronic and information technology is included on home pages and other key pages. Yes, No, N/A
Testing and Validity - Testing and validation can assist a developer in improving the accessibility of web pages.
Valid code is a good starting point on the way to web accessibility. The World Wide Web Consortium (W3C) has standards for many online technologies, including HTML (and XHTML) and CSS. Section Q of Oklahoma’s Web Accessibility Standards requires the use of “valid, industry recognized web programming standards including a document type definition or the equivalent.” Information about the W3C’s HTML standards can be found at http://www.w3.org/MarkUp/.
The W3C also offers an online markup validation service at http://validator.w3.org/ that will check web pages for conformance to W3C Recommendations.
Several online tools or software programs are also available to assist in testing for web accessibility. However, proper testing always requires human judgment as there are no programmatic tools or utilities that can absolutely conclude whether a page or site meets is accessible. Below are some online tools that can assist in testing for web accessibility.
WAVE Web Accessibility Tool - http://www.wave.webaim.org/index.jsp
Cynthia Says Portal - http://www.cynthiasays.com/
LIFT, including LIFT for Macromedia Dreamweaver and Microsoft FrontPage - http://www.usablenet.com/products_services/products_services.html
NILS Web Accessibility Toolbar for Internet Explorer for Microsoft Windows - http://www.nils.org.au/ais/web/resources/toolbar/
Web Developer Toolbar extension for Mozilla Firefox - https://addons.mozilla.org/
WebAIM Evaluation and Repair Tools page - http://www.webaim.org/products/
Manually checking code against compliance checklists and other forms of human testing are the most effective methods to ensure compliance with Oklahoma’s Accessibility Standards.
More to come – descriptions, reorganization, etc.
Access Board and Standards http://www.access-board.gov/508.htm
Access IT technical assistance for education http://www.washington.edu/accessit
Adobe’s Page on Acrobat Accessibility http://www.adobe.com/enterprise/accessibility/
Assistive Technology Program Oklahoma ABLE Tech (800) 257-1705 http://okabletech.okstate.edu
Building Accessible Websites online book http://joeclark.org/book/sashay/serialization/
Center for Applied Special Technology http://www.cast.org
Color-Blindness Simulators http://webexhibits.org/causesofcolor/2.html
Disability Law Resource Project Technical support for the Americans with Disabilities Act, IT accessibility, and educational entities
Dive Into Accessibility Web Training Course http://diveintoaccessibility.org
Equal Access to Software and Education http://www.rit.edu/~easi/
Federal Section 508 http://www.section508.gov
National Center for Accessible Media http://ncam.wgbh.org/
Oklahoma Advisory Council on Electronic and Information Technology Accessibility For more information contact Oklahoma ABLE Tech(800) 257-1705
Society for Technical Communication – Accessibility SIG http://www.stcsig.org/sn/index.shtml
Trace Center http://www.trace.wisc.edu
Web Accessibility Initiative-W3C Guidelines for web design http://www.w3.org/WAI/
World Wide Web Consortium (W3C) http://www.w3.org
OK.gov and Online tutorial for accessible web design http://www.ok.gov
This document was authored by members of the Electronic and Information Technology Advisory Council, Subcommittee 2: Web-based Intranet and Internet Information and Applications; Video and Multimedia Products.
Lead: Chip Diffendaffer, Southwestern Oklahoma State University
Subcommittee Chair: Kevin Sesock, Assistive Technology Specialist, Student Disability Services
Oklahoma State University, Phone: 405-744-2024
Coordinating Organization for the EITA Advisory Council: Oklahoma ABLE Tech, 1514 W. Hall of Fame, Stillwater, OK, Phone: 1-800-257-1705 or 405-744-9748. http://okabletech.okstate.edu
Julie Brantley Department of Rehabilitation Services
Elaine Boykin, Department of Rehabilitation Services
Robert Breisch, Department of Career Tech
Lisa Counts, Ok.gov
Joshua Craig, Web Administrator for the Oklahoma State Regents for Higher Education
Rod Davidson, Department of Human Services
Brenda Dawes, OK ABLE Tech
Chip Diffendaffer, Southwestern Oklahoma State University
Ed Eckenstein, Water Resources Board
Teri Ferguson, Oklahoma State University - OKC
Phillip Jackson, Oklahoma County MIS
Linda Jaco, OK ABLE Tech
David Jinks, Department of Career Tech
Michael O'Hasson, Department of Libraries
Jason Price, Department of Rehabilitation Services
Lee Roberts, Rose Rock Design
Kevin A. Sesock, Oklahoma State University
William Wright, Oklahoma Health Care Authority
For additional questions, contact Oklahoma ABLE Tech: Oklahoma ABLE Tech Oklahoma State University Seretean Wellness Center 1514 W. Hall of Fame Stillwater, OK 74078 http://okabletech.okstate.edu Phone/TDD: (800) 257-1705 Fax: (405) 744-2487
alt, alternate text: The “alt” attribute is used inside img and area tags to provide a text equivalent to the non-text element. Example: img src=”photo.jpg” alt=”My Photo” /. Standards (a) and (f)
audio information: Audio information refers to information presented to the user that must be received aurally. Standard (b)
captioning: Captions are a written representation of audio or dialogue that accompanies video information. Captions are similar to subtitles but also convey non-dialogue auditory information that is important to the video, such as laughter.
equivalent alternatives: Equivalent alternavites are different means of providing information, including product documentation, to people with disabilities. Equivalent alternavites may include, but are not limited to, voice, fax, relay service, TTY, Internet posting, captioning, text-to-speech synthesis, written transcripts, and audio description. Standard (b)
frames: HTML frames allow authors to present documents in multiple views, which may be independent windows or subwindows. Multiple views offer designers a way to keep certain information visible, while other views are scrolled or replaced. For example, within the same window, one frame might display a static banner, a second a navigation menu, and a third the main document that can be scrolled through or replaced by navigating in the second frame. (From the first paragraph under 16.1: http://www.w3.org/TR/REC-html40/present/frames.html#h-16.1) Standard (i)
key pages: Pages that represent the upper portions of a website’s hierarchy with respect to navigation including home pages of major subdivisions of content or services. The top-level section pages are the most common links in the site's navigation system. It also includes the first page of any site help system. For online applications, the application start page and the first page of any application help system are key pages. Standard (t)
longdesc: Attribute meaning long description used to describe complex images.
If the information contained in the image is important to the meaning of your page (i.e. some important content would be lost if the image was removed) , then you must provide a longer description than the "alt" attribute can reasonably display. The "longdesc" attribute was created for this reason. (Taken from http://www.w3.org/WAI/wcag-curric/sam3-0.htm)
markup: Markup refers to the use of a markup language to describe the structure and appearance of a particular document. Certain symbols are placed inside a document and are interpreted by a program (such as a web browser and a word processor) or by a compiler (such as LaTeX) into a more readable version of the text.
Taken from http://en.wikipedia.org/wiki/Markup_(computing). Standard (h)
meaningful text equivalent: Text that accurately and thoroughly conveys the content of a non-text element. For example, simply using "image" or "photo" as alternate text does not provide a meaningful description of what the image represents. Standard (a)
multimedia presentation: Multimedia is the use of several different media to convey information such as text, audio, graphics, animation, video, and interactivity. From Wikipedia (http://en.wikipedia.org/wiki/Multimedia)
programmatic elements: Programmatic elements include scripts and applets that perform a specified function on a web page. Standard (l)
screen flicker: A repeated, rapid, or fluctuating variation of brightness, contrast, or position on a display. Standard (j)
synchronized: Equivalent alternatives that are synchronized with a presentation are provided in unison with the original presentation. Synchronized alternatives may include closed captioning, audio descriptions, and other methods.
timed response: Any programmatic element or script that triggers an action after a specific period of time that limits a user's ability to read a page or complete a task. This includes scripts to automatically refresh pages and scripts that "time out" a user session after a specific period of time. Standard (p)
user interfaces: A user interface is a set of commands or menus through which the user communicates with a program or web page.
Web pages: HTML/XHTML files including the associated graphics, CSS and script files intended for delivery to a user's Web browser via the HTTP protocol.
web programming standard: A web programming standard in this document refers to standards and recommendations of the World Wide Web Consortium (W3C). More information can be found at http://www.w3c.org. Standard (r)
The subcommittee would like to acknowledge the following resources that were consulted in the compilation of this document.
The Access Board, http://www.access-board.gov, developed accessibility standards for the various technologies covered by the law, Section 508 of the Rehabilitation Act.
Oklahoma's electronic and information technology accessibility law, HB 2197 - http://okabletech.okstate.edu/eit/hb2197text.htm
Section 508 of the Rehabilitation Act, as amended by the Workforce Investment Act of 1998 - http://www.section508.gov
Illinois Web Accessibility Standards - http://www100.state.il.us/ito/iwas1_2.cfm
Missouri IT Accessibility Standard - http://oit.mo.gov/standards/ITGS0003.pdf
World Wide Web Consortium (W3C) http://www.w3.org and the
Web Accessibility Initiative (WAI) – http://www.w3.org/WAI/
WebAIM (Web Accessibility in Mind) – http://www.webaim.com
Wikipedia - http://en.wikipedia.org