Developing accessible applications for IBM WebSphere Portal 7.0.0.2 and 8.0

IBM® WebSphere® Portal 7.0.0.2 and 8.0 were developed and tested to be compliant with the Web Content Accessibility Guidelines (WCAG) 2.0. These versions of IBM WebSphere Portal neither enforce nor prevent compliance automatically. Knowing and understanding the requirements of WCAG 2.0 and incorporating them into your web applications is your responsibility. The suggestions in this article will help you understand what is already built into Portal themes and how to build accessibility compliance into your own applications.

Prerequisites for authoring accessible content

Understanding the four principles of accessibility

1. It is perceivable.
   To be perceivable, a web application must provide content and a user interface that allows assistive technology to find the necessary components and present them to the user. Providing text alternatives for images is one example of a perceivable component.
2. It is operable.
   An operable application can be run entirely from a keyboard, allows time-based and moving components to be paused or stopped, minimizes flashing elements, and provides easy ways for users to navigate through content and find their place.
3. It is understandable.
   An application is understandable if it provides ways for assistive technology to interpret the content in the native language, including any specialized terms. It also provides help for using the application and in recovering from errors. An understandable application also behaves consistently on similar pages, doesn't change the context without warning, and labels items in the same way throughout.
4. It is robust.
   A robust application is coded in a way that the tagging, naming, and properties for all components can be determined programmatically.

IBM WebSphere Portal 7.0.0.2 and 8.0 applications can be Level A or Level AA accessible, depending on the design choices you make. Level A is the minimum level of compliance. Level AA is a more rigorous level of compliance.

The dynamic content in Portal themes meets accessibility guidelines

1. Portal themes are perceivable.

Technique:
Use the “alt” text field for images to define a text alternative for an image.

Guideline:
1.2 Provide alternatives for time-based media.

Technique:
Portal themes do not maintain multimedia presentations by default. If you create a page with media, you must add the appropriate HTML to support the media.

Guideline:
1.3 Create content that can be presented in different ways (for example simpler layout) without losing information or structure.

Technique:
For images in High Contrast mode, alternative text is provided in the Portal theme.

Technique:
In the Portal theme navigation, text is provided for the help icon and IBM logo when in high contrast mode. The text is provided by a combination of css and a span. The following is defined in the css:


.wpthemeAltText { display: none;}

	.wpthemeImagesOff .wpthemeAltText {display: block;}



In the markup, the wpthemeAltText class is added in a span.
IBM Logo

During the loading of the page, a test is run to determine if the page is running with high contrast enabled. If high contrast is enabled, the wpthemeImagesOff attribute is added to the body tag class attribute. The text is displayed in the menu.

In the Portal 8.0 theme, support for determining if high contrast is enabled is provided in a module. The module id for this support is wp_theme_high_contrast. Information on the module framework support is documented in the WebSphere Portal 7.0.0.2 and WebSphere Portal 8.0 documentation.

Guideline:
1.4 Make it easier for users to see and hear content including separating foreground from background.

Technique:
The Portal themes meet the guidelines outlined in checkpoint 1.4. You are responsible for providing the proper code for any added content.

2. Portal themes are operable.

Technique:
A new menu framework was implemented for the Portal 7.0.0.2 theme. In the theme, the portlet context menu is implemented using this framework. This menu is used for the Actions menu as well.

The Actions menu is actually included in a span and in order to successfully navigate with a keyboard, additional handlers were added to the span. The actual menu itself also has focus and keyboard handlers to process the necessary keys for the menu. The code for the span is shown below:

var sectionElements = document.getElementsByTagName("SECTION");

	for (var i = 0; i < sectionElements.length; i++) {

	if (i$.hasClass(sectionElements[i], "a11yRegionTarget")) {

	var sectionRegionNode = sectionElements[i];

	var tempSpanNode = null;

	var tempSpanNodes = sectionRegionNode.getElementsByTagName("SPAN");

	for (var j = 0; j < tempSpanNodes.length; j++) {

	if (i$.hasClass(tempSpanNodes[j], "a11yRegionLabel")) {

	tempSpanNode = tempSpanNodes[j];

	}

	}

	if (tempSpanNode) {

	var spanRegionNode = tempSpanNode;

	var tempParentNode = sectionRegionNode;

	var regionNodeWindowID = null;

	// get window id

	while ((tempParentNode = tempParentNode.parentNode) != null ) {

	if (i$.hasClass(tempParentNode, "component-control")) {

	var m = tempParentNode && (tempParentNode.className || "").match(/id-([\S]+)/);

	regionNodeWindowID = m && m[1];

	break;

	}

	}

	if (regionNodeWindowID) {

	var ariaRegionId = "wpRegionId"+regionNodeWindowID;

	spanRegionNode.setAttribute("id", ariaRegionId);

	sectionRegionNode.setAttribute("aria-labelledby",ariaRegionId);

	}

	}

	}

	}

Guideline:
2.2 Provide users enough time to read and use content.

Technique:
You must provide a mechanism to pause, stop or hide any moving, blinking, or scrolling information. This is not built into the theme framework.

Technique:
There are options in the WebSphere Integration Solutions Console that control the session timeout. These values may be set to increase time for completing forms or accessing pages.

Guideline:
2.3 Do not design content in a way that is known to cause seizures.

Technique:
By default, the WebSphere Portal theme does not create blinking or flashing text.

Guideline:
2.4 Provide ways to help users navigate, find content, and determine where they are.

Technique:
The Portal Theme template uses landmark roles. These landmarks are used by assistive technology to enable a user to navigate a web page and find content. The table lists which landmarks are used in each of the 7.0.0.2 and 8.0 portal themes.

• *The navigation role is not explicitly placed on the markup element. Using the WAI-ARIA navigation region triggers the assistive technology to communicate the section of navigation links to the user.

Technique:
Include navigation elements. In the 7.0.0.2 and 8.0 Portal theme, the WAI-ARIA navigation landmark provides the primary page navigation content. This tag defines the section of navigation links. The navigation on the page is horizontal.

The Portal 8.0 theme also includes a side navigation template that can be applied to render pages at the secondary level. This template is applied to the Administration section of Portal. The side navigation is contained within a div with the role of navigation defined. If multiple navigation areas are defined on the page, you must ensure that each div that uses the landmark role has a unique label. For more information on the side navigation implementation, see the WebSphere Portal documentation.

There is a visual indication of which menu item is selected. To provide this information in a text format, the theme uses the following technique in the main menu.

A span contains the label for the currently selected menu item. This item is placed off the page, so the text is not visible, but assistive technology reads the text.

<span class="wpthemeAccess"> currently selected</span>

The markup for the WAI-ARIA support is shown below:

<div id="utb-shelf0P" class="" role="tabpanel" aria-labelledby="utb-shelf0" aria-hidden="false">

	<div id="utb-shelf1P" class="lotusHidden" role="tabpanel" aria-labelledby="utb-shelf1" aria-hidden="true">

	<div id="utb-shelf2P" class="lotusHidden" role="tabpanel" aria-labelledby="utb-shelf2" aria-hidden="true">

	<div id="utb-shelf3P" class="lotusHidden" role="tabpanel" aria-labelledby="utb-shelf3" aria-hidden="true">

Technique:
A typical WebSphere Portal page can have multiple portlets on a page. To ensure that each portlet on the page can be uniquely identified by the assistive technology, a WAI-ARIA role of "region" is added to the skin of each portlet.

When creating Portal pages using the Customization Shelf, portlets can be dropped on the page. Each of the portlets that are added to a Portal page has a skin assigned. The skins are templates applied around the portlet. To identify each of these content areas to an assistive technology, the WAI-ARIA region role and the attribute "aria-labelledby" are used for each skin.

Due to the dynamic processing of the page, a technique to uniquely identify the region was implemented. Attributes specific to Portal were added to the class definition of the skin: a11yRegionTarget and a11yRegionLabel. A JavaScript function was added that runs during the loading of the page that determines the id of the portlet. A unique id is generated for the region and replaces a11yRegionLabel and a11yRegionTarget with the definition of the WAI-ARIA label.

This code is included in the wp_theme_skin_region module.

In the skin.html, new attributes were added.

<section class="ibmPortalControl ... a11yRegionTarget" role="region" >

	…

	<span class="lm-dynamic-title asa.portlet.title a11yRegionLabel">



When the page is loaded, the following code runs:

var sectionElements = document.getElementsByTagName("SECTION");

	for (var i = 0; i < sectionElements.length; i++) {

	if (i$.hasClass(sectionElements[i], "a11yRegionTarget")) {

	var sectionRegionNode = sectionElements[i];

	var tempSpanNode = null;

	var tempSpanNodes = sectionRegionNode.getElementsByTagName("SPAN");

	for (var j = 0; j < tempSpanNodes.length; j++) {

	if (i$.hasClass(tempSpanNodes[j], "a11yRegionLabel")) {

	tempSpanNode = tempSpanNodes[j];

	}

	}

	if (tempSpanNode) {

	var spanRegionNode = tempSpanNode;

	var tempParentNode = sectionRegionNode;

	var regionNodeWindowID = null;

	// get window id

	while ((tempParentNode = tempParentNode.parentNode) != null ) {

	if (i$.hasClass(tempParentNode, "component-control")) {

	var m = tempParentNode && (tempParentNode.className || "").match(/id-([\S]+)/);

	regionNodeWindowID = m && m[1];

	break;

	}

	}

	if (regionNodeWindowID) {

	var ariaRegionId = "wpRegionId"+regionNodeWindowID;

	spanRegionNode.setAttribute("id", ariaRegionId);

	sectionRegionNode.setAttribute("aria-labelledby",ariaRegionId);

	}

	}

	}

	}

Technique:
Many of the widgets used by and provided by the Portal 7.0.0.2 and 8.0 themes are written using Dojo. For more information on the accessibility functionality provided by Dojo, see the Dojo Accessibility Design Requirements.

3. Portal themes are understandable.

http://www.w3.org/1999/xhtml">{code}
Guideline:
3.2 Make Web pages appear and operate in predictable ways.

Technique:
The Portal theme supports this requirement by providing a theme and skins, but cannot enforce this requirement. You can use these artifacts to create pages that operate predictably.

Guideline:
3.3 Help users avoid and correct mistakes.

Technique:
On pages that contain fields for the user to enter information or make selections, the Portal pages make use of various WAI-ARIA attributes and properties that help identify key information for the user.

One example is the use of the aria-required attribute for required fields. This indicates that user input is required before the page can be submitted.

Technique:
For some form fields, additional help information is available through a help button. The aria-haspopup property is used with the aria-owns property to identify the available information.

Technique:
The Portal 8.0 theme provides a status bar area on the page. If an error occurs during the loading or processing of a page, an error is returned. When an error is shown on the page, the role of “alert” is added to the markup to indicate a message is available.

4. Portal themes are robust.

Technique:
You should verify that all user interface components (form elements, links, and so on) conform to current standards. Any custom widgets should be reviewed for accessibility. The use of WAI-ARIA is required to meet the Robust requirement of WCAG 2.0.

Web Content Accessibility Guidelines 2.0

W3C WAI-ARIA documentation

W3C Roadmap for Accessible Rich Internet Applications

W3C WAI-ARIA Authoring Practices

DOJO Accessibility Design Requirements

WebSphere Portal 8.0 documentation

WebSphere Portal 7 documentation

Developing an Exceptional Web Experience