2. Agenda Introduction Motivation for Accessibility Flex Accessibility API Building Custom accessible Components Best practices Testing Final word
3. Introduction Consultant for Adobe Professional Services Specialized in developing Rich Internet Applications Developing with Flex for 3 year Worked on a public facing RIA for a government organization Took interest in accessibility
4. Motivation for Accessibility Morale arguments Accessibility is the right thing to do 12.8 percent of adults (21-64) are disabled in some way Ensure equal access for individuals with disabilities Improves the application’s design by thinking upfront of accessibility constraints Also benefits the mainstream audience it is our duty to design and develop accessible websites as part of our work
14. Motivation for Accessibility – WCAG 2.0 About WCAG2 The W3C WAI released the WCAG 2.0 in December 2008 WCAG 2 follows the spirit of trying to bring anaccessible Web With WCAG 2, “Don’t use x” is no longer valid. It is now up to you, the developer, to work on the direct accessibility of your content, no matter what technology you choose WCAG 2 provides an opportunity for a common approach to web accessibility across countries
40. Do not design content in a way that is known to cause seizures
41.
42. About Accessibility in Flash Introduced with Flash 6 Previously limited to Flash and Flex but not supported in AIR Air 2 now supports Accessibility (built in Flex/Flash) Detailed documentation and Language Reference available Support for assistive technology through Microsoft Active Accessibility (MSAA) API
43. How MSAA works provides a descriptive and standardized way for applications and screen readers to communicate. Middleware architecture that conveys an object model of an application When Internet Explorer or Firefox loads a new page, it sends an event notification to the MSAA system Screen Readers are essentially MSAA clients listening for events
44. Accessible object model in Flash Player The Flash Player's accessible object tree consists of a single top-levelcontainer Contains a flat collection of the following types: Text Input TextField Buttons Simple Movie Clip Scripted Movie Clip
45. Enabling Accessibility for your Flex applications In Flash Builder 4 Select “Generate Accessible SWF file” in the Project properties dialog Modfifies the compiler node : <compiler additionalCompilerArguments="-locale en_US" generateAccessible="true"> in the .actionScriptProperties file This is now selected by default in Flash Builder 4 At Runtime Append accessible=true to the URL http://www.mydomain.com/index.html?accessible=true Using the command line compiler Use the Accessible option with MXMLC mxlmc –accessible MyApplication.mxml
47. Flex Accessible components and containers Adobe built support for accessibility into Flex MX components and containers Accessible components : 28 for Halo - 19 for Spark ButtonBar DropDownList NumericStepper RichEditableText Spinner TabBar ToggleButton VideoPlayer Accordion AdvancedDataGrid Alert Button CheckBox ColorPicker ComboBox DataGrid DateChooser DateField Form Image Label LinkButton List Menu MenuBar Panel RadioButton RadioButtonGroup Slider TabNavigator Text TextArea TextInput TitleWindow ToolTipManager Tree
48.
49. ForceSimple: If true, causes Flash Player to exclude child objects within this display object from the accessible presentation.
51. Silent: If true, excludes this display object from accessible presentation.
52.
53. Accessibility API Instanciating the flash.accessiblity.AccessibilityProperties class In MXML <?xml version="1.0" encoding="utf-8"?> <s:Applicationxmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:s="library://ns.adobe.com/flex/spark" xmlns:mx="library://ns.adobe.com/flex/mx"> <s:TextArea id="accessibleTxt" accessibilityName="Spark Accessible Text" accessibilityEnabled="true" accessibilityDescription="A short description" /> </s:Application>
54. Accessibility API The flash.accessibility.Accessibility class provides the following methods and properties: active : Indicates whether a screen reader is currently active and the player is communicating with it. updateProperties():Tells Flash Player to apply any accessibility changes made by using the DisplayObject.accessibilityProperties property. sendEvent: Sends an event to the Microsoft Active Accessibility API. What happens when your OS doesn’t have an active screen reader? Calling updateProperties() will throw an IllegalOperatorErrorexception Use flash.system.Capabilities.hasAccessibilityto detected if the system supports Accessibility And the active property to prevent a call to updateProperties() privatefunctionupdateProperties():void { if (Accessibility.active) { Accessibility.updateProperties(); } }
55. The flash.accessibility.AccessibilityImplementation class Flash provides the flash.accessibility.AccessibilityImplementation class for exposing accessible components subset of the IAccessible interface, adapted slightly for ease of use. The Flash Player IAccessible interfacepasses most calls from MSAA to thesubclass instance for that component Flex components with Accessibility will be treated as scripted movie clips In Flex, this class is extended by mx.accessibility.AccImpl
56.
57. Building Custom Accessible Components Developers need to be able to provide their own accessibility implementations for custom component You create a new accessibility implementation by extending mx.accessibility.AccImpl for each new component Consider two primary forms of guidance: MSAA documentation has guidelines for objects based on the component type Look at a similar component in an HTML page Make sure you implement keyboard navigation and focus management Go for the easy path and extend accessible components if possible
58. Building Custom Accessible Components Let’s start with an example : Contextual help component You will need to create your implementation class by extending AccImpl The AccConst class provides all the MSSA constants you need. You will have to override some of the methods from the IAccessible interface
59. Building Custom Accessible Components Let’s first create our visual component – the HelpButton class Defining a custom accessibility implementation for a component requires changes the component class file First thing to do – add the AccessibilityClassmetatada tag to let the compiler know which AccessibilityImplementation to use [AccessibilityClass(implementation=”component.HelpButtonAccImpl")] Add a placeholder for the mix-in function mx_internal static var createAccessibilityImplementation:Function; This createAccessibilityImplementation() method will be assigned by the PopUpButtonAccImpl accessibility implementation class we'll create Override the UIComponent.initializeAccessibility() method with the following to initialize the AccessibilityImplementation for a given component instance at runtime. overrideprotectedfunctioninitializeAccessibility():void { if (HelpButton.createAccessibilityImplementation != null) { HelpButton.createAccessibilityImplementation( this ); } }
60. Creating the accessibility implementation Creating the HelpButtonAccImpl which is a subclass of mx.accessibility.AccImpl Constructor We set the appropriate role for the component based on the MSAA constants publicfunctionHelpButtonAccImpl(master:UIComponent) { super( master ); role = AccConst.ROLE_SYSTEM_PUSHBUTTON; }
61. Creating the accessibility implementation Initializing Accessibility for the host component Initializes the creatAccessibilityImplementation property we declared on the host component Creating a new acessibiliyImplementation for each instances of the host component mx_internalstaticfunctioncreateAccessibilityImplementation ( component:UIComponent):void { component.accessibilityImplementation = new HelpButtonAccImpl(component); } publicstaticfunctionenableAccessibility():void { HelpButton.createAccessibilityImplementation = createAccessibilityImplementation; }
62. Creating the accessibility implementation Managing events that will an assistive technology will need to react to Overriding the eventToHandle methods Overriding the EventHandler method to manage these events overrideprotectedfunctiongeteventsToHandle():Array { returnsuper.eventsToHandle.concat([ Event.Change]); } overrideprotectedfunctioneventHandler(event:Event):void { super.eventHandler( event ); switch (event.type) { caseEvent.CHANGE: Accessibility.sendEvent(master, 0, AccConst.EVENT_OBJECT_STATECHANGE); Accessibility.sendEvent(master, 0, AccConst.EVENT_OBJECT_NAMECHANGE); Accessibility.sendEvent(master, 0, AccConst.EVENT_OBJECT_SHOW); Accessibility.sendEvent(master, 0, AccConst.EVENT_OBJECT_FOCUS); Accessibility.updateProperties(); break; } }
63. Creating the accessibility implementation We now need to override methods from the IAccessible interface Overriding the EventHandler method to manage these events overrideprotectedfunctiongetName(childID:uint):String { varlabel:String = helpButton.label; label = ( label != null && label != "" ) ? label : ""; if( helpButton.selected ) { label = label + ". " + helpButton.helpText; } return label; } overridepublicfunctionget_accName(childID:uint):String { varaccName:String = AccImpl.getFormName(master); accName += getName(childID) + getStatusName(); return (accName != null && accName != "") ? accName : null; }
64. Creating the accessibility implementation We now need to override methods from the IAccessible interface overridepublicfunctionget_accDefaultAction(childID:uint):String { return"Press"; } */ overridepublicfunctionget_accState(childID:uint):uint { varaccState:uint = getState(childID); if (HelpButton(master).selected) accState |= AccConst.STATE_SYSTEM_PRESSED; returnaccState; }
66. Best Practices – Reading order Reading order must match the content of the application Default order is Left-Right/Top-Bottom Possible to override but not straightforward : Tab order is flat Doesn’t provide hierarchy If overridden the tab index must be specified to ALL component in the application Allocate slots for each part of your application.
67. Best Practices – Reading order Controlling the reading order in MXML <mx:Form label="login"> <mx:FormItem label="Username"> <mx:TextInputtabIndex="1"/> </mx:FormItem> <mx:FormItemlabel="Password"> <mx:TextInputtabIndex="2"/> </mx:FormItem> <mx:HBox> <mx:Buttonlabel="Reset" tabIndex="3"/> <mx:Buttonlabel="Login" tabIndex="4"/> </mx:HBox> </mx:Form>
68. Best Practices – Global navigation Extremely different from an HTML Page What happens when you navigate ( Changing state or switching content )? By default : nothing! Example : Login screen to dashboard screen Notify the user that a change occurred Explain briefly the new content and the purpose of the screen Set the focus on a relevant component Consider non-mouse driven navigation Everything should be accessible using the keyboard Make sure your navigation components have simple and explicit names Provide auto-scroll when focusing a component
69. Best Practices – Pop Ups What happens by default : again, nothing Correct behavior : Read the title followed by the content of the pop up Set the focus on the default button ( e.g. cancel or ok) Disable the background : the rest of the application is hidden to the screen reader Use a default key to close pop ups (commonly the ESC key)
70. Best Practices - Forms Use Form and FormItem for user input Provide out of the box accessibility features Mandatory Field Validation Set focus on the first input field when entering a form Make sure the user can enter “Form mode” with his screen reader What happens when the validation fails? Focus on the first error Explicitly warn the user that the form is invalid If possible specify the number of errors
71. Best Practices – Adjustable Interface / High contrast Provide resizable text Screen magnification A High constrast version Alternative css Save user preferences
73. Best Practices – Context ad relationship Provide context and relationship : Applications that assume comprehension of visual relationships require extra attention ( i.e hierarchical data) Explicitly add context to links/buttons whenever possible (e.g. :Edit --> Edit your profile) Otherwise use tooltips or description to give more information.
74. Best Practices – visual content Consider users with visual acuity limitations : Don’t rely on colors/images to convey information Provide caption to any images Disable animations Provide instructions: Non-obvious functionality needs to be revealed for users
76. Testing Accessibility MSAA Inspector Tools: Quick tool for identifying role and state info Much faster to test a component Screen reader : Jaws Navigation (test with your keyboard ) : Tabbing through controls is a good start Make sure to shift+tab backwards Try to turn off your monitor and use the application Perform user testing
77. Final word Accessibility is not an easy task Allocate enough time on the project Keep accessibility in mind during all phases ( starting with the design phase) Involve users as soon as possible : Regular users of assistive technologies will provide the most accurate information An accessible application is not necessarily usable – allow time for user testing User expectations are a possible issue Don’t put accessibility on a TODO at the end of the project
The state of legal requirements and protections concerning the accessibility of websites is far from uniform. Many countries have some form of web accessibility laws in place, but the extent of those laws is radically variable. Furthermore, as many websites serve multiple countries, the question of jurisdiction can become a tricky aspect of accessibility law.It's well beyond the scope of this presentation to discuss the exact limits of web accessibility law around the globe, but I do aim to discuss the ramifications and philosophies of these laws for your web-based business.
Web Content Accessibility Guidelines (WCAG) 2.0 covers a wide range of recommendations for making Web content more accessible. Following these guidelines will make content accessible to a wider range of people with disabilities, including blindness and low vision, deafness and hearing loss…. Following these guidelines will also often make your Web content more usable to users in general. WCAG 2.0 success criteria are written as testable statements that are not technology-specific
For each guideline, there are testable success criteria, which are at three levels: A, AA, and AAA.
The screen reader sends a special window message (WM_GETOBJECT) to the browser, asking for its root object.The browser responds by sending back a pointer to a COM interface of type IAccessible. This interface has methods that allow the screen reader to ask for object properties, such as type, name, description, value, and visibility.IAccessible also has methods for traversing the object tree in various ways—abstractly, in terms of tab order, in terms of geometric relationship, or in terms of pixel locations. Finally, IAccessible allows clients to manipulate UI objects programmatically, pressing buttons and altering selection and focus. The screen reader now traverses the tree of IAccessible objects, building up a tree of COM pointers.For each object discovered, the screen reader determines the type of object (is it a container? button? textfield? and so on), the object's name, and possibly a few other properties. The screen reader now has enough information to construct its narrative text and feed it into the text-to-speech engine.The browser, in order to be a proper MSAA server, has two main responsibilities. It must implement the IAccessible interface for every significant onscreen object that it displays, and it must notify the MSAA system whenever any part of the object tree changes. The Flash Player handles these two responsibilities for Flash content.
Text: Regions of dynamic or static text in the movie. The principal property of a text object is its name, which, in keeping with MSAA convention, is equal to the contents of the text string being displayed. A text object may also have an associated description string. The Flash Player also makes an attempt to deduce labeling relationships between text and input text fields (text immediately above or to the left of an input text field is be taken as a label for that field), and between text and buttons (text entirely inside a button will be taken as a label for that button). Any text that is deduced to be a label will be omitted from the accessible object tree, and the content of that text will be used as the name of the object that it labels. Labels are never assigned to buttons or text fields that have author-supplied names.Buttons:A button object has a state (pressed or not pressed), The child objects inside buttons are note normally looked at by the player for accessibility purposes—buttons are "leaves" in the accessible object treeSimple movie clips: All non-scripted movie clips at all levels are classified into one of two categories: simple or non-simple. A movie clip is simple if it does not have any other accessible objects (text, input text, buttons, or components) as children at any level of depth. Non-simple clips are not given any representation in the object tree; instead, their accessible-object contents are promoted into the flat top-level list of accessible objects. Simple clips, on the other hand, do show up in the object tree, expressed to MSAA as an image or animation widgetScripted movie clips: Flex (and Flash Professional) UI components present a special problem for the accessible object model in Flash Player. They are movie clips or sprites built from collections of text, input text, shapes, and buttons, but if Flash Player exposed those individual objects to MSAA, the meaning of the overall component would be lost. For this reason, a Flex UI (or Flash Professional) component may require a custom accessibility implementation. A movie clip or sprite that provides its own accessibility implementation is called a scripted movie clip, and it appears in the accessible object tree. The details of the accessibility implementation depend on the kind of component being implemented and are up to the component developer.
To accelerate building accessible applications, Adobe built support for accessibility into Flex MX components and containers. These components and containers automate many of the most common accessibility practices related to labeling, keyboard access, and testing. They also help ensure a consistent user experience across rich Internet applications.
The name property of these objects is the most important property to specify because accessibility aids provide the names of objects to users as a basic means of navigation. Do not confuse AccessibilityProperties.name with DisplayObject.name; these are separate and unrelated. The AccessibilityProperties.name property is a name that is read aloud by the accessibility aids, whereas DisplayObject.name is essentially a variable name visible only to ActionScript code.
Note that Accessibility.updateProperties() is a fairly expensive method and should only we called once for a collection of updates occurring at the same time.SendEvent : Microsoft Active Accessibility handles that event and sends the event to any active screen reader application, which in turn reports the change to the user
The methods of the flash.accessibility.AccessibilityImplementation class are a subset of the IAccessible interface, adapted slightly for ease of use.It class provides a set of methods that allow a component developer to make information about system roles, object based events, and states available to assistive technology. The Flash Player IAccessible interface for a scripted movie clip simply passes most calls from MSAA through to the flash.accessibility.AccessibilityImplementation subclass instance for that component.For example, when a screen reader needs to determine the default action of a mx.controls.Button component instance on the Stage in Flash Player, it calls the IAccessible method get_accDefaultAction() on the IAccessible interface exposed by the Flash Player for that component instance. The request is passed through to the get_accDefaultAction() method of the mx.accessibility.ButtonAccImpl accessibility implementation class instance, which returns the appropriate default action String for a button control, which is “Press.”
Flash Player provides the flash.accessibility.AccessibilityImplementation class as a base class for creating custom accessibility implementations for Flex and Flash UI components in ActionScript 3.In Flex, this class is extended by mx.accessibility.AccImpl which serves as the base class for accessibility implementations in Flex components. You create a new accessibility implementation by extending mx.accessibility.AccImpl for each new component. The methods of the flash.accessibility.AccessibilityImplementation class are a subset of the IAccessible interface, adapted slightly to make life easier. The Flash Player's IAccessible interface for a scripted movie clip passes most calls from MSAA through to the flash.accessibility.AccessibilityImplementation subclass instance for that component. Accessibility implementations must also send event notifications to MSAA in a variety of situations. Event notifications are sent by using the flash.accessibility.Accessibility.sendEvent() method.
Flex component developers need to be able to provide their own accessibility implementations for custom components. The way in which an accessibility implementation implements the IAccessible interface and the events that it sends depend on the kind of component being implemented.Consider two primary forms of guidance: First, the MSAA documentation has a list of guidelines for accessible object implementations according to component type. Second, an accessibility implementations's behavior should match as closely as possible the behavior exhibited by the equivalent form element (if any such element exists) in an HTML page inside Internet Explorer or Firefox or in the Windows operating system. This behavior can be examined using the AccExplorer, Inspect32, and AccEvent tools, available in the Microsoft Active Accessibility 2.0 SDK. Collectively, these two forms of guidance constitute an MSAA model for IAccessible implementations. This model is loosely specified. The only definitive test of an IAccessible implementation is to test it with the latest versions of screen readers.
The initializeAccessibility() method is invoked by the UIComponent.initialize() method to initialize accessibility for a component instance at runtime.
The createAccessibilityImplementation() method is called by the initializeAccessibility() method for the UIComponent subclass when the component initializes.All AccImpl subclasses must implement this method.The enableAccessibility() method is required for the compiler to activate the accessibility classes for a component.
Update the eventHandler() method to handle any events to which the PopUpButtonAccImpl should listen from its master component. ".The eventHandler() method handles events from the master component and sends the appropriate object or system event to MSAA using the flash.accessibility.Accessibility.sendEvent() method. Depending on the object or system event it receives, the MSAA system will call the IAccessible method to retrieve the appropriate value from the object that sent the event.
