Avoka Blog: Adobe LiveCycle

April 29, 2009

PDF and Flex Accessibility – part 1

Filed under: 1, Designing Forms, LiveCycle — Tags: , — pcopeland @ 7:57 am

The bottom line

Despite some misconceptions, PDF and Flex/Flash solutions can be highly accessible. However, it does not happen automagically. Project commitment is required to attain the desired level of accessibility. It is advocated that ITC professionals spend time to understand accessibility, regulatory compliance, the capabilities of Adobe technologies and apply the appropriate level of consideration in project planning. It is far more expensive to retro-fit changes, rescue a failed project or limit brand damage caused by building a solution that, for example, is unavailable to an important community of Mac users or is complained about in a public forum by a blind user. This blog is the first in a series that explores the, often misunderstood, field of accessibility. This introduces the basic concepts and sets the context for subsequent blogs which will cover the practical aspects of implementing accessible PDF and Flex solutions.

What is accessibility?

Accessibility can be considered the degree to which electronic services and products can be accessed by the largest number of users possible. Although, often focused on disabled people, this is relevent to all people, including those that are on slow broadband, using non mainstream operating systems, using a mobile device or speaking non native languages. Accessibility is closely related to the concept of usability. Usability can be considered the ease with which a specified group of people can use an electronic service or product.

Why should I care about accessibility?

Technological progress and the meteoric rise of the Internet continues to fuel the trend of delivering services and goods through electronic channels. As the trend progresses, the opportunities and responsibilities of accessibility increase. The three primary reasons to care about accessibility are:

  1. It is good for business – increase leads and convertion to sales
  2. It is good for society – provide access for more people to the benefits of technological advancement
  3. You have to – legislation has been passed around the world that mandates accessibility requirements

Accessibility and disability

Although, accessibility is often set in the context of totally blind people, there are different categories of disabilities with different accessibility requirements.

Types of disability

The major categories of disability types are:

Visual disability Visual Blindness, low vision, color-blindness
Hearingdisability Hearing Deafness
Motor disability Motor Inability to use a mouse, slow response time, limited fine motor control
Cognitive disability Cognitive Learning disabilities, distractibility, inability to remember or focus on large amounts of information

What is Assistive Technology?

Assistive technology refers to any product or software program that has been developed or modified to make it accessible for the disabled. Of the wide range of assistive technologies available, the most relevent to PDF and Flex solutions are screen readers, text-to-speech, screen magnifiers and braille output devices.

Screen Readers

Screen readers are software that interprets what is being displayed on screen and re-presents it as synthesised speech or on a Braille output device. According to the WebAIM Survey of Preferences of Screen Readers Users completed in January 2009, the top three screen readers being used by 1121 respondents were:

JAWS and Window-Eyes are commercial products that offer evaluation licences. NVDA is a free, open-source screen reader. Screen readers are highly configurable, complex software that is designed to enable the operation of a computer in ways that are very different from the traditional keyboard and mouse methods employed by fully sighted users. The WebAIM screen reader simulation tool is an interesting way for a fully sighted user to experience the use of screen readers. It is recommended that screen reader testing be performed by specialist users.

Text to Speech

Text to speech software re-present normal language text as an artificial production of human speech. This software is used by screen readers and can be used independently. Common programs include ReadPlease and NaturalReader.

Screen Magnifiers

Screen magnifiers are software that interface with a computer’s graphical output to present enlarged screen content for the partially sighted.

Braille output devices

Braille output devices re-present text as braille by raising pins through a flat surface in braille characters.

What is the web standard for accessibility?

Since 1999 the primary international standard for website accessibility has been the Web Content Accessibility Guidelines (WCAG) developed by the W3C. This has formed the basis for accessibility legislation around the world, including Section 508 in the US and the 2000 Government Online Strategy in Australia. In December 2008, the W3C released WCAG 2.0 recommendation. Version 2 is a significant update to its predecessor. WCAG 2.0 is build around four basic principles:

Perceivable Information and user interface components must be presentable to users in a way that they can perceive
Operable User interface components and navigation must be operable
Understandable Information and the operation of user interface must be understandable
Robust Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies

Each of these four principles contains a number of guidelines outlining how a website should meet all users’ needs. Within the guidelines there are a number of success criteria which outline how the web content should be developed to meet the guidelines. There are three levels of conformance within WCAG 2.0, A, AA and AAA (the highest level). In order to conform to WCAG 2.0, the web content must satisfy at least level all of the Level A success criteria. The diagram below shows the minimum success criteria that must all be satisfied for web content to conform to WCAG 2.0: WCAG 2.0 - Level A WCAG 2.0 introduces the notion of “Accessibility Supported” and the requirement that only “accessibility supported ways of using technologies” can be relied upon to satisfy the success criteria. As both Adobe Reader and Flash Player are free and generally available from the Adobe web site, PDF and Flex satisfy the first of the basic requirements for it to be considered “accessibility supported” under the standard:

  • Users of the web must be able to obtain user agents for the Web Content technology that are accessibility supported. The W3C suggests this can be achieved in one of four ways.
    • In its basic state the technology is accessible to common user agents – e.g. HTML is supported by browsers. OR
    • The technology is supported by an accessible plug in such as Flash that is generally available. OR
    • he content is to be used in a closed environment such as a university or corporate network, where the necessary accessibility supported technologies are supplied. OR
    • The user agent that allows the technology to be accessible is easy for a person with a disability to obtain and it doesn’t cost any more than it would for someone without a disability.

Developments in the Adobe Acrobat, Reader and Flash Player in partnership with assitive technology vendors results in PDF and Flex passing the second of the basic requirements:

  • The way a particular web content technology is used must be supported by the assistive technology, that is, if you use JavaScript or PDF, for example, you must do so in a way that allows the final product to be accessed by assistive devices like screen readers and switches.

The accessibility myth

It is a misconception that PDF and Flex solutions cannot be accessible. There are two primary reasons for this:

Many existing PDF and Flex solutions on the web are not highly accessible

This is either due to projects not investing in accessibility or, particularly in the case of PDF technology that has been around for a long time, and was developed prior to versions of Reader and Flash Player that do support accessibility. Although HTML supports accessibility, it is possible (even easy) to implement HTML web-sites that are horribly inaccessible. Just because HTML supports accessibility does not mean that all HTML sites are automatically accessible – it takes effort and care to achieve this. In the same way modern versions of Reader and Flash do support accessibility and it is possible to build PDF and Flash content that is accessible. It is up to PDF and Flash developers to learn about these features and implement them correctly.

A bias of the earlier standard WCAG 1.0 was towards W3C web technologies

WCAG 1.0 has been the W3C endorsed standard for nine years and is the referenced standard for accessibility legislation around the world. WCAG 1.0 is technology dependent; Guideline 11 of the standard has two checkpoints relating to what technologies are accessible:

  • Checkpoint 11.1 has priority 2 (should) and says to use W3C technologies
  • Checkpoint 11.4 has priority 1 (must) and says that if you cannot create an accessible page, then an alternate accessible page that uses W3C technologies must be provided

One of the key drivers to WCAG 2.0 was to become technology agnostic, thereby opening the standard to non-W3C technologies such as PDF and Flex.


April 7, 2009

Processes, Orchestrations, Services, and other confusing terminology

Filed under: Components, Designing Processes, LiveCycle, LiveCycle Architecture — htreisman @ 11:47 am


There are a number of different terms used in Adobe LiveCycle Process Management, including process, orchestration, workflow, service, and component. These can be confusing.

Part of the reason for the proliferation of terminology is the history of the Process Management product and industry trends, and this blog entry tries to provide this perspective. This is my understanding of how these terms fit together, and should not be regarded as a definitive explanation.

If you don’t care about the historical perspective, skip to the end for a summary.


The first version of Process Management was called “Adobe Workflow”. And the things you created were called “Workflows”. Even today, many people will generically refer to any combination of boxes and lines that you create in Workbench as a “workflow”.

However, the term workflow was used primarily in the 80’s and 90’s to refer to more traditional image storing and routing applications, and doesn’t really adequately describe the much more useful data-oriented and integration capabilities of LiveCycle. In the 2000’s, the terms BPM or Business Process Management started to become more widely used, not just as a technology, but also as a way of thinking about and improving your business. Various BPM disciplines evolved, including Six Sigma, Lean, and others. LiveCycle fits in much more closely with BPM than it does with the older imaging-oriented workflow systems, so…

Adobe Workflow became LiveCycle Process Management, and Workflow was replaced with …


A Process is no different to a workflow, really, it’s just a term that better reflects the data-orientation and integration capabilities of the LiveCycle platform.

In LiveCycle, a process is almost always associated with a Form, and a series of human interactions that allow people to interact with the form and its data. There are almost always integration steps as well, such as pre-filling the form, writing to a database, adding a digital signature, sending emails, etc. These are also known as “long lived processes”, because they involve people interating with the form over a period of days or weeks.

Long lived process have a unique process-id, have every step recorded and audited, can be re-tried if any step fails, and can be viewed and managed through the Adminui interface.


In LiveCycle ES, we started seeing an increasing number of processes that are short-lived, and don’t include human steps. An example is the Default Render Process in LiveCycle ES. These processes used to be written as Java code in LiveCycle 7 – in ES, they have the advantage that being processes, we end-users can see and modify them very easily. It’s really just visual drag-and-drop programming. You can also easily build your own orchestrations to do something useful – for example, you may want to grab some data from an XML file, populate a form with it, encrypt the form with a password, and email the result to someone. There are no human steps in that, just a series of operation that need to be performed as quickly as possible. You could do this using the API’s, but implementing this as an orchration is quicker, more reliable, and much easier to change.

These short-lived or “straight-thru” processes do not store an audit trail, run as fast as possible (very close to native Java speeds), and do not have a unique process-id that identifies them. They cannot be managed through Adminui, and if they fail, they simply throw an exception back to the caller, rather than being able to be re-tried thru Adminui.

Someone coined the term “Orchestration” to refer to this type of process, and the name has stuck. I’m not sure where the use of this term originated, but it’s used in several other standards BPM standards and products.


  • Adobe do not officially use this term in their documentation (see http://blogs.adobe.com/livecycledocs/2009/02/the_livecycle_terminology_secr.html) but I think it’s a helpful term that differentiates a process as being short-lived.
  • You can still use a long-lived process for something that doesn’t involve humans. We often use long-lived-processes for processes that geneally run very quickly, because of the advantages of having each step audited, and for the ability to re-try a step if anything goes wrong. I would still call this an orchestration, because it doesn’t involve any human steps.

Here is a screenshot from WorkBench. This shows a process, its implementation, and its properties. This is a short-lived process, so I would call it an orchestration.



A LiveCycle Component is basically a bunch of Java code, packaged up into a jar file, and deployed into the LiveCycle server.

LiveCycle Components are brilliant. I love ’em. They are my insurance policy. I know that there is no problem that I can’t solve in the process world, because if i get stuck, I can write Java code to implement it. Then I can turn it into a LiveCycle component, drop it into LiveCycle, and bingo, I can use it my processes. And the real beauty of it is that anyone else can use my component too, without needing to understand programming. In LiveCycle, Adobe have created the best implementation of a server-side component model that I’ve ever seen – it’s a bit like those Visual Basic ocx controls that you can buy to build your GUI – but on the server.

The concept of LiveCycle server-side components came from a predecessor of Process Management, and were originally called QPACs – Quick (QLink for the real old-timers) Process Action Components.

Each component defines one or more services (see below). Although in reality, most components only define a single service, so components and services are somewhat interchangable.

A service can define one or more operations. An operation is the thing that actually does the work – like sending an email, encrypting a PDF, or writing a file to disk. Services group common operations together – so the File Utilities component contains a FileUtilsService, which in turn contains operations to read, write, create and delete files. Operations each define a number of input and output parameters.

For Java programmers:

  • Component == .jar file
  • Service == Class
  • Operation == method

Here is a screenshot of a Component within LiveCycle.


Avoka has been building components to solve real business problems with LiveCycle for many years, and we turn most of our components into re-usable components that anyone can use. We have a large library of components that solve most of the problems we’ve encountered over the last 5 years. So most of the time, you don’t even have to learn how to build components – if it’s not already in the Adobe “box”, then check out our website – there’s a good chance we may already have built it for you.

For more information, see: http://www.avoka.com/avoka/escomponents.shtml, or email info@avoka.com


Another concept that was introduced in LiveCycle ES was that of a “Service Bus” or “Service Oriented Architecture”. LiveCycle is internally implemented as a service bus. In simple terms, any bit of functionality within the LiveCycle server can be exposed to the outside world as a “Service”, and can be invoked in a number of different and useful ways. Once you’ve defined a service, you can define one or more EndPoints for that service. So for example, I might have a service that encrypts a PDF – I could add a Web Service Endpoint that allows me to invoke that service using Web Services. And I could also add a Watch Folder endpoint that allows me to invoke that service by dropping a file into a folder.

Now things get a little confusing. Services can be implemented as either some Java code, or as a LiveCycle process.

  • If you need to write Java code, you create a component, deploy that, and you get a service.
  • Or you can do it by creating an orchestration (or process), you define your orchestration, activate it, and you get a service.
  • Either way, you get a service. The choice of whether to use an orchestration or Java code depends on the complexity of the service you’re trying to create, and whether it can be created by joining together (or orchestrating) a number of other existing services.

The LiveCycle process engine doesn’t really care whether your service is implemented in Java or as an orchestration, you invoke and manipulate it in exactly the same way. You can either call a service externally (by defining an endpoint), or you can invoke one service from another, simply by dragging the service into process. This is a very neat way to handle things – why should you care how something is implemented, you should be able to use it the same way.

Note: An orchestration only ever defines a single operation, always called “invoke”. Whereas a component can define multiple operations.

This screenshot shows two services, one implemented as a component, and the other as an orchestration.



  • Process: Something that you build in Workbench, and looks like a flowchart. Can be user-oriented/long-lived, or straight-thru/short-lived.
  • Orchestration: An unofficial but commonly-used term for a straight-thru/short-lived process.
  • Workflow: An older term for a process.
  • Component: A jar file containing some code to do something “useful”, that you deploy to the LiveCycle server. A component contains services, which in turn contain operations. All the Adobe services are built as components, as are all the Avoka add-on services.
  • Service: Something that lives in the LiveCycle server that provides some sort of “service”. Can be implemented either as Java code (as a component) or as a process/orchestration.

Create a free website or blog at WordPress.com.