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.
A Quick Way to get to the Script Editor in Designer
When you first start up Designer, the script editor is only half visible just underneath the toolbar. Usually I make it a little bigger by moving the thumb down a bit, like this:
Then I double click on the thumb to move it all the way to the top, and double click again to re-expand.
But this is very inconvenient. The script editor is not really big enough to see bigger blocks of script, and if I increase its size, it takes up too much of the screen real-estate that I need for actually designing my form. So I end up continuously making it bigger and smaller depending on what I’m doing. Very irritating.
Here’s a simple way around this.
Firstly, set up a keyboard shortcut to toggle the Script Editor visibility. Use the Tools/Keyboard Shortcuts… menu, select Product Area = Window, find the Script Editor command. Then click in the “New Shortcut” field, press F4 (or your shortcut of choice), and click Assign.
Then re-arrange your Script Editor to suite your needs. My favourite is detached from the main window (or undocked), and fairly large, as shown below:
There is a bit of a trick to get this right, because as soon as you make the Script Editor a bit large, it will try to dock whenever you move it. So…
- To undock it, double click on the move bar of the Script Editor. (The move bar will appear either at the top or left of the Script Editor, depending where it’s docked.)
- Then reposition the Script Editor, NOT by moving it, but rather by resizing both the top left and bottom right corners. Resizing won’t cause the Editor to dock, whereas even the slightest movement can.
From this point on, a single F4 keypress will toggle the Script Editor on and off, and I always have the script editor just where I need it when I need it.
Many thanks to Stefan Cameron for this trick.
LiveCycle @ MAX
Last week I had the privilege of attending MAX, Adobe’s annual conference, and being part of the buzz and excitement around Adobe’s strategy and direction.
There is always a lot going on at MAX, and it’s always difficult to decide what to attend, and what to blog about – so I thought I’d focus on LiveCycle, and leave Flex and Flash and Creative Suite to others.
Some of the highlights for me were:
- Walking in to the LiveCycle pre-conference tutorial on Sunday (yes, people gave up their weekends to attend technical training) and seeing an entire roomful of people (at a rough count, about 70 workstations) banging away building applications using the LiveCycle ES2 beta. Apparently, LiveCycle was the only one tutorial that was completely sold out, as were several LiveCycle sessions during MAX.
- Two new products added to the LiveCycle platform: LiveCycle Mosaic (http://www.adobe.com/products/livecycle/mosaic/) and LiveCycle Collaboration Services (http://www.adobe.com/products/livecycle/collaborationservice/ )
- LiveCycle WorkSpace approvals via mobile devices.
- Seeing LiveCycle and Enterprise Development being showcased at the opening keynote by Ben Forta and Rob Tarkoff . http://max.adobe.com/online/keynote_monday/ – About 62 minutes in for Rob and 71 minutes for Ben. Both talks includes a few sample enterprise applications, as well as demos of Mosaic, approvals via mobile devices, and more.
- The new version of Form Guides, or just Guides, as they now seem to be known. We’ve been playing with the early versions of the new Guide Builder for a little while now, and we think Adobe have done an awesome job on this release – Guides are now very powerful and very easy – we’re very very happy.
- The Adobe Data Model. In the Enterprise, everything usually starts and stops with data in a database somewhere. Data model driven development is part of LiveCycle Data Services, but is also used as the basis for the data storage in the new Guides. We’re very excited about this.
http://tv.adobe.com/watch/max-2009-develop/modeldriven-development-using-flash-builder-4-and-livecycle-data-services-es/
You can view many of the Adobe sessions on Adobe TV here:
http://tv.adobe.com/show/max-2009-develop/
including this one, on What’s New in LiveCycle ES2
http://max.adobe.com/online/session/46
This is Jayan’s pick of the sessions:
http://blogs.adobe.com/livecycle/2009/10/max_2009_sessions_about_livecy.html
One other amusing note: The mythical John Jacobs, who is a “sample” user that appears in many of LiveCycle’s samples and demos, actually exists. He was at the MAX conference, and attended the pre-conference tutorials. Hello John!
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
What is a SmartForm?
Heard about SmartForms, but confused by the jargon? Never heard of SmartForms, but interested in the latest developments in electronic forms?
This blog provides the need-to-know facts about SmartForms. For a full overview, please watch SmartForms – the next generation of electronic forms.
| Running time: | 13 minutes |
|---|---|
| Content: | What is a SmartForm? |
| Demo of three SmartForms in action | |
| Why SmartForms? | |
| Who is using Smartforms? |
SmartForms
A SmartForm is an electronic form used by your customers, staff and partners to apply for products and services.
Key capabilities include:
- perform complex calculations
- dynamically display content as it is required
- perform sophisticated validation of the data
- lookup data from remote systems
- securely submit the data to your organisation’s systems
Geneaology of the Electronic Form
Not all electronic forms are equal. They differ in how smart they can be in making it easy for users and ensuring that you capture high quality data.
Electronic forms can be categorised into:
- Print form downloaded from your web-site, printed, completed by hand and posted/faxed to your organisation
- Fillable form downloaded from your web-site, filled-out on screen before being printed and posted/faxed to your organisation
- SmartForm downloaded from your web-site, filled-out on screen and submitted electronically
Print Form
The only electronic aspect to this is in its distribution. You face the same challenges as paper of interpreting hand-writing, handling forms that have been incorrectly filled-out and manually entering the data into your systems. According to the Australian outsourcing company review of 2006, 40% of forms contain missing information. Each of these failures result in higher costs and lost sales opportunities
Fillable Form
Fillable forms perform basic validation on the data as it is entered and will print an easy to read form. You will typically need to re-key this data into your back end systems. Optical character recognition (OCR) is feasible with fillable forms if you have the necessary infrastructure.
SmartForm
The most significant development in electronic forms since their inception. For the first time, it is now possible to guide novice users through the completion of complex forms in a highly engaging experience.
SmartForms presentation at BFMA
I was happy to accept an invitation to present at the BFMA region 8 September meeting.
I chose to talk about SmartForms; I described some of the innovative work that has been performed in Australian government over the last four years and shared some lessons learnt from the Red Tape Blueprints project that was delivered for a consortium of 41 NSW councils.
I ran the webinar on Adobe Connect and present the full recorded session below in four parts:
-
Part 1: What is a SmartForm? Demo of discovering a SmartForm Demo of filling out a Smartform Demo of user’s submission history -
Part 2: Why should you care about SmartForms? Demo of eForms benefits calculator Leading SmartForm projects in Australian government Introduction to Red Tape Blueprints case study -
Part 3: Red Tape Blueprints solution Red Tape Bluepirnts challenges overcome -
Part 4: Demo of SmartForm submission -
Part 5: Demo of providing attachments Demo of making payment Demo of signing a receipt
Part 1
Part 2
Part 3
Part 4
Part 5
About BFMA
BFMA, or the Business Forms Management Association, formed 50 years ago to address the unique educational and networking needs of forms designers and managers. With today’s technology, the forms function has broadened in scope to include everything from traditional paper forms to electronic data capture and the databases and applications that support it.
BFMA region 8 (Asia Pacific) is lead by Jessica Enders at Formulate.
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
From eForms to Climate Change
One of the benefits of eForms over Paper Forms is a reduction in the use of paper (seems obvious). But when you look at how much of a climate change impact this can have – it’s surprising. Using data from the Environmental Protection Agency in Queensland Australia that using 1 ream of paper equates to 6% of a tree, 5.4kg of CO2 and 160 litres of water, Avoka have developed an eForm Benefits Calculator that calculates the environmental, cost and customer service benefits of replacing paper forms with eForms.
A core service offering from Avoka is the development of electronic forms (we call them “SmartForms“) … interactive PDF, Flash or HTML forms for structured data capture. Typically these SmartForms replace paper or static PDF forms within organizations and the clients for these solutions are medium-large businesses and Government agencies. They usually deal in tens, hundreds or thousands of different forms and many receive millions of form submissions each year.
Traditionally, the motivation for the creation of SmartForms is improvements to customer service, reductions in operating costs and increased revenue through improved sales order processing. But what about the environmental impact?
I received an email from the Environmental Protection Agency in Queensland Australia with one of those “think b4u print” messages at the bottom, which was backed up with data. Namely:
“Think B4U Print
1 ream of paper = 6% of a tree and 5.4kg CO2 in the atmosphere
3 sheets of A4 paper = 1 litre of water”
Based on this data, we decided it would be interesting to develop a calculator (eForm Benefits Calculator) that provides estimates on the benefits to an organization when replacing paper forms with SmartForms…with the benefits grouped in to 3 distinct categories:
- Environmental Impact
- Cost Savings
- Customer Service improvements
Based on the user entering 2 pieces of information in the calculator
- Forms – Number of forms processed per year
- Pages – Average number of pages per form…
we calculate the savings as follows:
Environmental Impact:
Assuming the Forms x Pages = pages consumed, and a ream of paper = 500 pages. We calculate the amount of CO2 produced, number of trees removed from the environment and water consumed in the manufacturing of that total number of pages.
We then convert the water and trees in to CO2 figures as follows:
- Using 1,100 litres of water is equivalent to 1 kg of CO2 in to the atmosphere (not that water isn’t valuable in its own right)
- 1 tree can remove 3 kg of CO2 from the atmosphere per year
By brining all the environmental benefits back to a CO2 number, we can calculate a single Climate Change figure represented by the size of the Green Footprint – the more potential savings, the bigger the footprint.
Cost Savings:
Based on research from a business process outsourcing company on the operational cost of processing paper forms (e.g. data entry, rework due to missing information, searching for misplaced documents, etc) and using a flat fee of $40 per hour for administrative staff, we’ve calculated the work time that can be saved when an organisation avoids dealing with paper…no data entry, no rework, no misfiled documents, etc. This is shown as a straight annual dollar saving.
Customer Service:
Based on the same outsourcing company’s research into paper form processing, we’ve estimated the reduction in the processing time for a request initiated with a form. Given that 38% of paper forms have incorrect information or are missing required information (from the same outsourcing company study), organizations have to get back in touch with the customer to get that information. When combined with data entry time etc. the total delays that can be avoided averages out to be 48 hours. So if your company operates 24×7, you can get back to a customer 2 days faster. If you operate 9 to 5, you can respond 6 days faster. This equates to more rapid customer service.
Summary
If your organization was to replace 500,000 form submissions with an average of 4 pages per form with eForms, the ANNUAL savings would be in the order of:
- 21,643 Kg of CO2
- 667,332 litres of water
- 240 trees
- $13m in operational costs
- Reduction in customer response times by 48 hours.
Try the calculator for yourself…
Note:
The calculator is not designed to be exact or exhaustive…it’s more of a rough estimate, but with some science to back it up. For example, we purposely haven’t factored in additional power usage requirements for filling in a form online using a computer as:
(a) It is probably balanced by the power usage to download and print (printers are power hungry!) a static PDF from a website
(b) Computers tend to be on during the day – this way they’re being used productively
(c) Other savings like emissions associated with transporting paper in mail vans etc. haven’t been included
(d) You get the picture…it gets complicated pretty quickly.
This is our first calculator and there’s probably room for refinement. We’d be happy to receive suggestions on enhancements – please post your suggestions here.
Tour de LiveCycle Launched
Over the past several months we have been working with the Adobe Evangelist Team to create Tour de LiveCycle, a desktop application designed to explore the capabilities of Adobe LiveCycle Enterprise Suite.
After the success of Tour de Flex it was felt that a similar style AIR application would be an ideal way to allow users to explore the wide range of features and services provided by the LiveCycle ES Platform. There are over 2,000 pages of content, videos and sample applications. Whether you plan to spend 10 minutes getting a feel for what LiveCycle ES is all about or you need to build a full application with LiveCycle ES, Tour de LiveCycle can help.
Tour de LiveCycle is built on Adobe AIR and will run on Windows, Mac and, Linux. All of the content is hosted and downloaded on demand – the installer is only about 1.5MB.
Managing the size of your LiveCycle database
A user on the Adobe forums, recently posted a comment about noticing that his LiveCycle database was increasing rapidly over time.
http://forums.adobe.com/message/1934388#1934388
You may have noticed the same with your own database, as well as the size of the Global Directory Storage, particularly if you’re running larger numbers of long lived processes involving users.
It turns out that quite a big chunk of this data is temporary data, that doesn’t really need to be kept around after the process has completed. Luckily, there are a few ways in which you can remove this data.
1. You can use the Adobe PurgeProcessTool.
This tool completely deletes all trace of processes that meet a particular criteria (usually, they must be comleted, and older than a certain date). After you run the tool, that process and all its data will be gone – there is no record that it ever existed. You can find a batch file (modify for Unix) at: C:\Adobe\LiveCycle8.2\LiveCycle_ES_SDK\misc\Foundation\ProcessPurgeTool
Note: We recommend you only purge process types that you have created and make sure you test this in your Test machines before you activate in in Production.
2. You can use the Avoka purge tool.
The Avoka tool takes a slightly different approach. It leaves the old processes intact, but removes a whole lot of superfluous information that is stored along with the process instance. It removes:
- The data associated with certain internal data structures. This data accounts for the vast majority of the size associated with process instances, and is generally completely superfluous. (The only exception is if you’re invoking processes programmatically, and polling for the results.)
- Optionally, the data associated with attachments within Workspace. It doesn’t remove the record that there was an attachment, but if you try to download the attachment, it will be a zero byte file. Note that any attachments are duplicated at every single user step, potentially resulting in very large data in the database.
Our general recommendation is to use both tools:
- Use the Avoka Purge Tool on a weekly or even daily basis. This means that you can still search and track historical processes, maintaining audit trails – it doesn’t delete the whole process, just the unneccessary data associated with each process.
- Quarterly or annually, use the Adobe purge tool to remove all traces of processes that completed in the previous quarter/year – providing you don’t want those records for historical analysis. Ensure that you have a backup of the database before you do this.
One of our recent customers had reached a database size of 50GB, and was running out of capacity. By using the Avoka Purge Tool, we were able to reduce the database by 80%, without any loss of historical process data.
The bottom line is that the Avoka Purge Tool will dramatically reduce your database size, without removing your ability to search and track historical process instances.
http://www.avoka.com/avoka/purge_util.shtml