accessibility guidelines for flex, 2007

SKITSANOS

2007

Adobe Flex Accessibility Evaluation

Accessibility guidelines and test sheets

Evgenios Skitsanos

H T T P : / / W W W . S K I T S A N O S . C O M

Adobe Flex Accessibility Evaluation March 1, 2007

h t t p : / / w w w . s k i t s a n o s . c o m

Web Application Accessibility Evaluation The Federal Mandate: Section 508 Standards

Section 508 of the U.S. Rehabilitation Act prohibits federal agencies from buying, developing, maintaining, or using electronic and information technology that is inaccessible to people with disabilities. Although Section 508 was enacted more than 14 years ago, little progress was made until 1998, when Congress passed the Workforce Investment Act, amending the law to give members of the public and government employees with disabilities the right to sue agencies in federal court and file administrative complaints for noncompliance.

The deadline for full compliance of Federal websites with Section 508 was June 21, 2001. (It does not apply to web pages of private industry). Specifically, the law directs all Federal agencies that develop, procure, maintain, or use electronic and information technology to ensure that this technology is accessible to employees and members of the public. The amended Section 508 requires that:

"…electronic and information technology allows Federal employees with disabilities to have access to and use of information and data that is comparable to the access to and use of information and data by Federal employees who are not individuals with disabilities, unless an undue burden would be imposed on the agency." Read the full regulation.

Accessibility policies vary from country to country, but most countries, including the European Union, have adopted standards based on the Web Content Accessibility Guidelines (WCAG) of the World Wide Web Consortium. In the United States, Section 508 of the U.S. Rehabilitation Act mandates that web content maintained by the federal government must be made accessible to people with disabilities. This law is based on W3C priority 1 checkpoints.



Section 508 also requires that:

“…individuals with disabilities who are members of the public seeking information or services from a Federal agency have access to and use of information and data that is comparable to that provided to the public who are not individuals with disabilities, unless an undue burden would be imposed on the agency.” The full regulation can be viewed at www.usdoj.gov.

While applying legal leverage to agencies, Section 508 also uses government buying power to pressure companies to produce accessible products. Section 508 standards will become part of the Federal Acquisition Regulation and other federal laws that govern agency buying. Simply put, companies will no longer be able to sell federal agencies any software or hardware that fails to meet accessibility standards.

This report would give some explanations on current requirements on web application usability and accessibility, clarify number of tests and their results and describe couple of products that exists today on the market for people with disabilities.

This report describes the conformance of the Flex driven Web application sample with W3C's Web Content Accessibility Guidelines (WCAG) 1.0. The review process is described document below and is based on the W3C's Conformance Evaluation method as described in Evaluating Web Sites for Accessibility. Based on this evaluation, sample web application does not meet WCAG 1.0 -‐ Conformance Level Double A. Detailed review results are available within this document below.



Section 508 Checklist

First thing you need to know in order to test your web application is what the minimal requirements that your web application have to fulfill. There are at least two sets of requirements for this moment, one is for HTML and another one is for JavaScript. Since target application is going to be implemented in Adobe Flex we going to review requirements related only to Adobe Flex framework.

Accessibility Requirements for Scripts, Plug-‐ins, Java, etc. The following standards are excerpted from Section 508 of the Rehabilitation Act, §1194.21. Full text of Section 508 -‐ external link (http://www.section508.gov/index.cfm?FuseAction=Content&ID=12).

SEC. 508 STANDARD (a) 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. (b) 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. (c) 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. (d) 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. (e) 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. (f) 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. (g) Applications shall not override user selected contrast and color selections and other individual display attributes. (h) When animation is displayed, the information shall be displayable in at least one non-‐animated presentation mode at the option of the user. (i) Color coding shall not be used as the only means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. (j) 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. (k) 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.



(l) 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.



Software applications for disabled people

JAWS The most popular screen reader worldwide, JAWS® for Windows® works with your PC to provide access to today’s software applications and the Internet. With its internal software speech synthesizer and the computer’s sound card, information from the screen is read aloud, providing technology to access a wide variety of information, education and job related applications. JAWS also outputs to refreshable braille displays, providing unmatched braille support of any screen reader on the market. Get started with training in DAISY format and a trial version of Freedom Scientific's FSReader DAISY player software.

Product home page: http://www.freedomscientific.com/fs_products/software_jaws.asp

Thunder Thunder is free screen reader talking software for blind and visually impaired people. Thunder will speak all Windows menus and dialog boxes, allowing full control of your computer. It gives full speech feedback for most text-‐based word processing tasks including editing documents. Thunder enables the blind user to keep in touch with friends and family in complete privacy by using the popular Outlook Express e-‐mail, which is available on every computer. To enjoy the internet, use WebbIE, the text browser, which is part of the Thunder download.

Product home page: http://www.screenreader.net/



Accessibility tests At this moment JAWS seems as most advanced screen reader with rich functionality and capabilities to handle very complicated web content as well with handling static applications within user’s desktops.

Screen reader and Browser specifics By now, almost everyone has heard about the IE Security Update and how it impacts ActiveX control interaction. With the release of JAWS 7.1, there are additional reasons to make sure that you add the HTML Object element in the way suggested at the Active Content Developer Resource site (http://www.adobe.com/devnet/activecontent/).

If you don't, here's an example of the badness that you'll inflict on your screen reader users. In JAWS there are two modes that you need to think about -‐ Virtual PC Cursor mode, which allows the user to read through the document line by line or using several shortcuts; and Forms mode, which allows users to interact with controls and type information into editable controls. There are two modes because keystrokes that are needed to navigate (e.g. "f" takes you to the first form control on a page in HTML or Flash) may also be needed in a control (e.g. Frank needs to enter his name in a TextInput). When a user locates a form control in HTML or Flash, they hit 'enter' and JAWS says "forms mode on" and the user can interact with the control.

To simplify your Flex application launching process we do recommend using small JavaScript library called SWFObject by Geoff Stearns.

SWFObject is a small JavaScript file that you can use for embedding Macromedia Flash content into your website. The script detects Flash Player in all major web browsers (Mac OS and Windows) and is designed to make embedding SWF files as easy as possible.

Besides being very search engine–friendly, SWFObject degrades gracefully, can be used in valid HTML and XHTML 1.0 documents (that is, when pages are sent as text/html instead of application/xhtml+xml), and is forward-‐compatible. It should work for years to come.

You can read how SWFObject works on Adobe web site at http://www.adobe.com/devnet/flash/articles/swfobject_02.html

A second issue with JAWS 7.1 is that when you tab through a web page in Virtual PC Cursor mode and tab to the not-‐yet-‐activated ActiveX control you might expect that you'd hear the same information that is available visually ("Press SPACEBAR or ENTER to activate and use this control"), but you don't. You hear nothing. If the user is aware that they've tabbed onto something they might hit ins+tab to read that item and then they will hear "Flash movie start". If the use is familiar with what is going on they might hit enter or space, but neither will work. The user needs to use the arrow keys to navigate into the flash content and if they need to enter forms mode deal with repositioning their focus.



All of this is a consequence of changes made to JAWS for version 7.1. If you enable "legacy Internet Explorer Support" in the JAWS Configuration Manager's HTML Options dialog all of these issues go away, but you can't count on users doing that.

Avoid all this by using the method recommended at the Active Content Developer Resource site (http://www.adobe.com/devnet/activecontent/).

Product Accessibility Templates Adobe released Product Accessibility Templates for number of their products, include Adobe Flash. Adobe Voluntary Product Accessibility Template (VPAT) spells out the details of the law and outlines the accessibility-‐related features of various products. A Voluntary Product Accessibility Template, or VPAT, is a standardized form that lists all of the regulations of Section 508 and explains how a given product helps you comply with each regulation. The VPAT was developed by the Information Technology Industry Council to be used across the software industry.

The purpose of the Voluntary Product Accessibility Template is to assist federal contracting officials in making preliminary assessments regarding the availability of commercial electronic and information technology products and services with features that support accessibility. It is assumed that these product and service providers will offer additional contact information to facilitate more detailed inquiries.

The first table of the Accessibility Template provides a summary view of the Section 508 standards. The subsequent tables provide more detailed information on each subsection. Each table contains three columns. Column one of the Summary Table describes the subsections of subparts B and C of Section 508 standards. The second column of the Summary Table describes the supporting features of the product or refers readers to a corresponding Detail table. Finally, the third column of the Summary Table contains any additional remarks and explanations about the product. In the subsequent (Detail) tables, the first column lists the lettered criteria of each subsection. The second column describes the supporting features of the product as specified by that criteria. The third column contains any additional remarks and explanations about the product relating to the specified criteria.

VPAT for Flash Player version 8 had been used, since there no materials published yet for Flash 9.

Summary Table Voluntary Product Accessibility Template

Criteria Supporting Features Remarks and explanations Section 1194.21 Software Applications and Operating Systems

Please refer to the following VPAT for Macromedia Flash 8 features that meet these criteria.

The criteria of this section apply to Macromedia Flash 8, the application used to create Macromedia Flash Player 8 content.

Section 1194.22 Web-‐based internet information and

Please refer to the following VPAT for Macromedia Flash 8

The criteria of this section apply to Macromedia Flash 8, the application



applications features that meet these criteria.

used to create Macromedia Flash Player 8 content.

Section 1194.23 Telecommunications Products

These criteria do not apply to Macromedia Flash 8.

Section 1194.24 Video and Multi-‐media Products



Section 1194.25 Self-‐Contained, Closed Product


Section 1194.26 Desktop and Portable Computers


Section 1194.31 Functional Performance Criteria



Section 1194.41 Information, Documentation, and Support



Section 1194.21 Software Applications and Operating Systems – Detail Voluntary Product Accessibility Template

Criteria Supporting Features Remarks and explanations (a) 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.

Criteria partially met: In Macromedia Flash 8, interaction with the Stage and the Timeline is not possible using the keyboard.

(b) 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

Criteria met with minor exceptions: Macromedia Flash 8 does not interfere with accessibility features native to operating systems, with the exception of button images in the Property and Tag inspectors which are difficult to see when using the Windows XP high contrast mode.



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. (c) 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.

Criteria fully met.

(d) 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.

Criteria met with minor exceptions: Macromedia Flash 8 does not provide information about whether individual panels are open or closed to assistive technology.

(e) 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.

Criteria fully met.

(f) 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.

Criteria fully met.

(g) Applications shall not override user selected contrast and color selections and other individual display attributes.

Criteria partially met: Selected panels do not respond to user-‐selected operating system color and contrast or font display size



settings, including the output, parameters, bindings, schema, and libary panels.

(h) When animation is displayed, the information shall be displayable in at least one non-‐animated presentation mode at the option of the user.

Criteria fully met.

(i) Color coding shall not be used as the only means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

Criteria fully met.

(j) 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.

Criteria fully met.

(k) Software shall not use flashing or blinking text, objects, or other elements having a flashing or blink frequency greater than 2 Hz and lower than 55 Hz.

Criteria fully met.

(l) 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.

Criteria partially met: The following dialog boxes in the Macromedia Flash 8 authoring application use custom controls not readily accessible by assistive technology. These include: the Preferences dialog box, the Keyboard Shortcuts dialog box, and the Create New Symbol dialog box.

Section 1194.22 Web-‐based Internet information and applications -‐ Detail Voluntary Product Accessibility Template

Criteria Supporting Features Remarks and explanations (a) A text equivalent for every non-‐text element shall be provided (e.g., via "alt", "longdesc", or in

Criteria fully met.



element content). (b) Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation.

Criteria fully met.

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

Criteria fully met.

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

Criteria not applicable to this product.

Macromedia Flash 8 content works independently of style sheets.

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


Macromedia Flash 8 content does not use server-‐side image maps.

(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.


Macromedia Flash MX content does not use client-‐side image maps.

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

Criteria not met. Macromedia Flash 8 content does not have primitives for table data.

(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.

Criteria not met. Macromedia Flash 8 content does not have primitives for table data.

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


Macromedia Flash 8 content does not contain layout frames.

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

Criteria fully met.

(k) A text-‐only page, with equivalent information or functionality, shall be provided to make a web site comply with the provisions of this part, when compliance cannot be accomplished in any other way. The content of the text-‐only page shall be updated whenever the primary page changes.

Criteria fully met.

(l) When pages utilize scripting Criteria fully met.



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. (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 §1194.21(a) through (l).

Criteria fully met.

(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.

Criteria fully met.

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

Criteria fully met.

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

Criteria fully met.

Note to 1194.22: The Board interprets paragraphs (a) through (k) of this section as consistent with the following priority 1 Checkpoints of the Web Content Accessibility Guidelines 1.0 (WCAG 1.0) (May 5 1999) published by the Web Accessibility Initiative of the World Wide Web Consortium: Paragraph (a) -‐ 1.1, (b) -‐ 1.4, (c) -‐ 2.1, (d) -‐ 6.1, (e) -‐ 1.2, (f) -‐ 9.1, (g) -‐ 5.1, (h) -‐ 5.2, (i) -‐ 12.1, (j) -‐ 7.1, (k) -‐ 11.4.

Section 1194.24 Video and Multimedia Products -‐ Detail Voluntary Product Accessibility Template

Criteria Supporting Features Remarks and explanations (a) All analog television displays 13 inches and larger, and computer equipment that includes analog television receiver or display circuitry, shall be equipped with caption decoder circuitry which


Macromedia Flash 8 does not include any display hardware.



appropriately receives, decodes, and displays closed captions from broadcast, cable, videotape, and DVD signals. As soon as practicable, but not later than July 1, 2002, widescreen digital television (DTV) displays measuring at least 7.8 inches vertically, DTV sets with conventional displays measuring at least 13 inches vertically, and stand-‐alone DTV tuners, whether or not they are marketed with display screens, and computer equipment that includes DTV receiver or display circuitry, shall be equipped with caption decoder circuitry which appropriately receives, decodes, and displays closed captions from broadcast, cable, videotape, and DVD signals. (b) Television tuners, including tuner cards for use in computers, shall be equipped with secondary audio program playback circuitry.


Macromedia Flash 8 does not include any television tuner hardware.

(c) All training and informational video and multimedia productions which support the agency's mission, regardless of format, that contain speech or other audio information necessary for the comprehension of the content, shall be open or closed captioned.

Criteria fully met. Designers may provide synchronized text and audio equivalents in Macromedia Flash 8 using one of four methods. For more information on captioning, please go to the Macromedia Accessibility Resource Center

(d) 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.

Criteria fully met.

(e) Display or presentation of alternate text presentation or audio descriptions shall be user-‐

Criteria fully met.



selectable unless permanent.

Section 1194.31 Functional Performance Criteria Voluntary Product Accessibility Template

Criteria Supporting Features Remarks and explanations (a) At least one mode of operation and information retrieval that does not require user vision shall be provided, or support for assistive technology used by people who are blind or visually impaired shall be provided.

Criteria partially met: Macromedia Flash 8 may be used to create content that does not require user vision; however, some vision is required to manipulate the Stage and Timeline in Macromedia Flash 8.

(b) At least one mode of operation and information retrieval that does not require visual acuity greater than 20/70 shall be provided in audio and enlarged print output working together or independently, or support for assistive technology used by people who are visually impaired shall be provided.

Criteria fully met.

(c) At least one mode of operation and information retrieval that does not require user hearing shall be provided, or support for assistive technology used by people who are deaf or hard of hearing shall be provided.

Criteria fully met.

(d) Where audio information is important for the use of a product, at least one mode of operation and information retrieval shall be provided in an enhanced auditory fashion, or support for assistive hearing devices shall be provided.

Criteria fully met.

(e) At least one mode of operation and information retrieval that does not require user speech shall be provided, or support for assistive technology used by people with disabilities shall be provided.

Criteria fully met.



(f) At least one mode of operation and information retrieval that does not require fine motor control or simultaneous actions and that is operable with limited reach and strength shall be provided.

Criteria fully met.

Section 1194.41 Information, Documentation, and Support -‐ Detail Voluntary Product Accessibility Template

Criteria Supporting Features Remarks and explanations (a) Product support documentation provided to end-‐users shall be made available in alternate formats upon request, at no additional charge.

Criteria partially met: Help documentation in Macromedia Flash 8 is available in four general locations. First, help documentation can be found in the printed documentation that accompanies Macromedia Flash 8. Second, help documentation identical to that found in the printed documentation is available in HTML format under the Help menu item Using Flash in Macromedia Flash 8. Third, help documentation is available at the Macromedia website, at the Macromedia Flash 8 product documentation site.

(b) End-‐users shall have access to a description of the accessibility and compatibility features of products in alternate formats or alternate methods upon request, at no additional charge.

Criteria fully met. Information on the accessibility and compatibility features of Macromedia products is available at the Macromedia Accessibility Center.

(c) Support services for products shall accommodate the communication needs of end-‐users with disabilities.

Criteria fully met.

Testing keyboard access in Flash and Flex Testing for keyboard access is probably the first test that should be performed when evaluating the accessibility of Flash and Flex content and applications. Many developers are not familiar with the ways



that users are able to interact with applications when using only the keyboard, so it is important that time is taken learn about how keyboard access should work.

For Windows, a useful resource is Microsoft’s Windows User Experience Guidelines, and in particular the section on controls (http://msdn.microsoft.com/library/en-‐us/dnwue/html/ch08c.asp). This document provides detailed information about keyboard access, and is worth reading. In Flex and Flash components, keyboard accessibility is designed into the components, but for developers creating new components or customizing controls it is crucial to keep the expected keyboard access requirements in mind.

A good starting point for testing keyboard access is the following basic test plan:

1. Put the mouse away. Turn it upside down, unplug it, whatever it takes to not use it.

2. Open the application or web page containing the Flash or Flex content.

3. Tab through the application without interacting with any controls. Make sure that you can follow the focus visually and that it follows an expected path. If you have difficulty locating the focus, this is a problem that needs to be addressed. Tools such as Inspect32 (http://www.microsoft.com/downloads/details.aspx?displaylang=en&familyid=3755582a-‐a707-‐460a-‐bf21-‐1373316e13f0) can be used to assist testers in locating the focus when it is hard to see – this is just to assist in development; don’t expect your users to use this tool.

4. Tab in reverse. Shift+tab is used to tab backwards through the tab order. Occasionally there are issues in tabbing that are made apparent by reverse tabbing.

5. Tab to specific controls and check the behavior of each. For example, if you tab to a ComboBox in a Flex 1.5 application make sure that the behavior of the ComboBox matches your expectations and the documentation for the ComboBox keyboard navigation at http://livedocs.macromedia.com/flex/15/flex_docs_en/00000232.htm.

6. The big challenge here is when you are using controls that you’ve made in a Flash movie (e.g. a simple tab navigator, made from scratch and possibly without much attention to proper keyboard support) or in a custom control for Flex — make sure that when you make or significantly modify a control that you determine what type of control it is and make it conform to expected keyboard conventions.

7. If the Flash content has specific keyboard shortcuts to perform functions, make sure that these don’t interfere with the keystrokes defined for specific controls. Most keystroke conflicts that I see occur when a screen reader is running, so that will be a necessary testing step for another phase of testing.

Tab order IS important The tab order is really, really important, because it not only affects the logical usage order of the application’s controls, but it also affects the reading order for assistive technologies. This means that



you need to set the tab order for everything that will be read unless your application is very simple and only has object in a single vertical or horizontal group.

Additional notes Primary tests we had in mind to pass was to help us figure out behaviors of different screen readers and text browsers that can be used in tandem with screen readers in case if screen reader itself does not have capabilities to navigate page/web application on generic browsers (Firefox, Internet Explorer, Opera, Camino, etc…) like it happened in case with Thunder.

Another moment we would like to point your attention to is that all browsers works differently with screen readers like JAWS. We found for instance that Microsoft Internet Explorer can perfectly communicate with JAWS and basically whole Flex application works just fine, form items are readable and audible, user can easy navigate through UI with almost no issues. However, we experienced some problems with Firefox browser even after special accessibility features as it recommended by Adobe. Unfortunately we can not report anything on Mac OS based browsers since we don’t have any Apple computers near around to test.



Flex Accessibility Guidelines

You create accessible content by using accessibility features included with Flex, by taking advantage of ActionScript designed to implement accessibility, and by following recommended design and development practices. The following list of recommended practices is not exhaustive, but suggests common issues to consider. Depending on your audience's needs, additional requirements may arise.

Visually impaired users For visually impaired users, keep in mind the following design recommendations:

• Design and implement a logical tab order for the tabs. • Design the document so that constant changes in content do not unnecessarily cause screen

readers to refresh. For example, you should group or hide looping elements. • Provide captions for narrative audio. Be aware of audio in your document that might interfere

with a user being able to listen to the screen reader. • Use percentage sizing so that your applications scale properly at smaller screen sizes. This allows

users of screen magnifiers to see more of your application at one time. Also take into account that many visually impaired users run applications with lower screen resolutions than other users.

• Ensure that foreground and background colors contrast sufficiently to make text readable for people with low vision.

• Ensure that controls don't depend on the use of a specific pointer device, such as a mouse or trackball.

• Ensure that components are accessible by keyboard. All Flex components defined as accessible include keyboard navigation. For a list of these components and the available keyboard commands for each, see Accessible components and containers.

Color blind users For color blind users, ensure that color is not the only means of conveying information.

Users with mobility impairment For users with mobility impairment, keep in mind the following design recommendations:

• Ensure that controls don't depend on the use of a specific pointer device. • Ensure that components are accessible by keyboard. All Flex components defined as accessible

include keyboard navigation. For a list of these components and the available keyboard commands for each, see Accessible components and containers.

Hearing-‐impaired users For hearing-‐impaired users, ensure that you add captions to audio content.

Users with cognitive impairment For users with cognitive impairments, such as dyslexia, keep in mind the following design recommendations:

• Ensure an uncluttered, easy-‐to-‐navigate design. • Provide graphical imagery that helps convey the purpose and message of the application. These

graphics should enhance, not replace, textual or audio content. • Provide more than one method to accomplish common tasks.



Reviewers Below you will find the list of reviewers participated in web application accessibility evaluation process:

Details Name Evgenios Skitsanos Affiliated Company Skitsanos Inc Contact Details Phone: +40-‐721-‐834664

Email: [email protected] Expertise Web Development, User Interface Prototyping,

User Interface design, Usability, Computer-‐Human Interaction

Natural Languages English



References

• Web Content Accessibility Guidelines 1.0 <http://www.w3.org/TR/WCAG10/>

• Checklist for Web Content Accessibility Guidelines 1.0 <http://www.w3.org/TR/WCAG10/full-‐checklist.html>

• Techniques for Web Content Accessibility Guidelines 1.0 <http://www.w3.org/TR/WCAG10-‐TECHS/>

• Evaluating Web Sites for Accessibility <http://www.w3.org/WAI/eval/>

• Evaluation, Repair, and Transformation Tools for Web Content Accessibility <http://www.w3.org/WAI/ER/existingtools.html>

• Selecting and Using Authoring Tools for Web Accessibility [draft] <http://www.w3.org/WAI/EO/Drafts/impl/software5.html>

• Review Teams for Evaluating Web Site Accessibility [draft] <http://www.w3.org/WAI/EO/Drafts/review/reviewteams.html>

• Adobe -‐ Section 508 Explained <http://www.adobe.com/macromedia/accessibility/508standards.html>

accessibility guidelines for flex, 2007

Documents

accessibility standards

accessibility features

accessibility requirements

accessibility policies

federal agencies

federal employees

federal agency

federal government