Creating Accessible Enterprise Reports using Oracle9i Reports

April, 2002

Building Accessible Reports With Oracle9i reports
Oracle's goal is to ensure that products and services are accessible to the disabled community. Since industry standards for accessibility will continue to evolve over time, Oracle is actively engaged with other market-leading technology vendors in addressing technical hurdles. Accessibility solutions for the disabled community have become mainstream productivity enhancements.

This paper provides guidelines that will aid in using Oracle9i Reports for creating accessible Enterprise Reports It addresses reporting environments that make significant use of Web technology for distributing reports. It focuses on the visual aspects of accessibility in enterprise reporting, and how Oracle9i Reports can help you to achieve this goal.

In addition to HTML enhancements for accessibility, Adobe Acrobat PDF files have new accessibility features. To leverage these features, you must use Acrobat Reader 5 or later. Only these versions have implemented the Microsoft Accessibility API, implemented, which is the basic requirement for communication to assistive products, such as the JAWS screen reader from Freedom Scientific.

Building accessible WEB Publications

General Principles

Reporting is the representation of data in a visually clear and easily understandable way; therefore this paper focuses on resolving visual barriers. Barriers in auditory or mobility may also exist, but these are outside the scope of a typical report.

A report that meets these criteria for the majority of users may be unusable or difficult to use for people with visual impairment.

Within the group with visual disabilities we can create two broad areas:

  1. Users with limited visual capabilities
  2. Users with no visual capability

These two user groups require different levels of visual representation for a report. While the first group is able to use some sort of a visual approach (with different levels of detail), the group with no visual capability relies on the representation of the screen content via a screen reader and/or a Braille keyboard or other devices.

Oracle9i Reports offers the capability of creating highly customized HTML output that better supports screen readers by using the JSP-based Web output introduced in Oracle9i Reports.

The examples in this paper utilize the HTML accessibility features. We describe the effect, but not all features are implemented with the available assistive tools yet. We use JAWS (by Freedom Scientific), a commonly used screen-reader, for the purpose of this paper.

Design Considerations for People with Limited Visual Capabilities
When considering visual modifications on Web pages, you must address the problem of browser independence. The examples in this paper follow the W3C suggestions and guidelines (Web Content Accessibility Guidelines and Checkpoints for WCAG), but might not produce the same results in every (especially order) Web browser due to different levels of implementation.

When designing a report for users with limited visual capabilities, it is very important to keep in mind that they might be using special kinds of browsers, specialized for enhancing the visual appearance (e.g. zooming, high contrast) and that do not render a Web page like browsers such as Internet Explorer would. Some of these special browsers may only render the text without any color and font attributes, to satisfy the user?s need for high-contrast or magnified output.

These special browsers take advantage of ALT or LONGDESC attributes that are available in IMG tags to create text equivalents of the image instead of rendering the image itself.

STYLE SHEETS
Oracle9i Reports HTML output and the JSP-code created by the wizards in the Web source take advantage of Cascading Style Sheet (CSS) definitions to create a high-fidelity report of your data. Information only represented visually (e.g. values above or below certain boundaries with different background colors) cannot be interpreted by assistive technology (e.g. screen readers). From a page design point of view, the information must be usable with or without the Cascading Style Sheets. You can do this using a hyperlink on the text, image , and table cell, or by directly entering text into the Web page.

Current operating systems, like Windows 2000, already offer tools like Magnifier that create a magnified view of the screen and enable the user to use the available browsers to view HTML documents. Even with these tools, however the use of a color scheme may still be a problem. Users can toggle the use of style sheets or even configure Internet Explorer to use a specific one instead of the one defined in the page. It might be useful to create a downloadable style sheet of your report for accessibility testing, which you can then provide to your users.

Using Tables
There are many limitations on tables in accessible documents. The limitations are specified so that the screen reader utilities can read the table content.

In most cases, table headings are visually separated from the data using background colors and/or text attributes. These attributes cause the tables to be unreadable if viewed using text-only browsers or the page is displayed without style sheets. To avoid this problem, you can use the <TH> tag for the heading and thus enable the headings. This tag allows headings to be separated from cell data.

HTML provides attributes (ID, HEADERS) for the <TD> and <TH> tags so you can cross-reference table and column headings from a table cell. Doing so allows you to define heading-cells for each data cell in a table. There are examples on how to use attributes later in this paper.

Design Considerations for People with No Visual Capabilities
Designing reports for people with no visual capabilities is even more challenging than that for people with limited visual capabilities. The report designer can use visual attributes (like background colors, styles, text colors) to encode information, but must keep in mind that every visual attribute must be backed up by text or a link that can be picked up by a screen reader.

In general, all guidelines mentioned for people with limited visual capabilities apply to users that utilize screen readers as well. In addition to these items, there are several coding characteristics that can influence the way a screen reader presents the HTML document.

Use ALT or LONGDESC attributes
Screen readers and other assistive utilities cannot interpret images. It is important that you use the ALT attribute to provide a text equivalent of each image.

There are some other elements in HTML that also provide the ALT attribute. Use this attribute wherever the element is a visual representation of information that otherwise would be lost.

Use the LONGDESC attribute to point to a long description using a URL. One possible usage of this attribute could be to point to a tabular representation of the data used by a graph in the main page.

<IMG LONGDESC="ThisImage.html"

     ALT="This is an image"

     SRC="image.jpg"

 

Oracle9i Reports offers you a property called Alternative Text (HTML) for objects like graphs and file links (of type image) to populate the ALT attribute.

Graphs
If your report is using Reports' integrated graphing solution, you can use several different elements to enhance the accessibility of your graph.

ALT text for the graph-image-tag

By using the alternativeText attribute of the <RW:GRAPH> Reports JSP tag in the Web source or the Alternative Text Property in the Paper layout, you can specify an alternative text that will populate the ALT attribute of the graphs <IMG> tag.

<rw:graph id="myGraph"
          ...  
         
alternativeText="Overview-Graph">
...
</rw:graph>

ALT attributes for the Graph Hyperlink Image Map
In order to provide description for e.g. the bars in a bar-graph (for example), you can use the "Show data tips when mouse is over bar" checkbox on the Plot Area tab of the Graph Wizard.

Selecting this will trigger the graph to contain ALT attributes for all elements of the client-side image map, which is used to generate the hyperlinks.

Alternative representation

Another way of representing a graph for accessibility is a text representation of the data behind the graph. Using the Graph Hyperlink property you can create data-driven hyperlinks that could even branch off to another report that dynamically generates the tabular representation of the data presented in the graph.

<rw:graph id="myGraph"
          ...  
          graphHyperlink="/details.jsp?deptno=&deptno;">
...
</rw:graph>

You can use lexical parameters to populate the hyperlink at runtime with dynamic data, or even make the complete hyperlink dynamic.

Cell labeling in tables

HTML offers several different ways to create cross-references from a table cell to its corresponding heading text.

The SCOPE attribute of the <TH> element defines this heading to be the header for every cell in the relevant column or row. This attribute has no impact on the visual representation of the table. It is only used to provide assistive utilities with header information for each cell so navigation within the table can be made easier by exposing (i.e. reading or displaying) the headers for each cell to the user.

In most cases, tables used for reporting are complex and therefore require different ways of referencing the associated heading information for each cell. To address this requirement, there are two additional attributes that apply to the <TH> and <TD> elements.

ID and HEADERS enable you to cross-reference cell content to represent explanatory information for a cell value. In case you want to create a shorter spoken version of the heading value, use the ABBR attribute. With this attribute you could, for example print "EMP. NAME" but force the assistive utility to use "NAME" (by using abbr="name") as it is easier to understand.

<TABLE>
<TR>
<TH ID="HeadCol1" ABBR="Column 1">
Heading for Column 1
</TH>
<TH ID="HeadCol2" ABBR="Column 2">
Heading for Column 2
</TH>
</TR>
<TR>
<TD HEADERS="HeadCol1">Data 1</TH>
<TD HEADERS="HeadCol2">Data 2</TH>
</TR>
</TABLE>

For further details about the accessibility enhancements of HTML and PDF and for detailed examples, visit at http://www.w3.org/WAI/, http://access.adobe.com/ or http://www.access-board.gov.

Coding reports for accessibility
Creating accessible reports requires you, the designer, to keep in mind the requirements of users with low or no visual capabilities. With some of the previously mentioned requirements you are limited using Oracle9i Reports, but the color/contrast/font size considerations can also be addressed in earlier versions of Oracle Reports.

Accessibility for the Paper Layout
To create the required information for accessibility, Oracle9i Reports offers a series of additional properties in the Property Inspector. For an overview of these properties see Appendix A1-- Accessibility Properties.

Images
Oracle9i Reports has the Alternative Name property for objects like graphs and file links (of type image) to populate the ALT attribute.

Tables
Besides the simple tabular report, a data-cell can have at least two heading references. To provide reports with this information, you have to set the properties found under the Accessibility heading of the Property Inspector.

These properties are used by Reports when generating the output. Due to technical restrictions, accessibility will only be provided when using PDF as the destination format. In this case Oracle9i Reports generates the appropriate information for assistive technologies.

If you want to use PDF as your preferred output format, your users must use Acrobat Reader 5 or later. Only these versions have the Microsoft Accessibility API implemented. This API is the main interface between assistive utilities and your browser or plug-in. The PDF generated by reports will leverage the extensions for accessibility made in Version 1.4 of the PDF, which is implemented in Acrobat Reader 5.

Accessibility using the JSP-based Web layout in Oracle9i Reports

Oracle9i Reports offers you a new paradigm for data publishing, a JSP-based approach where you insert custom tags into HTML to populate it with data.

When using the Report Block Wizard, the generated HTML code will follow the requirements of the WCAG 1.0 for supporting assistive utilities.

The wizard creates the necessary attributes inside the tables structure to ensure the linkage between the data cells and the headings using the ID-HEADERS approach. This method was chosen because the table object generated by Reports is too complex for the SCOPE attribute.

With multiple headers, the generated HEADERS attribute will also reference the headers of the row header columns or group values.

For example, a Group Left report might look like this:

Department Name Sal Comm
10 Smith 1000 100
  Jones 2000  
20 Jake 2400 200

In this case, the assistive utility reads "DEPARTMENT 10 NAME SMITH ... " and "DEPARTMENT 10 NAME JONES ...". This is achieved by the generated HEADERS reference to the cell containing the column-header (NAME) and the cell containing the row-header (10) as well as the cell containing the header for the row-header-cell (DEPARTMENT).

This technique might not work for every grade of complexity. Therefore you should keep reports you want to make accessible as simple as possible.

Design considerations for Parameter forms
For reports that require input from the user, Oracle9i Reports utilizes parameter forms. If you run a report to paper output, the parameter form is created according to the parameters you defined in the report.

If you use the JSP-based Web layout, you must create the parameter form manually. This form then invokes the report passing the user-input to the report. You can also use this method if the automatically generated parameter form does not fit your needs.

In either case, the manually generated form has to make sure that the labels associated with an input field are marked-up correctly so that assistive utilities can keep track of fields and associated items. HTML4 offers you the <LABEL> element for that. With the <LABEL> tag you can define which control this label should be assigned to and which access key should be assigned.

<FORM ...>
<LABEL FOR="Input1" AccessKey="1">
Input Field 1
</LABEL>
<INPUT TYPE="TEXT"
ID="Input1"
NAME="InputField1"
/>
<LABEL FOR="Input2" AccessKey="2">
Input Field 2
</LABEL>
<INPUT TYPE="TEXT"
ID="Input2"
NAME="InputField2"
/>
...
</FORM>

The values used for the ID attributes across the HTML document have to be unique, as they are used to address an object within the Document Object Model (DOM) regardless of its type.

Making existing reports accessible

Earlier versions of Oracle9i Reports only had the notion of paper reports. These reports could be generated into PDF, HTML or HTMLCSS to make them viewable on the Web.

These destination types were designed to create a representation that closely approximated the appearance of the printed report output. To achieve this, the objects have to be positioned on the screen according to the report definition. This was the only way to produce an output that approximates printed output. Unfortunately, this causes problems when trying to access these outputs using tools like screen readers because the HTML that is produced is not readable by these tools.

There are multiple ways to make your existing reports accessible. Besides re-creating them as a JSP-based Web report, Oracle9i Reports offers you properties in the paper layout to provide relevant information that is then used when creating the PDF representation.

If the overall layout of the report is very complex, generating an accessible paper report may not be possible. To resolve this problem, you may want to create an accessible version of such a report, using the same data model but generating a JSP-based web report instead.

Including Objects from the Paper Report into you Web Source

Oracle9i Reports allows you also to include objects from the Paper Layout into your JSP-based Web layout using the reports custom tag <rw:include .../>.

At runtime this tag renders the selected object in HTML and insert the generated HTML code where the <rw:include> tag was placed. During generation the specified accessibility properties are taken into account to generate accessible HTML. These are the same properties you set to generate accessible PDF documents. Some properties are exclusively for this HTML rendering (Table-Caption, ID, Headers) and have to be set in order to have accessible HTML. You then simply add <rw:include> in your WebSource.

...
<rw:include id="myPaperObject" src="R_RepFrame"/>
...





The ID holds a unique identifier for this tag. SRC points to the top-level object you want to include. RW:INCLUDE can only access objects that are in the first hierarchy level under the body or margin node of a section in the Object Navigator.

Enabling the accessibility features
To provide a flexible environment, the runtime accessibility features can be triggered on a per-report basis.

By default, they are turned off. To turn them on, you have to use the command line parameter ACCESSIBLE=YES at report execution.

At design time, you have to start the Oracle9iDS Reports Builder with this parameter in order to have the accessibility features enabled for Run to Web and Run to Paper.

This command line parameter only triggers the way RW:INCLUDE and the PDF driver generate their output. The custom-tags <RW:ID> and <RW:HEADERS> are not affected by the setting of the ACCESSIBLE parameter

CONCLUSION
Accessibility is an important factor that has to be considered at the beginning of the report design process. Users with disabilities and users without should be served equally well. In some cases it will not be possible to create one report that achieves that. Oracle9i Reports allows you to create two versions of your report, the high fidelity enterprise report and the accessible version in a single file, using the same data model.

In addition, you can generate accessible PDF documents out of your paper layout to provide accessibility for existing paper reports.

Oracle9i Reports provides you with the technology to add accessibility to your enterprise reporting efforts.

Appendix

A1 -- The Accessibility Properties
To retrieve the information required to generate accessible output, a few new properties for the paper layout objects must be provided.

Alternative Text
For non-text objects (e.g. file-links of type image, boilerplate elements like rectangles, ?) to provide the text for the ALT attribute of the IMG tag.

ID
This is the value of the ID attribute used for referencing the value of the element in the HEADERS attribute. If your headers are data-driven (e.g. in a matrix report) you can use lexicals to produce unique headers. (This functionality is not directly supported by PDF. The Oracle9i Reports PDF driver creates additional information to create an effect similar to this functionality in HTML)

Table Caption
The property defines on a frame-level the value for the caption element of a table.

HEADERS
Here you can specify the IDs that should be referenced as the header for this particular cell in the table.

Parameter forms
For parameter forms there are two accessibility properties:
Label for
This property is available for boilerplate objects and is used when generating the <LABEL> tag to cross reference the parameter field.
Access key
This property specifies the value for the AccessKey attribute of the LABEL element. It is defined on the boilerplate-text level and only has effect when the LABEL FOR property is used.


...
? <tr>
<th <rw:id id="HBDEPTNO" asArray="no"/> > Deptno
</th>
<th <rw:id id="HBDNAME" asArray="no"/> > Dname
</th> <th <rw:id id="HBLOC" asArray="no"/> > Loc
</th> </tr>
...
<tr> <td <rw:headers id="HFDEPTNO" src="HBDEPTNO"/> >
<rw:field id="F_DEPTNO" src="DEPTNO" ...
</td>
<td <rw:headers id="HFDNAME" src="HBDNAME"/> > <rw:field id="F_DNAME" src="DNAME" ...
</td>
<td <rw:headers id="HFLOC" src="HBLOC"/> > <rw:field id="F_LOC" src="LOC" ...
</td>
</tr>
...

The RW:ID generates a unique ID within the specified Reports JSP and is automatically bound to a repeating-group if necessary. The RW:HEADERS tag generates the HEADERS attribute for the cross referencing. By passing more than one name in the SRC tag you can create more complex structures.

Example:

<rw:headers id="HFEMPNO" src="HBEMPNO, HBDEPTNO, HFDEPTNO"/>

A3 -- Quick Reference
The following section contains a brief description of how Oracle9i Reports supports specific accessibility criteria. Where conformance with these criteria is a matter of the report design, rather than provided features, it is marked as Design Issue.

(a) A text equivalent for every non-text element shall be provided (e.g., via "alt", "longdesc", or in element content).
Oracle9i Reports provides the accessibility property "Alternate Text" (see A1 -- Accessibility Properties) for PDF generation. In the JSP-based layout, you have full control over the HTML code.

(b) Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation.
Design Issue - In the JSP-based Web layout you have full control over the HTML Code.

(c) Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup.

Design Issue - Depending on your report design you can add additional markers to indicate values. In the JSP-based report you can create links on specific elements that point to explanatory text.

(d) Documents shall be organized so they are readable without requiring an associated style sheet.
Design issue

(e) Redundant text links shall be provided for each active region of a server-side image map.
Design Issue - Generating PDF, there are no server-side image maps. When using the JSP-based Web layout it is a design issue to create these links if you choose to use a server-side image map.

(f) Client-side image maps shall be provided instead of server-side image maps except where the regions cannot be defined with an available geometric shape.

See (e) above.
(g) Row and column headers shall be identified for data tables.

Where possible, Oracle9i Reports uses <TH> to identify cells that contain header information.

(h) Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers.

As more complex reports require more sophisticated header mechanisms, Oracle9i Reports provides additional properties (see A1 -- Accessibility Properties) to specify this relationship in the paper layout. The Report Block Wizard generates the necessary HTML code for the JSP-based Web layout leveraging the custom-tag <RW:ID> and <RW:HEADERS> to generate unique IDs for the header cells and the HEADERS attribute for the data-cells..

(i) Frames shall be titled with text that facilitates frame identification and navigation.
Design Issue - This does not apply as PDF has no notion of frames. The use of frames in the Web layout is up to the report designer.

(j) Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz.

Design issue - As the JSP-based Web layout is not owned by Reports, you can add whatever style elements (animated GIFs, Flash movies, ...) you want. These are not under the control of Oracle9i Reports.

(k) A text-only page, with equivalent information or functionality, shall be provided to make a Web site comply with the provisions of this part, when compliance cannot be accomplished in any other way. The content of the text-only page shall be updated whenever the primary page changes.

Some reports might be too complex for the generated PDF to provide usable accessibility. In this case, you can use the JSP-based Web layout to create an accessible version. You can also use the CHARACTER destination-format to generate a text-only version of your paper layout. Either way, the content is generated in the same way as the original report will and therefore it is as current as the original report and therefore it is the same report, only the output format is different.

(l) When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.

Design Issue - The JSP-based Web layout is not owned by Oracle9i Reports. Therefore you can add whatever scripting you want. All Oracle9i Reports related scripting is server-side and therefore transparent to the user and the used assistive technology. Other client side- scripting added to the report by the designer is not under control of Oracle9i Reports.

(m) When a Web page requires that an applet, plug-in or other application be present on the client system to interpret page content, the page must provide a link to a plug-in or applet.

Oracle9i Reports' JSP-based Web layout does not require any plugins or applets. Elements that were added to the JSP page unrelated to Oracle9i Reports, requiring such technologies are not under the control of Oracle9i Reports.

For access to the PDF version of a report a plug-in (Adobe Acrobat Reader 5 or higher) is required.

(n) When electronic forms are designed to be completed on-line, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.

When Running the Paper layout of a report, a parameter-form might be generated. Oracle9i Reports provides additional properties that allow you to create a LABEL association between boilerplate text on the form and form-element such as field and selection lists. It will also provide the property Access Key for hot-key access to specific input elements.

(o) A method shall be provided that permits users to skip repetitive navigation links.

Design Issue

(p) When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.

Design Issue - Oracle9i Reports does not require timed responses in any way. If such a requirement was added to the JSP-based Web layout it is neither required nor under the control of Oracle9i Reports.
 

 

References

W3C -- Web Content Accessibility Guidelines (WCAG 1.0)
W3C -- Checkpoints for WCAG 1.0
US Section 508 Accessibility Standards (1194.22)



 

Accessibility in enterprise reporting using Oracle Reports
April 2002
Author: Philipp Weckerle
Copyright Oracle Corporation 2002
All Rights Reserved Printed in the U.S.A.


This document is provided for informational purposes
only and the information herein is subject to change
without notice. Please report any errors herein to
Oracle Corporation. Oracle Corporation does not
provide any warranties covering and specifically
disclaims any liability in connection with this document.


Oracle is a registered trademark and Enabling the
Information Age and Software Powers the Internet are trademarks
of Oracle Corporation.

All other company or product names are mentioned for identification
purposes only, and may be trademarks of their respective owners.


Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.

Worldwide Inquiries:
650.506.7000
Fax 650.506.7200


Copyright Oracle Corporation 1995
All Rights Reserved