Setting a User Task Deadline – Based on Form Data: LiveCycle Tips and Tricks
LiveCycle User Assign Tasks have a neat User Interface for settings deadlines. Setting it up with a timeout and a route to follow after the deadline has elapsed is all done graphically. It is well documented and pretty easy to follow.
Recently a customer came to me, asking to deadline a User Assign Task – based on a date in the form. I said yes I can do it. I knew that LiveCycle supports Literal (read Graphical) and Variable (read code) configuration for every component and there were over 80 data types in LCES 8.2.
Setting a deadline for an Assign Task during process runtime is not obvious. The Deadline section can take an XPath expression (see below) to something but the magic question is what XPath expression?
It’s not well documented but there is a built-in LiveCycle type made exactly for this purpose – called TaskDeadline.
Once you declare a variable of that type you can basically set it to do anything you want. Here are the XPath settings I used in a Set Value task for configuring the Task Deadline dynamically.
| /process_data/deadlineVar/object/@selectedRoute | ‘Deadlined’ |
| /process_data/@deadlineDate | /process_data/xfaForm/object/data/xdp/datasets/data/myform/deadlinedate |
| /process_data/@iDays | get-days-from-date-difference( /process_data/@deadlineDate , format-dateTime-withFormat( current-date() , ‘yyyy-MM-dd’ ) ) |
| /process_data/deadlineVar/object/dateObj/@days | /process_data/@iDays + 1 |
| /process_data/deadlineVar/object/@omitDeadlineRouteFromUser | 1 |
Note that the Selected Route is configurable, and a button showing that route can be omitted from the Workspace chrome with the expression in the last assignment.
What’s new in LiveCycle Designer ES2?
Adobe has recently released LiveCycle ES2 – the second major update to their enterpise suite. This blog takes a look at what is new for PDF form developers and designers.
What is LiveCycle Designer?
LiveCycle Designer is the Adobe tool for building PDF forms.
Hang on a minute, can’t you do that with Acrobat? Yes, you can create simple forms by over-laying fields onto a PDF with Acrobat. You use Designer when you get serious about forms and want to provide your users with the best experience possible. Designer provides enhanced form functionality, including:
- Streamlined workflow; create content and form elements in a single tool. Content changes can be performed without having to re-apply form elements, such as accessibility tags
- Dynamic content; forms that personalise their content to the user and guide them through the data capture process. This is implemented with content show/hide and repeating sections
- Data connections; bind fields to external data sources for easier integration with other systems. Data structures are protected from changes to form layout
- Reuse; fragments, common objects and templates allow content to be reused across multiple forms
LiveCycle Designer is a Windows application that can be purchased on its own or comes bundled with Acrobat Pro and LiveCycle Workbench. The bundled version is automatically opened by its parent application when needed or can be opened stand-alone by running FormDesigner.exe
New features in Designer ES2
The most significant change to Designer is the removal of the Form Guide Builder. LiveCycle Guides are now built in Workbench and no longer require a base XDP file. There will be more on this in upcoming blogs.
There is minimal over-head in migrating to Designer ES2 due to very little change in the workflow of building PDF forms. What Adobe have given us in this release is additional features for making it easier to produce high quality forms. Form designers and developers can now be more productive than ever.
Please note that the minimum versions of Reader/Acrobat that you must support will determine which of these features are available to you. Contact Avoka if you need further information.
Action Builder
A common theme in my training courses and client engagements has been that form designers want to realise the benefits from the smart features of PDF forms without having to get too deep into coding.
Designer ES2 introduces Action Builder – a simple wizard interface for building useful, common behaviours with no coding, including showing/hiding an object, attaching a file, displaying a message box and perhaps the most useful of all – adding and removing repeating sections and table rows.
Clearly, a lot of thought has gone into Action Builder. It is surprisingly forgiving. It manages the code so that it continues to work even when you move and rename fields and works happily alongside custom code. It even handles the case when its generated code is changed.
Early indications are that this will be useful for experienced developers as well as designers and novice developers. It provides a useful starting point for advanced features, such as clearing the fields in the last row to be deleted in a dynamic table.
Error Messaging
A common requirement from clients is to enhance the default error messaging provided by Acrobat/Reader. In fact, it is so common that Avoka has invested a significant amount of time in building a sophisticated errors framework for our clients’ forms.
Designer ES2 enhances the default behaviour by providing additional messaging handling options. Without coding, the form designer can configure:
- The behaviour of error message boxes
- How to highlight fields that fail validation
- How to highlight mandatory fields that are left empty
- Whether to set focus to the first field that fails validation
An interesting feature of this, is that it provides real-time validation. For instance, if you have configured the background colour of fields to turn red on failed validation, this will occur as soon as you exit an invalid field. Historically, this was difficult to achieve as it meant putting code on every field. This has been made simple in ES2 by the introduction of the next feature – event propogation.
Event Propogation
It is common to want a group of fields in a form to exhibit the same behaviour. For instance, you may want to strip leading and trailing spaces from text as it is entered into your form.
Designer provides several ways to do this when you are first building a form, including using pre-coded common objects. However, it was difficult to maintain as any change would typically require changing code on multiple objects.
Event propogation makes this much easier by allowing code on an a container to be inherited by every object within that container. I could write my space stripping code in the exit event of a top level subform, turn on event propogation and have all text fields immediately start stripping text.
A nice feature of this is that it is accumulative; an object will execute the code it inherits from every one of its containers that propogate events in addition to any code that is written directly on its events.
Data Connection to Adobe Data Model
LiveCycle ES2 introduced the Adobe Data Model to make it easier to share data resources across applications, including LiveCycle guides and processes. Data from an ES2 Data Model can be displayed in a static form by using the new Adobe Data Model data connection. Form fields are bound to data fields in the Designer data view pallet in the usual way.
Localisation
To create forms in multiple languages using XLIFF it is necessary to configure Designer to create a unique identifier for each text string. This can now be configured using the ‘Create Translation IDs when Saving’ property on the Document Handling section of the Options dialog box.
Three new locales have been added to Designer ES2: Catalan, Basque and Tagalog.
Usability Improvements
Based on community feedback, Adobe have made various usability improvements, including:
- Filtering data views. Makes it easier to handle large data connections by filtering for the sections that you are working on
- Integration with Workbench ES2. Workbench now opens forms for editing in Designer stand-alone which provides the full set of features and makes better use of screen real-estate. The two work well together – seamlessly opening and saving forms between the two
- Default scripting language. Rather than set the language to JavaScript every time you create a new form, you can now set it once in the Options dialog box
- Pasting into drop-downs and list boxes. Rather than enter each value of a list separately, you can now copy the entire list from a text editor and paste it into Designer
- Enhanced scripting assistance. The script pallet feature that suggests methods and properties as you type now provides additional information including input and output parameters
- Snap to Object. Makes it easier to layout objects in a positioned layout
- Metadata properties. You can now add custom properties to a form, such as copyright URLs, in the Info tab of the Document Properties dialog box
Find out more…
Resolve a specific LiveCycle Designer issue or have general questions answered by one of our experienced consultants by contacting Avoka.
Learn more by attending our certified LiveCycle Designer training course.
Explore what is possible with LiveCycle Designer on our website.
PDF Accessibility – part 3 of 3 (reading text)
This blog is the third in a series that explores PDF accessibility. This installment describes how to implement PDFs using Adobe LiveCycle Designer so that form text is accessible to users of assistive technologies.
In this series:
PDF Accessibility – part 1 (introduction) – an introduction to accessibility standards and technologies
PDF Accessibility – part 2 (reading fields) – a step-by-step guide on making form fields accessible
WCAG 2.0 Guidelines
1.3.1 Info and Relationships: Information, structure and relationships conveyed through presentation can be programatically determined or are aviable in text 1.3.2 Meaningful Sequence: When the sequence in which content is presented affects its meaning, a correct reading sequence can be programatically determined 2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages 2.4.5 Multiple Ways: More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process 2.4.6 Headings and Labels: Headings and labels describe topic or purpose 2.4.10 Section Headings: Section headings are used to organize the content 3.2.3 Consistent Navigation: Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user
These guidelines are all about making it easier for assistive technology users to find text.
This is important due to the way that assistive technology users interact with a form. Unimpaired users can rapidly identify form text. They have the benefit of being able to scan a form by eye in any direction that they choose and rapidly absorb large amounts of text. Assistive technology users can access the same information, but at a slower pace. Mechanisms are required to present form structure so that assistive technology users can navigate directly to areas of interest.
Tags
You add structure to your PDF by tagging text. Similar to the table of contents in a document, tags are used by assistive technology to provide the user with a summary of a form’s content and the ability to quickly navigate to an area of interest without having to take the time to read the entire form.
To make your tags available to assistive technology, you have to check the ‘Generate Accessibility Information (Tags) for Acrobat’ in the ‘Form Properties’ dialog window.
Headings
Add structure to your PDF by tagging the headings. Set the ‘Role’ property to ‘Heading Level X’ for text objects in the accessibility pallet.
Headings can be tagged in a hierarchy up to 6 levels deep. Use the same rules that you would in a document – tag heading level 3’s under heading level 2’s etc. Heading tags can only be applied to an entire text object – you cannot tag part of the text.
When an assistive technology user runs the commands to navigate headings, they will be given the ability to quickly browse the form’s structure and navigate quickly to the area of interest. For instance, JAWS10 can display the dialog window below and will read all headings or only those at a specified level and the ability to ‘Move To Heading’.
Lists
Add structure to your PDF by tagging lists. This is appropriate for simple text lists. Do not tag nested lists or lists that contain fields.
Set the ‘Role’ property to ‘List’ and ‘List Item’ on subforms in the accessibility pallet. The ‘List’ subform should contain at least one ‘List Item’ subform, but not necessarily at the top level.
When an assistive technology user runs the commands to read lists, they will be given the ability to quickly navigate to any list in the form. For instance, JAWS10 can display the dialog window below and will read the content of each list. Each item in the dialog represents a ‘List’ with all its ‘List Items’. The screen reader reads any text that it can find within the tagged subforms.
Form Design for the Rest of Us – Avoka SmartForm Composer
There are some people who have an instinctive feel for design – color, balance, typefaces, effective use of whitespace – and who can create beautiful looking forms. I can’t. My forms generally look like they were designed by a six-year-old with a box of crayons. I usually rely on someone else with creative design skills to help me to come up with a good looking form.
On the other hand, I can build forms with great functionality, because I’ve got a programming background, I’ve been building forms using LiveCycle Designer for 5 years, and I’ve read large portions of the 3000+ pages of API documentation that Adobe provide (yes, really). Plus I have a team of very experienced LiveCycle developers around me who I can call on to help me if I get stuck.
Composer Design Window
You may be a bit of a geek like me, or perhaps the thought of programming bores you to tears. You may have some of the creative talents that I lack, or perhaps you’re “creatively-challenged” like me. Or maybe you’re a pragmatist who doesn’t care about style or programming, all you’re really concerned about is the business problem of collecting the data that you need, and making it as easy and intuitive for your users to interact with your form.
Whichever category you fit into, it’s unlikely that you have the complete set of skills and experience to build a SmartForm from beginning to end.
This is exactly why we built Avoka SmartForm Composer – for you!
We’ve taken all of the knowledge that our Form Design Team have gained in dozens of person-years of experience in building forms, and we’ve encapsulated all that knowledge in Composer. We’ve wrapped that knowledge up into a web-based Flex application that makes it really easy to build forms.
Smart Templates
With Composer, you simply select one of our pre-defined Smart Templates, and you’ll end up with a form that looks great, no matter what your design skills. Add business logic easily using our intuitive rules editors – no programing required. Or choose from our specially designed pre-fabricated “blocks” that embed professionally coded business logic into your form. Click the “Publish” button, and Composer will generate an Adobe XFA compliant PDF SmartForm, and optionally publish to the LiveCycle Repository or Avoka FormCenter. Need to change something across all your forms? Simply tweak the master Style Sheet to change colors, fonts, margins, logos and other visual aspects of your form.
I’m biased, of course, but I’m very excited about Composer. I think it will enable all of us to build intelligent, interactive PDF SmartForms easily, quickly and reliably, and ultimately help to streamline our business processes.
For more information about Composer (including demos), or to stay informed or sign up for our beta program, please visit: http://www.avoka.com/composer
PDF Accessibility – part 2 of 3 (reading fields)
This blog is the second in a series that explores PDF accessibility. This installment describes how to implement PDFs using Adobe LiveCycle Designer so that form fields are accessible to users of assistive technologies.
In this series:
PDF Accessibility – part 1 of 3 (introduction) – an introduction to accessibility standards and technologies
PDF Accessibility – part 3 of 3 (reading text) – a step-by-step guide on making text accessible
WCAG 2.0 Guidelines
1.1.1 Non-text Content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose 2.4.6 Headings and Labels: Headings and labels describe topic or purpose 3.2.4 Consistent Identification: Components that have the same functionality within a set of Web pages are identified consistently 3.3.2 Labels or Instructions: Labels or instructions are provided when content requires user input 4.1.2 Name, Role, Value: For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies
These guidelines are all about making it easier for assistive technology users to use form fields.
This is important due to the way that assistive technology users interact with a form. Although, fields are typically represented by un-informative shapes such as a rectangle, unimpaired users can rapidly determind its purpose. They have the benefit of being able to scan a form by eye in any direction that they choose and see fields in context; location, label and surrounding content. Assistive technology users can access the same information, but at a slower pace. Mechanisms are required to enable the user to navigate directly through the fields, ignoring other content, and for alternate text to be read which describes the fields’ purpose without relying on context.
Using the field’s caption for alternate text
Whenever possible you should use the field’s caption for alternate text. Set the ‘Screen Reader Precendence’ property to ‘Caption’ in the accessibility pallet.
When a user tabs into this field, the screen reader JAWS V10 with default configuration reads the following:
Your country of citizenship… edit… type in text
The alternate text is read first to identify the field. This is followed by additional information to help the assistive technology user. In this case, it tells the user what type of field this is and how to use it. Although, this approach is common, the text read is specific to screen reader.
Setting custom text for alternate text
There are occasions when it is not appropriate to use the field’s caption, including:
- The field has no caption
- The caption is too verbose
- The caption is not meaningful out of context
Set the ‘Screen Reader Precendence’ property to ‘Custom Text’ and enter the custom text in the ‘Custom Screen Reader Text’ property in the accessibility pallet.
The field has no caption
It is sometimes necessary to implement a field’s label as a separate text object, for instance to implement multi-line labels:
In this case, it is common to use the text from the label object as custom text.
The caption is too verbose
It is important that the alternate text for a field is concise. Verbose captions that are provided to assist a sighted user may be frustrating for a user of assistive technology.
In this case, it is common to paraphrase the caption text.
The caption is not meaningful out of context
Field captions can depend on context to make sense. A common example is radio button lists. Typically, a separate text object is implemented to ask a question and a radio button is provided for each answer.
For instance, when a user tabs into a yes/no radio button list that uses the caption for alternate text, the screen reader JAWS V10 with default configuration would read the following:
Yes… radio button not checked… one of two
To resolve this, it is common to provide custom text that combines the question with the response for that radio button.
A closer look at how alternate text works
How alternate text is read is dependent on the assistive technology used. You can use the attached AltText-TestForm to test. The two most popular screen readers were used for this article:
- JAWS V10
- Window-Eyes V7.1
Screen Reader Precedence
The ‘Screen Reader Precedence’ property on the accessibility pallet has the following values:
- Custom Text
- Tooltip
- Caption
- Name
- None
The screen reader uses this property to determine what text to read. If no text is found, then the screen reader searches for text in the precendence order, starting from Custom Text.
When ‘None’ is selected Window-Eyes performs a search through the precedence order. JAWS does not search through the precedence order, but tries to find a caption, including looking for a text object that may be the label for this field. As a last resort, both screen readers read nothing for the field description, resulting in:
edit… type in text
Using tooltips
Tooltips are used to provide sighted users assistance with completing fields. The text is displayed in a box when the user hovers the cursor over a field.
Typically, tooltips are too verbose to be used as alternate text. To make important tooltip information accessible, it should also be displayed in the form content.
c9eq4xmrbv
Pre-populating forms with LiveCycle ES
Summary
The recommended pre-population technique is on the server as part of a Livecycle ES process. This provides the best user experience and allows leverage of the full power of LiveCycle ES. This is the default implementation for LiveCycle forms rendered as Form Guides or HTML, as you already have the infrastructure in place for rendering these formats.
A light-weight alternative is available for PDF forms: direct web service calls from Reader/Acrobat that requires little or no server infrastructure.
The most common approach for PDF is to pre-populate user data, for instance name, address and contact details for a known user, in a LiveCycle ES process on the server and then use web services from the client to lookup data from large data sets or perform complex/shared validations.
Pre-populating on the server
Pre-population of data into LiveCycle forms on the server is implemented in a LiveCycle ES process. The three core services to enable this are:
- Forms Data Integration (FDI) – for pre-population of XML data into a PDF. This service is bundled with several LiveCycle solution components including Process Management and Reader Extensions
- Forms ES – for pre-population of XML data into an XDP and conversion to PDF, Form Guide or HTML. This is for use cases that are only supported by XDP, including dynamic importing of form fragments
- Output ES – for pre-population of XML into XDP or PDF and conversion to a read-only or printer-ready format
A typical user experience would be:
- User logs into a web-site or portal
- User clicks on a link to a form
- A server web component (any HTTP technology including servlets, jsp, PHP and ASP.NET) handles the request and calls a LiveCycle process, passing a form ID and the user’s ID (either as a web service or using the LiveCycle APIs)
- The LiveCycle process retrieves the form based on form ID
- The LiveCycle process retrieves user data based on the ID and generates an XML file
- The form is pre-populated using one of the services above
- The pre-populated form is returned to the web component which is displayed to the user
Avoka provides a pre-built web component to simplify this implementation – process invoker.
Pre-populating from the client
PDF forms provide the functionality to lookup data directly from Reader/Acrobat using a web service or database lookup. An explanation of how this is implemented is provided by Adobe livedocs.
Web service pre-population is the prefered approach. The database lookup requires that ODBC data source names (DSN) be set up on each user’s machine that will use the form. This may be useful for testing, but is infeasible for production forms. It is not scalable for internal forms and impractical for externally facing forms.
A typical user experience would be:
- The user navigates to a web-site
- The user clicks on a link to a form
- An empty form is displayed within the browser (inside the Acrobat plug-in)
- The user enters a customer ID and clicks a button
- The Acrobat plug-in directly calls a web service, passing in the customer ID
- The web service returns the user’s data which is displayed within the form
Comparison Matrix
| Pre-populating on the server | Pre-populating from the client | |
|---|---|---|
| User experience | The form is already customised for a known user when it is viewed | The form is not personalised to the known user when it is first viewed. The user has to re-enter identifying information into the form and perform an action, for instance click a button, for the web service to be called |
| Maintenance | Changes to the pre-population service can be made in one central location and does not require changes to or re-distribution of forms | Changes to the pre-population service may require changes to and re-distribution of forms |
| Data sources | Pre-populated data can be retrieved from multiple sources and transformed by the LiveCycle process before being pre-populated into the form | Multiple web services can be used from within or outside the organisation |
| Infrastructure | A server installation of LiveCycle ES is required | A lighweight solution that can be implemented with little or no server infrastructure. Server infrastructure is only required to provide access to the form, if it is not to be distributed offline, for instance by email or on CD-ROM/DVD, and to expose web services from your organisation |
| Development tool | Implemented with LiveCycle Workbench | Implemented with LiveCycle Designer |
| Offline support | The user must be logged in and online to view a new form. They can then save the form to their local machine and work offline | The user can either view the form from a web-site or receive it in an email or on fixed media, for instance cd-rom or memory stick. The user must be online to call the web service |
| Technical limitations | None. LiveCycle ES can handle different form types, data sources and transformation requirements | Web services in anything that is not document literal style or returns multiple responses requires custom codingPassword-protected web services cannot be called from a form
Users behind an NTLM authenticating proxy must use Adobe Reader/Acrobat version 9.0 or higher. Typically, this only affects users on corporate environments |
PDF Accessibility – part 1 of 3 (introduction)
This blog is the first in a series that explores the, often misunderstood, field of accessibility. This installment introduces the basic concepts and sets the context for subsequent blogs which will cover the practical aspects of implementing accessible PDF and Flex solutions.
In this series:
PDF Accessibility – part 2 of 3 (reading fields) – a step-by-step guide on making form fields accessible
PDF Accessibility – part 3 of 3 (reading text) – a step-by-step guide on making text accessible
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.
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:
- It is good for business – increase leads and conversion to sales
- It is good for society – provide access for more people to the benefits of technological advancement
- 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 | Blindness, low vision, color-blindness |
 |
Hearing | Deafness |
 |
Motor | Inability to use a mouse, slow response time, limited fine motor control |
 |
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 at 74%
- Window-Eyes at 23%
- NVDA at 8%
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 built 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 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
- The 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.
What do the LiveCycle ‘Process Fields’ really do?
Background
In order to integrate a LiveCyc le PDF form into LiveCycle Process Management, you need to embed some special fields into your form.
The LiveCycle documentation does indicate what these fields are for, but doesn’t really explain exactly how they are used and populated.
Process Field Documentation Link
This blog entry explains how it all really works.
The Fields
The Process fields inside Designer look like this:
The scenarios
When integrating with Process Management, the form will be presented inside Workspace. There are a number of scenarios:
- A user is submitting a form within Workspace (either to initiate a process, or as an item in their To Do list)
- The user has taken an initialization form offline
- The user has taken a form from their inbox offline.
Submitting a form within Workspace
In fact, for this basic scenario, you don’t need the process fields at all. All you really need is a Submit button.
However, if you do use the process fields, you get a few extra capabilities, including user choices, and the option to take the form offline.
The field AWS_SUBMIT is a regular button that contains some Javascript code. This code, among other things, checks whether you’re running in an online (within Workspace) or offline mode. If you’re running online, it simply sends a “click” event to the real submit button, FSSUBMIT_ (which is a hidden http submit button).
Apart from the choice fields described below, none of the other fields are necessary – LiveCycle knows exactly who you are, and what you’re doing, because you’re logged into a live session in Workspace. It’s only when you take a form offline that the other fields are necessary.
Giving the user a choice
Sometimes you want to give your users a choice, which will affect the routes that are taken within the LiveCycle process. If you put a bit of text into the AWS_CHOICE text field, such as “Approve,Deny”, the Javascript code will:
- Display the Action dropdown (if there are no choices, it will be hidden)
- Populate the Action dropdown with the values from the AWS_CHOICE field.
It will look something like this:
You can put your own comma-separated text into AWS_CHOICE, but LiveCycle will automatically do a whole bunch of useful things for you.
- When you create a User Assign Task step in your workflow, check the checkbox that says “Populate Form with Routes”. LiveCycle will then look at all the route names coming out of your User step, and populate AWS_CHOICE with the route names.
- When the user submits the form, LiveCycle will interrogate the value of the Action dropdown, and automatically route the process down the selected route.
Note: If you choose not to use this option, you can simply create rules in your routes that interrogate other data within your form to decide which route to follow.
Note: Certain route names are associated with special icons in Workspace. These are “Approve” and “Reject” (or maybe “Deny”, I forget.) You can configure these special icons and their associated routenames from Adminui.
Taking a form offline.
Once you take a form offline, it is “disconnected” from Workspace. You can fill it in, and when you click the Submit button, it will be submitted via email, rather than over the web. The AWS_Submit button has logic to determine whether you’re online or offline, and submit either via the web or via email.
If you’re submitting via email, the form needs to know what email address to submit it to. This email address is automatically populated by LiveCycle into the AWS_MAILTO field when you take the form offline. Like all the other fields, there’s no real magic – you can set the field to an email address manually or in code if you want to, but generally it’s easier and safer to let the LiveCycle server take care of this for you.
Note: In order to allow offline submissions, you need to set up a email box, and configure LiveCycle to monitor this email box. That’s the subject of another blog sometime. Email info-at-avoka.com if you’re having trouble.
When you submit your form data via email, LiveCycle no longer knows anything about you, or why you’re submitting the form. It simply knows that an email arrived in an inbox containing some XML as an attachment. So…
When you take the form offline, LiveCycle injects some data into a few fields:
- When you take an initialization form offline, the LiveCycle server will populate AWS_PROCESSTYPE with the name of the process that should be initiated when you submit the form. When you submit the form via email, LiveCycle will start the named process on your behalf, using the data from the email attachment.
- When you take a form in your inbox offline, the LiveCycle server will populate AWS_TASKID with the id of the task that this relates to. When the submit the form via email, LiveCycle will complete that task on your behalf.
- In both cases, LiveCycle will use the email address of the sender of the email of the email to determine who the “completer” was. Warning: make sure you send from an email associated with your LiveCycle identity – if LiveCycle doesn’t recognize the sender, it will treat the email as spam, and silently discard the incoming email. (I haven’t verified this lately, but it used to work this way.)
- In both cases, the LiveCycle server will populate the AWS_ASSIGNEDID with the internal LiveCycle ID of the user who was originally assigned this form. I have no idea whether this is used for anything, or why it might be useful to either you or LiveCycle.
- Finally, once you submit via email, Reader will set the AWS_STATUS field from ” ” to “Submitted”. Once this field has the “Submitted” value, you will not be able to submit the form again. This simply prevents duplicate submissions being accidentally emailed.
Summary
While there’s quite a bit of logic associated with these fields, both within the form and with the LiveCycle server, you don’t really need to know how it all works. Just drop the fields into your form, and LiveCycle takes care of the rest. It is helpful, however, to know how this works, so that you can tweak the behaviour if necessary.
Populating a drop-down using XML and Dynamic Binding
In one of our previous blogs, we mentioned several techniques for populating a drop-down list with data. In this posting, we’re going to use a technique called “Dynamic Binding”. We’re going to use an XML file to populate the drop-down, as well as for populating a repeating lists of questions.
The form we’re going to develop is a general purpose survey form, where both the list of questions, and the answers allowed, are pre-populated with XML. Since Designer only supports a single XML file, we’re going to store the drop-down values, the questions, and the answers that the end-user selects, all in the same XML file.
The Sample PDF is here: dynamic_survey_with_embedded_data. Try it out before you start the exercise, so you can see what we’ll end up achieving.
Note:
- You can just open this file in Reader to try it out
- You can open it in Designer to see how it works
- The PDF has two attachments, the XML schema and a sample XML file. Click on the paper-clip icon to get at these.
It also contains the sample XML and schema files as embedded attachments.
Step 1: create the schema
Note that “Question” and “ResponseItem” are repeating, with a cardinality of 1..*. “Questions” will be used to populate the list of questions dynamically. “ResponseItems” will be used to populate the drop-down list containing the user’s responses.
Step 2: Create a simple form
You must save it as a Dynamic PDF form, because it’s going to grow based on the data we put into it. Also, because we’re going to grow the number of questions based on the data in the XML file, we need to use a Flowed rather than Positioned layout.
Note that the table has only one row (set to “repeating” on the binding tab), and a DropDown list with no values specified.
Step 3: Add the schema to the form
Add the schema to the form by defining a new data connection. Embedding the schema is optional, but useful if you’re ever going to use this form within a LiveCycle process.
Step 4: Create the XML file
Make sure it conforms to your schema. Here’s a snippet:
Step 5:Turn on Dynamic Binding
This is available from the drop-down menu of the Object palette in Designer.
Step 6: Bind the schema elements to the form objects
Use the Binding sub-tab of the Object palette.
- Bind Row1 to the Question[*] repeating group – this will ensure that for every row of Question data in the XML, we’ll get a new Row1 in the form.
- Bind the Question and Answer fields to the sub-elements of the repeating group. Note that you use relative binding, because the repeating element is already bound to Row1.
Step 7: Dynamic Binding
Bind the drop-down’s values and labels to the elements defined in the schema. Click on the green “Specify Item Values” link, and in the Dynamic properties dialog, enter the repeating element, and the sub-items containing the text (the values displayed) and value (the values stored in the data). This is summarized in the screenshot below:
If you don’t see the green link, revisit Step 5.
Step 8: Preview the form
In Designer, set the “Data File” to point to your sample xml file.
Click on the Preview tab. You should see something like this:
Try changing the data in the sample XML file (for example, adding “No opinion” to the drop-down data, or a new question), and then preview again. You should see the new question and drop-down items appear.
Finally
You can embed the XML data into the form manually using Acrobat or automate it on the server via LiveCycle Forms or Process Management. Using a LiveCycle orchestration, you could of course generate the XML using a database query or some other source.
If you’d like more information on how to do this, please contact info@avoka.com
Creating a Read-only copy of a form
Overview
Very often, as part of a process, you’ll want to create a read-only copy of a form, and store it somewhere, or email it to someone. There are various ways of achieving this, and they vary in different ways.
Making the fields read-only
It’s possible to make all the fields in the form read-only, using some Javascript coding. This is fairly straight forward, and looks something like:
TextField1.access="readOnly"
If you have a few fields on your form, you can just do this for each field. If you have a lot of fields, you’ll probably want to write this as a recursive function, and do all fields in a single function call. This can be quite fiddly, because you need to correctly handle all the different types of form objects. (Avoka can help with this – contact info-at-avoka.com for assistance.)
Pros
- Inexpensive
Cons
- Can be fiddly to program
- While this makes the form appear to be read only, a clever end-user could still modify it. To modify it, open the form in Acrobat, use Forms/Manage Form Data…/Export Data… to export the data as XML, modify the XML, and then re-import the XML data using Forms/Manage Form Data…/Import Data… The form data will have changed, and nobody is any the wiser.
“Flattening” the form
Adobe have a server product called LiveCycle Output. One of the things that LC Output will do is “flatten” a form – that means that it will be converted from an editable type of PDF document to a more traditional “read-only” document. The fields are no longer editable fields, they are really now just boxes and text drawn onto the page.
Pros
- This is much more secure than setting fields to read only. The XML data no longer exists, and cannot be modified.
- No JavaScript programming required to achieve this – simply route your form to LiveCycle Output, and generate the flattened PDF.
Cons
- It’s still possible to modify the PDF file to change what appears on the form. This is much harder, because the PDF is now in a binary format, but it’s possible.
- Requires server-side integration
- Requires purchasing LiveCycle Output (but LC Output does other useful things, so this may really be an overall benefit to your organization).
Digitally Signing the Document
Digitally signing the document doesn’t actually prevent the document from being modified, so needs to be used in conjunction with one of the above techniques. However, it does take a “snapshot” of the document, and if any changes are made, the signature will be invalidated. This enables you to guarantee that the version of the file you saved has not been modified since it was produced.
Pros
- Guarantees that the PDF has not been modified since it was saved.
Cons
- If signing is performed directly by the client, it requires Adobe Acrobat (or Reader Extensions)
- If signing is performed on the server, then you must purchase a copy of LiveCycle Digital Signatures, and integrate this into your process.
Summary
There are several different techniques for making a form read-only. The one to use depends primarily on how willing you are to accept the risk of the document being changed (accidentally or maliciously) after it’s been produced, and how much you are willing to spend to achieve the level of protection you want.