Accessibility and Portlet Development

Owned by Jen Bourey
Last updated: Mar 16, 2010Version comment
3 min read

General Notes on Accessibility and Portlet Development

Accessibility is of course a large enough topic that it can't be covered on one wiki page. This page merely intends to represent a set of reminders and starting points, and to highlight some of the accessibility issues that may vary slightly in a portlet environment.

Common accessibility guidelines mesh exceptionally well with strategies for developing portlet content that will be robust and consistent across a variety of skins and portal environments. Ensuring that your content is valid and follows accessibility guidelines will result in re-usable, well-behaved portlet content.

Some accessibility issues may be a little simpler in a portlet environment, since a developer must create markup for only part of the page. For example, the portal itself should define the color scheme for the portlet and provide skip links to main navigation and content.

Developing Accessible Portlets

Markup

HTML markup should represent the structure of your content, which should be styled and formatted by CSS. If you load up a portlet with CSS turned off, the result should appear to be logically organized.

Tables

Tables are for tabular data, not for creating layouts. For easily creating multi-column layouts, please see FSS.

Headings

Heading levels (H1, H2, etc.) represent a hierarchy of content on your page; they should not be chosen merely on the basis of what size text you'd like to use.

uPortal generally recommends that title elements in a portlet start with H2. H1 in uPortal will have already been used for the main page title (either the tab name or in focus mode, the portlet name).

Text alternatives

Any non-text content in your portlet (images, audio, etc.) should have a text equivalent. For images, this generally means providing an alt attribute value.

Example

<img src="weather.png" alt="weather portlet's main view"/>

Forms

Any form element should have a matching label. The label is associated with a form field via the element ID, which means that you'll need to add IDs for all your form elements. In a portlet environment, it's critical to remember that all IDs on a page must be unique. As such, portlet IDs should be prefaced by the namespace of the portlet.

Example:

<c:set var="namespace"><portlet:namespace/></c:set>
<form ...>
	<label for="${namespace}firstName">First name:</label>
	<input id="${namespace}firstName" name="firstName"/>
</form>


Alternatively, you can use the Spring form tags to handle form IDs for you:

<form:form modelAttribute="person" ...>
	<form:label path="firstName">First name:</form:label>
	<form:input path="firstName"/>
</form:form>

UI consistency

All users will benefit from clear, consistent user interfaces. Where possible, make use of standard CSS classes, common user interface conventions, and Jasig-recommended widgets. While portlet development does allow for creativity, portlets may not the best place to pioneer new user interactions. Ideally your content should fit in with the rest of the portal in a clear, consistent manner.

Colors

In an ideal world, portal styles would handle styling for all CSS classes included by a portlet. If your portal's skin defines color schemes that use accessible color combinations and provide a reasonable amount of contrast, you will be served well by using standard CSS classes as much as possible.

Of course, developers of complex portlets often feel compelled to go beyond our currently limited portlet CSS standards. As such, it's important to test portlet content against all skins used in the containing portal.

Javascript

The easiest way to ensure JavaScript accessibility in your portlets will often to be re-use existing components. uPortal bundles the jQuery UI widgets and Fluid component sets in the Resource Serving Webapp, most of which are well-tested for accessibility.

Keyboard operability

In general, anything a user can accomplish with a mouse should also be able to be accomplished via a keyboard. For example, any element with an onmouseover event should also have a matching onfocus.

Tools