skip to content W3C SVG

1. Choosing Technologies

Choose technologies (e.g. HTML vs. Flash) with accessibility in mind

When choosing a document type or a user interface technology (e.g. HTML, Flash, Flex, PDF, mobile application), choose the most accessible technology that can accomplish project requirements.

Rationale

Some media types have a much higher potential for accessibility than others.

Even when two media types can each produce accessible results, choosing the most accessible technology will facilitate the process of making your product accessible.

HTML’s Potential

HTML and XHTML have the highest potential for accessibility of any document type available today.

HTML and XHTML provide access on multiple platforms and multiple browsers and work well with a wide variety of assistive technologies. (In this context, assistive technology is software and hardware that is used by people with disabilities to facilitate access to media.)

HTML accessibility has been studied and refined for over 14 years and users of assistive technologies are typically comfortable working with HTML and XHTML.

When coded with accessibility in mind, this media type gives users with disabilities:

  • A choice of device, operating system and browser
  • Access to all information presented
  • The ability to use all controls
  • The ability to skim the page for information without reading through the entire page
  • Access to detailed text alternatives for complex images and also the ability to choose when and if to read those detailed text alternatives

Added Benefits: HTML and XHTML are highly accessible because they are highly transformable and in widespread use. These qualities also make your content easy to reuse, to update and to transform for use with new technologies.

JavaScripts’s Potential

Including JavaScript in your HTML and XHTML media does not decrease the potential for accessibility. However, significant use of JavaScript introduces additional concerns that need to be addressed, primarily:

  • Notifying users who do not see the screen or who do not see the entire screen of changes to the screen
  • Making sure scripts work well when people use only a keyboard (no mouse) to navigate
  • Designing custom user interfaces components so that they work for users who experience the page after it has been transformed for their needs (e.g. transformed into an auditory form for people with visual impairment)
  • Rejecting inaccessible JavaScript libraries
  • Ensuring that changes to the screen are properly recognized by assistive technology.

While JavaScript’s association with (X)HTML gives it a high potential for accessibility, as with any programming language, user interface functionality written in JavaScript requires testing. This should include testing with:

This testing is easy to perform and provides experience with the types of user interfaces that we can expect for all users in emerging and future technologies.

Note: Unless otherwise indicated, when JavaScript is mentioned in this document, it means JavaScript that runs within HTML or XHTML pages on the client-side.

PDF’s Potential

Some PDF files are simply images of a document, without any real text, like a photo of a page in a book. While these files often allow users to zoom in on the document for easier reading, the documents are largely inaccessible to people with visual impairment.

However, since PDF Version 1.4, it has been possible create documents that are compatible with assistive technologies, like screen readers, by placing a structure of tags, very similar to HTML tags, behind a PDF document:
The tags panel presents a hierarchy of tags that describe the structure of a PDF document, including Sect, Title, Heading 1, P, and Figure.

As in HTML, it is possible even to make very detailed accommodations for accessibility, such as semantic mark up for complex data tables, including special attributes for telling screen readers exactly which data cells should be associated which header cells. When you use these tags and follow accessibility guidelines, PDF can be highly accessible with screen readers and can be keyboard accessible.

Abobe Reader offers an array of features for text resize, magnification, and adjusting text colors. These work well for simple clean documents, but not very well for complex documents with multiple columns and boxes of text. While in HTML, users can apply custom style sheets to separately customize the appearance of different types of items (headings, lists etc) this is not possible in PDF with Adobe Reader as of Version 10.1.

There are automated tools that help transform inaccessible PDF documents (even those that are just images of documents) into tagged PDF files. To fully take advantage of PDF's accessibility features, human review is required and most often PDF documents need post processing in Adobe Acrobat (version 6 or later). For complex documents with, for example, data tables, lists and links, this post-processing can be time-consuming.

If the document originates in another program, such as Microsoft Word, following best practices in that program (like using heading styles and lists properly) can:

  • Result in passably accessible documents in some simple cases
  • Reduce the amount of post-processing need in Acrobat

Screen Reader Compatibility

Screen reader compatibility is available on Mac (VoiceOver) and Windows (JAWS, NVDA, WindowEyes). Access to the tagging structure is not available when reading PDF on iOS. On Android, you need to download special players to even access the speech using TalkBack. But, iOS and Android accessibility is improving rapidly, so it this may improve soon.

Documentation for PDF accessibility

Flash and Flex’s Potential

Flash and Flex can be accessible, but it will not happen by accident, by checking “make movie accessible” in the Flash Authoring tool, or by including alternative text in an HTML embed tag. Like HTML, Flash / Flex accessibility requires specific detailed consideration during development.

Flash and Flex accessibility techniques are considerably less widely known among developers compared with HTML accessibility techniques. As such, accessible Flash is not likely to come from a vendor who does not have specific experience developing accessible Rich Internet Applications.

If you do want to work with a vendor who does not have accessibility experience, provide the following:

  • Detailed Requirements for Flash Accessibility
  • Accessibility Acceptance Testing (Make it clear upfront that you will not accept builds that don’t include accessibility features for the functionality that is present. All too often developers attempt to tack-on accessibility at the end of the project, which typically results in a poor level of accessibility or causes accessibility to be perpetually pushed to a later release. Flash accessibility is not a separate feature to be developed independently of other functionality. While it can often be added after the fact, that actually involves revisiting and adapting objects and functionality and takes longer than including accessibility upfront. Flash developers who know how to accomplish Flash Accessibility include accessibility during development. Leaving it for later increases cost, increases schedule time and is a good sign that the vendor does not quite know how to accomplish accessibility in Flash.)

The easier option is to use a vendor who has experience with Accessible Rich Internet Applications. The effort it takes to find and choose a vendor who has accessibility experience, is likely to pay off in other ways, as writing accessible Flash and Flex requires a professional understanding of Flash or Flex and often involves understanding, using, and even rewriting libraries.

It has been possible to create accessible Flash applications since Flash MX and the Flash Player 6; however, as implementing accessibility features targeted for the Flash Player 8+ has drastically reduced development time, these guidelines will provide techniques targeting Flash Player 8+.

Some effort has been made to support accessible Flash in Firefox and some online sources indicate that Flash is accessible in Firefox. However, as of March 2009, the support is not stable. So, currently, Flash accessibility for screen reader users requires Internet Explorer on Windows. Since this is the platform support by the screen readers that are used by the vast majority of screen reader users, JAWS and Window-Eyes, this is not as problematic as it may seem at first.

As with any programming language, user interface functionality written in ActionScript requires testing. This should include testing with:

This testing is easy to perform and provides experience with the types of user interfaces that we can expect for all users in emerging and future technologies.

Android Applications’s Potential

Android applications developed using Android 4.1 and later can be made accessible with the Android development framework. For more information on developing accessible Android applications see Android Accessibility API Guide.

With each new release of Android, new features to help users with disabilities are added. These features and settings can be found under the settings in the Accessibility option. Since the operating system can be changed by the device manufacture, some features may or may not be available on all devices. In Android Lollipop, the following features are available:

  • Talkback and Explore by Touch
  • Switch Access
  • Just Speak
  • Captions
  • Magnification Gestures
  • Large Text
  • High Contract Text
  • Accessibility Shortcut
  • Touch & Hold Delay
  • Color Inversion
  • Color Correction

While Android application programming interface supports accessibility, as with any programming language, user interface written for Android requires testing. This should include testing with:

  • Talkback and Explore by Touch
  • Screen magnification and text resize settings
  • Bluetooth keyboard, touch, and gestures

iOS Applications’s Potential

All iOS applications developed using iOS 3.0 and later can be made accessible with the UI Accessibility programming interface. For more information on developing accessible iOS applications see Accessibility Programming Guide for iOS.

With each new release of iOS, new features to help users with disabilities are added. These features and settings can be found under the General settings under Accessibility option. In iOS8, the following features are available:

  • VoiceOver screen reader
  • Zoom
  • Invert Colors
  • Greyscale
  • Speech
  • Larger Text
  • Bold Text
  • Button Shapes
  • Increase Contrast
  • Reduce Motion
  • On/Off Labels
  • LED flash for alerts
  • Subtitles & captions
  • Video descriptions
  • Guided Access
  • Switch Control
  • AssistiveTouch
  • Reachability
  • Accessibility Shortcut

While iOS application programming interface supports accessibility, as with any programming language, user interface written for iOS requires testing. This should include testing with:

  • VoiceOver Screen Reader
  • Screen magnification and text size settings
  • Bluetooth keyboard, touch, and gestures