This appendix describes techniques for designing reports to increase accessibility of report output for users with disabilities. Accessibility support is for HTML output only.
This appendix includes the following sections:
When creating content for consumption by a wide variety of users, you must plan to provide support for users with various disabilities. Such support is a legal requirement in many locations throughout the world.
You can follow several general guidelines when designing content for consumption by a variety of people with differing abilities. These guidelines apply to any content that you create for BI Publisher or other applications. You must also be aware of features that are specific to BI Publisher that ensure that the content that you provide supports accessibility requirements.
This section contains the following topics on designing for accessibility:
You can locate information about accessibility across the Information Technology industry in numerous published books.
This guide does not intend to duplicate those works. Various standards and legislation are documented, especially as part of the World Wide Web Consortium (W3C) and Section 508 of the United States Rehabilitation Act.
Many designers make assumptions about technology and accessibility. Some of the more common misconceptions are listed in this section.
HTML content automatically equals accessible content.
Accessible tools automatically create accessible content.
Automated testing tools can reliably determine accessibility.
None of these assumptions is correct. Developers can create non-accessible content using HTML. A tool that can produce accessible content might not do so by default, or might allow a developer to select options that turn off the accessible features within existing accessible content. Automated testing tools do not always interact with content the same way that end users do. As a result, the tools can erroneously report accessible elements as non-accessible. Therefore, accessibility is ultimately the responsibility of the content designer. When creating content, designers must be aware of certain common practices to ensure the content is accessible to all users.
Always consider the fact that multiple disabilities exist and that multiple disabilities might manifest in the same individual. You must also remember that there are varying degrees of certain disabilities (such as the various types of color vision deficiency). Your designs must take all these possibilities into account.
This section contains guidelines on the following general areas of design:
Many different types of color vision deficiency exist, from an inability to see the difference between one common color pair such as red-green (the most common deficiency), all the way to full color blindness where a person can see only varying shades of gray and black. Using only color to convey critical information means that certain users are not fully aware of all the pertinent information about a subject. And, of course, a blind user needs any information conveyed by color to also be present in an alternate textual format.
As a developer, you must not create any content that provides key information by color alone. One example of a non-accessible design is to denote negative numbers solely by coloring the text red. Another example is a typical "stoplight" indicator where the only context information comes from its color — green for good and red for bad.
You can use color in designs if you also include another indication of the same information.
For example, you can include a minus sign or parentheses to denote negative numbers in tables and pivots. For stoplight displays, you can add descriptive text or different shaped icons in addition to the color. You can include text such as "Status: good." You can include green circles for "good," yellow triangles for "warning," and red octagons for "bad."
Because color vision deficiency can also manifest as an inability to distinguish between subtle shades of similar colors, overall color design of all screen elements must provide a large amount of contrast. You should strive to achieve a minimum of a 4.5:1 color luminosity contrast ratio. For example, use black text on a white background instead of dark gray text on a light gray background.
You can check the following web sites for assistance:
This site offers a tool that can test for the proper level of contrast:
This site offers a tool for viewing how a web site is displayed for individuals with various types of color vision deficiency:
Users with low visual acuity often use screen magnification software to make the screen easier to read. The fonts that you use should be readable even when magnified by accessibility tools by as much as 20 times.
Some fonts do not display well when magnified, while others do. For example, the Tahoma font magnifies well.
You use the Template Builder for Word to create RTF templates that can generate reports with accessibility features.
The Template Builder also provides an accessibility checker to review the template for features that enhance the accessibility of the report for report consumers who may need assistive technologies to view the report.
For more information, see Checking Accessibility.
This section describes the following techniques for designing reports using RTF templates. Accessibility support is for HTML output only.
Avoid using nested tables in a report. For a complex report, try breaking down complex tables into several simple, straightforward tables.
The following figure shows a simple table.
The following figure shows an example of a nested table: A table is inserted inside a table-cell.
These are examples of table structures that BI Publisher does and does not support for accessibility.
BI Publisher does not support accessibility when nested tables are used in a report.
In the following illustration, BI Publisher cannot tell to which column data "C1R1data" belongs.
Remove the nested table as shown in the following illustration.
To ensure accessibility, table headers must be part of the table they belong to.
The example shown in the following illustration is not supported because the header, table body and accessibility fields exist in three different tables.
These three tables should be joined into one to support accessibility, as shown in the following illustration.
You can define a document title. The procedure differs slightly depending on the version of Microsoft Word.
To define or change a document title in Microsoft Word 2007:
Click the Office button, click Prepare, and then click Properties.
To define or change a document title in previous versions of Word:
To define alternative text for an image in the template:
In versions of Word prior to 2007, enter the alt:text syntax on the Web tab.
Add a table summary to a table by inserting this command.
<?table-summary: 'My Table Test '?>
in the first column and first row position of the table.
You can define a table column header. The procedure differs slightly depending on the version of Microsoft Word.
To define a table column header in Word 2007:
Select the heading row or rows. The selection must include the first row of the table.
On the Design tab, in the Table Style Options group, select Header Row.
Right-click the table and select Table Properties.
In the Table Properties dialog, click the Row tab and then select Repeat as Header row at the top of each page.
To define a table column header in previous versions of Word:
To define multiple row headers, use the BI Publisher command.
<?acc-row-header:'1,2,4'?> ==> column 1, 2 and 4 will be row-headers.
<?acc-row-header:'1,4'?> ==> column 1 and 4 will be row-headers.
In the following figure, the code behind the ACC field is:
ACC Field=<?table-summary:'My Table Test '?><?acc-row-header:'1,2'?>
which defines the first two columns as row headers.
The following illustrations display sample tables for which accessibility is supported.
Charts and gauges are not readable by the visually impaired. In order to make report output accessible for visually impaired users, create a table or cross tab that summarizes the data in the table.
The following figure shows the summarized data in the table. Ideally, the data is summarized at the same level as it is in the chart. Avoid providing a large table of detail data that is not summarized appropriately.
This section describes the following techniques for designing accessible reports using the BI Publisher layout editor.
You define the title of a report at the same time as you save the report layout. You can also rename the report at a later time.
You can define alternative text for images so that they are describable in accessibility mode.
To define alternative text for an image:
You can define a text summary to describe a table within a report.
To define summary table text:
Table row headers summarize each row in a table. The layout editor automatically includes table row headers on all inserted tables. No further action is required.
You can define text header levels to specify structures within a report.
To define text header levels:
You can use layout tables to present information in columns and rows and arrange content without using headers and a table summary.
<?table-summary:?>in a table, BI Publisher sets
role=”presentation”for that table, and specifies that table as a layout table in the HTML output.
To define a layout table: