| Oracle® Business Intelligence Enterprise Edition Help 11g Release 1 (11.1.1) |
|
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 Oracle BI EE or other applications. You must also be aware of features that are specific to Oracle BI EE 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 include:
HTML content automatically equals accessible content.
Accessible tools automatically create accessible content.
Automated testing tools can reliably determine accessibility.
None of these assumptions, however, 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 end that users do. As a result, they 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.
When configuring or creating content for dashboard pages, consider the following best practice recommendations:
Refrain from using tickers, because they are not supported.
When saving dashboards, ensure that you save them in appropriate locations so that they are easily accessible to users. See "Saving Dashboards By Other Names and In Other Locations" for information on appropriate locations.
Reduce the interactivity and the complexity of pages. For example, restrict the number of prompts and drop-down menus, do not use the drill-inline feature for sections, and configure tables to show as many rows as possible.
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:
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.
Oracle BI EE dashboards use style sheets to set standard display definitions. Ensure that these style sheets consistently use font selections that magnify well. That way, content creators automatically default to using fonts that are accessible.
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:
http://www.paciellogroup.com/resources/contrast-analyser.html
This site offers a tool for viewing how a web site is displayed for individuals with various types of color vision deficiency:
Use the guidelines in the following sections for designing accessible dashboards:
Use the following guidelines to promote a consistent structure for dashboards:
If multiple dashboards contain similar functions or content, then keep those links or forms in the same place on all dashboards.
Use the same text and labels for buttons and links that have the same functions or destinations. When graphical elements are used to identify controls, status indicators, or other programmatic elements, ensure that the meaning assigned to each graphical element is consistent throughout the pages of the dashboard.
Associate the same text with icons and other graphics that are used for the same functions. Graphics cannot be read by assistive technologies, and low-vision users might be unable to discern the meaning of a graphic. Therefore, all graphics must have additional text to describe the functionality.
Graphics must have "ALT text," which is descriptive text associated with the graphic that adequately describes its purpose. This alternate text is specified using the ALT attribute for the element in HTML code. Even if a graphic is present for aesthetic purposes and has no functional value, then you must still specify null ALT text (alt="") for its element so that screen readers know that the text should be skipped.
For other graphical elements that do not support creation of ALT text, you should include text fields at the top or side to denote functionality, such as "Select a Display View Below."
Try to keep dashboard pages simple. Do not try to include too many objects on one page. Include multiple pages that are easy to navigate rather than one page that is cluttered and difficult to navigate.
Use the following guidelines to enhance on-screen content for dashboards:
As you do in graphs to promote a high color luminosity contrast ratio, do not use colored or patterned backgrounds for dashboard pages.
Use styles that support high contrast between the background and the text, both in the dashboard header area and in the tabs on multi-page dashboards.
Place the most important content at the top of the page so that users of screen readers can access that content without having to navigate the entire screen.
For displays that are inherently visual, such as interactive GIS maps or audio-video feeds, no method might exist for making these elements directly accessible. When you deploy this kind of content, you must also provide a text-based equivalent display of the same information with similar interaction capabilities. Typically this means either creating an equivalent table or pivot table of the related data (if applicable), or providing a caption and text description for audio-visual content.
Dashboard pages generate explanatory text for objects based on their description fields. Ensure that each analysis that you create includes a short description of its functionality. You specify this description in the Description field of the "Save dialog" for the analysis.
The set of styles and skins that are available for the Oracle BI EE system controls the overall look and feel of any dashboard. You can work with styles and skins for accessibility, as described in the following sections:
You can create custom styles and skins to implement standard settings that support accessibility, such as default font selections, high-contrast color schemes, and so on. You can start by copying and modifying the default styles. By modifying these files, you can select default colors, contrast, and fonts that can benefit users with certain disabilities.
You can set a default style for all dashboards and you can also select a style to apply to an individual dashboard. You might want to create a set of dashboards with content that is specifically optimized for users with accessibility needs. You might also want to apply a special "accessibility" style to one or more individual dashboards for those users who need it.
You specify a style on the "Dashboard Properties dialog" for a particular dashboard.
Certain features should not be used at all, such as elements that blink with a frequency between 2Hz and 55Hz, or that use excessive animation (such as a "stock ticker" display widget). Ensure that you are familiar with all legally mandated design prohibitions that apply in your locality and avoid including those elements on dashboard pages.
 Previous |
 Next |
Copyright © 2010, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
 Contents |