As conscientious developers we try to ensure that our applications are streamlined, self explanatory, and easy to use. We work hard to make sure they look good and lend themselves well to a given workflow, but often forget that not everyone experiences our work in the same way.
From dyslexia and color blindness to full visual impairment and mobility issues, a percentage of the population face obstacles that can make using an application difficult or even impossible. Fortunately, as Flex developers we have great support built into our chosen platform for various accessibility solutions, and can tailor our applications in several ways to make sure they work for all users.
At end end of the article you’ll find a quiz, sponsored by Adobe. Test yourself and see how well you do.
Accessibility is the ability of an object to be used by anyone, regardless of a person’s incapacities. For an application to be accessible, web developers employ techniques and design concepts that enable users with any kind of impairment to navigate web pages and use software. It may involve altering the component structure, adding text to allow better interaction with screen readers, picking a color set with contrast and colour blindness in mind, or enabling full keyboard access to everything on the screen. The core idea is that your website or application is usable by those who are partially or fully blind, or who have trouble discerning one colour from another, or for whom mobility is restricted and so mouse use or gestures are difficult.
Many people think of wheelchairs when they think of disabilities, but in software terms this is not necessarily a barrier; most people confined to a wheelchair can operate computer software without any difficulty.
We use the sometimes controversial term “disability” here merely as a catch-all to describe various physical and mental states, visual or auditory impairments, or other conditions. This is in no way an attempt to describe people with any kind of impairment as disabled; rather, it’s simply a term of reference that is understood by all.
The disabilities that are most likely to affect your users fall into four major categories and present their own challenges for developers (this list is not comprehensive, scientific, or definitive; it’s just to give you a starting place):
- Visual Impairment
Visual impairment includes tunnel vision, color blindness, and, of course, being legally blind. Visually impaired users are often the most affected when it comes to accessibility issues, since everything done on a computer is to some extent visual. These users rely heavily on the keyboard for input and control, and tend to avoid using a mouse. A screen magnifier or screen reader provides a lot of assistance, as do audio events and cues. Some use a Braille display to “read” the text on screen with their fingertips.
- Dyslexia
Dyslexic users are likely to have great difficulty reading a web page or dealing with large amounts of textual controls. In some cases this can extend to difficulty with data entry too, such as using a search function. Strategies such as logical page or screen structure can help, as well as developers adopting design philosophies that make an application as self-explanatory as possible. Dyslexic users may also use screen readers to aid with their comprehension.
- Motor Disabilities
Motor disabilities can range from hand or arm tremors, a loss of limbs, or a lack of control and movement of body parts. In these cases input devices need to be considered, bearing in mind that users may be entirely unable to operate a mouse. Even if the user is unable to type, other assistive technologies exist to help them. Full keyboard navigation and control is essential for these users.
- Cognitive Disabilities
This group is probably the farthest reaching. Disabilities may include faculty impairment such as memory recall, comprehension, and interpretation. In some cases these can be temporary situations; in others they’re permanent—and there’s no easy solution to cater for them all. This group is best served by a combination of techniques used for the other three groups, tied to an overall design philosophy aware that more and more people on the Web are not geeks or programmers, and so approach software differently from the way we expect.
- Other Requirements
For some users the solution may be as simple as ensuring that your application provides font scaling. Even if a user doesn’t consider themselves visually impaired, they may be marginally short-sighted or spend too much time looking at a screen, so being able to enlarge screen fonts can make life a great deal easier. I am a full-time software developer and writer, yet I have visual acuity problems, which makes me always appreciate being able to up the font size in an application; technically, I might fall into the visual impairment category myself.
There are many reasons to make the effort to build accessible software, which we’ll cover here:
- Economics
Whether you’re running a software business that makes money from selling licenses, or heading up a project to bring a new application or workflow into an organization, you benefit from more people using the software. Statistics on computer users with a disability are difficult to come by, but the organization Blind Citizens Australia lists statistics from 2004-2005, revealing in excess of 480,000 vision-impaired people and over 50,000 fully blind. A study by the Fred Hollows Foundation mentions a World Health Organization estimate of more than 75 million people blind or vision-impaired in the world by the year 2020.
That’s a lot of potential users, and this is only one part of our accessibility target audience. The Disabled World community website estimates that around 10 percent of the total world’s population, or roughly 650 million people, live with some kind of disability.
- Legislation
In many countries, there’s anti-discrimination legislation in place that requires web sites and applications to include at least some level of accessibility. Even stricter rules may apply in government and education sectors. The enforcement level of these acts varies wildly, but there’s always the chance of losing revenue, or being fined and forced to redevelop if you fail to meet the requirements. Be sure to check the legislation governing the nations and business sectors you’re working in. This is especially important where the software is a requirement for gaining access to any kind of government or education service or support.
- Technical
Everyone knows that Google and other web spiders are important tools for promoting and selling software and web sites, but what you may not realise is that standard accessibility practices also can aid the spiders in indexing your pages. If you think about it, a spidering engine is essentially a blind user, reading only the text and code in your site. This is important if you’re setting up a deep-linking structure or text alternatives, and as more engines are beginning to look at spidering SWF files themselves, these techniques become even more relevant.
- Doing the right thing
Altruism isn’t always measurable, but you can be assured that going to the effort of making your software accessible will make a lot of people happy; even those for whom accessibility is not a key issue will remember your efforts. If pure altruism isn’t enough, remember that happy and impressed customers refer others!
Flex provides us with a number of technical solutions for accessibility. Let’s explore some tricks and techniques you can adopt to make your applications cater for as many users as possible.
Flex 3 applications are not accessible by default so you need to enable accessibility yourself (look out for the Flex 4 beta, though, because it now looks to be including accessibility by default). Doing so will add about 8KB to your SWF file, and there are four ways to make this happen.
To enable accessibility automatically for all Flex applications, you can modify your flex-config.xml file simply by setting the accessible tag to true, like so:
<mxml-compiler> … <accessible>true</accessible> …</mxml-compiler>
You can enable accessibility on a “per project” basis in Flex Builder by selecting the Generate accessible SWF file option in the Compiler options section of the project Properties dialog box shown in Figure 1, “Generate accessible SWF file”.
To enable accessibility when you’re using the command-line compiler, you can add a configuration variable -compiler.accessible or just -accessible during compilation, like so:
mxmlc -compiler.accessible /myapp/app.mxml
or
mcml -accessible /myapp/app.mxml
Either of these methods will alter the .actionScriptProperties file in the project directory to add a compiler argument like so:
<compiler additionalCompilerArguments=”-locale en_US” generateAccessible=”true”>
If your application is compiled at runtime and isn’t set for accessibility by default, you can enable it on the fly by appending a query parameter to the URL like this:
http://www.example.com/myapp/app.mxml?accessible=true
There are 28 accessible components included in the Flex 3 SDK. For a full list of them and the accessibility enhancements they provide, check the Adobe Accessible components and containers list document. If you want to make your RIA accessible, you need to build as much as possible with fully accessible components. If you’re constructing new components, you’ll need to add accessibility support, or at least subclass an accessible component from the SDK. This excerpt is from the Adobe Accessibility Best Practices document:
For a component to be accessible, it must expose role and state information according to the Microsoft Active Accessibility (MSAA) specification. Developers planning to develop their own components should plan to research and implement MSAA from the beginning to help ensure the consistent behavior of Flex components with other controls at the operating system level. Once MSAA support has been added to a control, it is important to validate that the component works with assistive technology, such as the JAWS screen reader. Screen readers rarely implement the entire MSAA spec, particularly inside of the browser, as web applications typically rely only on the 12 base controls that are included in the HTML specification. Some degree of coordination with screen reader vendors may be required if a custom-built component deviates from the approach used in the default Flex component set or a new control type is introduced.
Screen readers are applications that visually-impaired users employ to assist them in navigating websites and applications. These applications read out text and navigation items using a synthesized voice. To truly understand the experience you need to install a reader such as JAWS, and attempt to navigate your application with your monitor turned off. If you’ve never done this before, I highly recommend it for an amazing insight into the difficulties some users face.
JAWS is the standard among screen readers, so it’s a good one to test against. It’s Windows-only software though, so if you’re on a Mac or Linux machine you’ll need some virtualization or dual booting set up. We’ll refer to JAWS throughout the rest of the article when referring to screen readers.
When coding for screen readers, the two most important aspects are alternative text content and reading order. As its name suggests, the reading order dictates the order in which JAWS will read aloud the contents of the screen. For a very simple application this may not be an issue, but with any kind of complex or non-standard layout, the default reading order is likely to be very confusing to a JAWS user. This affects everything from navigation to data entry; for example, if your reading order is incorrect, a user may be read the wrong form field label by JAWS, and attempt to enter the wrong data in the field they’re currently focused on. For this reason you should always run your application through JAWS to gain an idea of how it reads.
The most important point is to keep your interface simple and uncluttered, using accessible components like the accordion and tab navigator. After this, you need to assign a tabIndex value to every object in your interface, including text fields and nonfocusable interface controls.
If you miss even one tab Index, the entire lot will be ignored and Flex will revert to its default reading order!
You can also choose to add instructions in various places that the screen reader can read aloud to the user. It can be helpful to include a description by entering text in the description property for the application, or the properties of the overall containers. Bear in mind though that these instructions will be read each time the user refreshes or moves to the top of an application, so if they’re too long they’ll become cumbersome. From the Adobe best practices document, here’s an example included in the Blog Reader demo application:
function accessibleInit() { var desc = createObject("TextInput","desc",0); desc.x = 0; desc.y = 0; desc.width = 0; desc.height = 0; desc.accessibilityProperties = new AccessibilityProperties(); desc.accessibilityProperties.description= 'Access instructions. The Flex Blog Reader reads entries from different Blogs on the Web. To interact with this application, turn forms mode on after entering the application.';} The function is then called from the application tag:
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" creationComplete="accessibleInit();” pageTitle="Flex BlogReader">…You may need to add a completely separate screen for instructions, providing a button or link to view them. It’s a good idea to have this button or link be the first detail the screen reader reads, so that the user knows they can easily get help.
All controls should have tooltips containing their name and, if required, a brief statement of how they can be used. Remember that tooltips will be read out by the screen reader, so if there’s information a user needs to know about a control, put it in the tooltip. The title and description of any images should also be available in a tooltip. Make sure that if you use icon buttons in your application, they have tooltips describing their function (this is good practice in any case). If you want to add extra information to an image, you can deposit the text in the accessibilityProperties property. Here’s an another example from the Adobe documentation:
<mx:Image width="60" height="56" source="assets/icecreampint.jpg" toolTip="Ice Cream Pint" creationComplete="event.target.accessibilityProperties = new AccessibilityProperties(); event.target.accessibilityProperties.description = 'Our fine Ice Cream Pint provides the perfect serving dish for your homemade ice cream treats'"/>
When video and audio content are included it’s helpful to have a synchronized text equivalent in the form of captions. You can set this up yourself, but there are some great tools like Hi-Caption Studio from HiSoftware and MAGpie from the National Center for Accessible Media. These create a special XML file with caption data set up specifically for Flash, and can be combined with Captionate to deliver captions connected to cue points in the video. Obviously you’ll need to add a display element to your video player to show the captions where necessary.
Font scaling should always be included in an accessible application. Give the user the ability to increase the font by choosing a scale from a select box or using a keyboard shortcut. Try to avoid the use of any particularly exotic fonts, and any nondefault fonts that are used should be embedded.
Keep color in mind, as those who are color blind can have difficulty picking up the visual cues you take for granted. Never make color the sole means of providing information. For example, bars in a graph should have alternate text, or an outline or border can help. Colored buttons need to have tooltips; remember a color-blind user may be unable to tell the difference between a green and red button. When adding instructions, make sure you include alternative descriptions for your controls; for example, “Click the red button on the right.” In the case of links it can be useful to include an underline, as well as making the link a different color, so if the user can’t make out the color difference, they’ll still be able to recognize the link.
Contrast is also important for readability. Focus highlights, backgrounds, and element changes due to mouseover events need to provide a strong enough contrast to be picked up by those with vision impairments. If you’re using extremely subtle changes of shade in your background or containers to help delineate text or form segments, for example, it may not be visible to many users.
Many users do not or can’t use the mouse, so it’s important to ensure that your application can be controlled via the keyboard. The accessible components in Flex already help with keyboard access, and you can enable the same in your own components without too much work. The key to this is making the mouse events available via the keyboard. A simple method is to add a new listener on a control and have it call the same function of a mouse click. Remember, a keyboard user will be tabbing their way through the controls on the screen, so ensure that (for example) hitting enter on a control will achieve the same result as clicking it with a mouse.
A second consideration is that even when a user can use the keyboard, it may still be difficult for them. Keyboard shortcuts can help in this situation; for example, mapping a key to load the help for whatever screen or section the user is focused on, and adding navigation controls mapped to keys. If you like you can create a global keyboard listener for keyboard shortcuts, and have it intercept certain keys or combinations and operate on them independently.
There are many technical challenges in developing accessible applications, but the best advice I can give is to adjust your design philosophy to take accessibility into account from the beginning. It’s much easier to develop accessibility from the beginning than try to shoehorn it into an application at the end of development.
When developing, strive for best practices like minimal container nesting; this will make screen reader adjustments easier. Think about using your application from the point of view of an impaired user; this not only helps support accessibility, but ultimately makes your software more usable for everyone. Test your application in black and white, and then with the monitor off while running JAWS and see how well it performs.
Another common and helpful path is to provide text alternatives to your pages or application. This isn’t always a suitable solution, especially for enterprise software, but in the case of smaller applications or areas where users are looking up text, deep linking and even full text alternatives to the Flex version can be very useful. Various methods are available to attempt to detect the use of screen readers, but at the moment they can be a bit hit-and-miss. Check out the useful blog post by Steve Faulkner on the subject.
Of course not all software can be made accessible; if it’s a highly visual game, like a first-person shooter or a CAD application, some kinds of disabilities will exclude users, but there’s nothing we can do there. Even in these cases there are tweaks we can do to make life easier for those who can use the software but might benefit from a little help. Ultimately, developing with accessibility in mind makes your application better all round, and expands your audience hugely.
In addition to what we’ve looked at here, there are many websites dedicated to accessibility in one form or another, and some offer great advice. There are even online services and organizations that will examine a site or application for you to test its accessibility; furthermore, when you’re developing to comply with accessibility legislation it can be helpful to have an expert look your software over. If you’re going to pay a company to make your software accessible, ensure they know what they’re doing and are providing options for various screen readers, as well as all the aspects mentioned above. Here’s a brief list of sites you may find useful:
You can also read more about Flex accessibility here:
Adobe Flex 3 livedocs
How well do you think you’ll do on our Quiz? Test yourself and find out!
Frequently Asked Questions (FAQs) about Accessibility in Flex Apps
What is the importance of accessibility in Flex applications?
Accessibility in Flex applications is crucial as it ensures that all users, including those with disabilities, can use the applications effectively. It involves designing and developing applications in a way that they can be accessed, understood, and used by everyone, regardless of their physical or cognitive abilities. This includes providing alternative text for images, ensuring color contrast for visibility, and making the application keyboard-friendly. By making your Flex applications accessible, you not only cater to a wider audience but also improve the overall user experience.
How can I make my Flex application more accessible?
There are several ways to make your Flex application more accessible. Firstly, ensure that all interactive elements can be accessed using the keyboard. Secondly, provide alternative text for non-text content such as images and videos. Thirdly, use ARIA roles and properties to provide additional information about elements and their state. Lastly, ensure that color contrast is sufficient for users with visual impairments. Regular testing with assistive technologies like screen readers can also help identify and fix accessibility issues.
What are ARIA roles and properties in Flex applications?
ARIA (Accessible Rich Internet Applications) roles and properties are used in Flex applications to provide additional information about elements and their state. They help assistive technologies understand the content and functionality of elements, making the application more accessible to users with disabilities. For example, an ARIA role can indicate whether a button is pressed or not, while an ARIA property can provide a description for an element.
How can I test the accessibility of my Flex application?
You can test the accessibility of your Flex application using various tools and techniques. Automated testing tools like aXe and Lighthouse can help identify common accessibility issues. Manual testing with assistive technologies like screen readers can provide insights into the user experience of people with disabilities. Additionally, you can conduct usability testing with users with disabilities to get direct feedback on the accessibility of your application.
What are the benefits of making my Flex application accessible?
Making your Flex application accessible has several benefits. Firstly, it increases the potential user base of your application by making it usable by people with disabilities. Secondly, it improves the overall user experience by making the application easier to use and understand. Thirdly, it can enhance your brand image by showing your commitment to inclusivity and equality. Lastly, it can help meet legal requirements related to accessibility.
What are the common accessibility issues in Flex applications?
Common accessibility issues in Flex applications include lack of keyboard accessibility, insufficient color contrast, missing alternative text for non-text content, and lack of ARIA roles and properties. These issues can make it difficult for users with disabilities to use the application, leading to a poor user experience.
How can I ensure keyboard accessibility in my Flex application?
To ensure keyboard accessibility in your Flex application, make sure that all interactive elements can be accessed and operated using the keyboard. This includes buttons, links, form fields, and other controls. Also, provide visual focus indicators to help users know where they are on the page. Lastly, ensure that the tab order is logical and intuitive, following the visual flow of the page.
How can I provide alternative text for non-text content in my Flex application?
To provide alternative text for non-text content in your Flex application, use the alt attribute for images and the title attribute for other non-text elements. The alternative text should describe the content or function of the element in a concise and meaningful way. For complex non-text content like charts and diagrams, consider providing a longer description in the surrounding text or a separate link.
How can I ensure sufficient color contrast in my Flex application?
To ensure sufficient color contrast in your Flex application, use a color contrast checker tool to verify that the contrast ratio between the text and background colors meets the recommended standards. Avoid using color alone to convey information, and provide alternative cues for users with color vision deficiencies. Also, ensure that interactive elements have a distinct visual style that remains visible even in high contrast mode.
What are some best practices for accessibility in Flex applications?
Some best practices for accessibility in Flex applications include designing for keyboard accessibility, providing alternative text for non-text content, using ARIA roles and properties, ensuring sufficient color contrast, and testing regularly for accessibility. Additionally, consider accessibility from the start of the design and development process, and involve users with disabilities in usability testing to get direct feedback on the accessibility of your application.
Toby TremayneA writer and software developer of more than 14 years experience, Toby is passionate about helping new and small businesses make the most of the internet and cloud technology. When he's not writing or telling stories he's busy trying to make technology easier to use for the average business person, and can often be found in dark corners practicing magic tricks or lock sport.
