Accessibility

The W3C Web Accessibility Initiative (WAI) published some guidelines to better support accessibility in HTML applications. The guidelines cover not only plain HTML pages but also so-called rich internet applications (ARIA: “Accessibility for rich internet applications”). In particular, the WAI defined some new attributes (starting with “aria-“) for HTML elements and defined a number of new values for the HTML attribute “role”.

This chapter describes some of the changes to the Web Center code for accessibility. The changes have been tested with JAWS 14.

Labels

Accessibility tools need unique and meaningful descriptions for each element on a page in order to be able to present the elements properly to the user.The visible element labels are often not sufficient since they don’t contain any information about their context.For example, if a page displays two buttons with label “Roles”, it’s usually clear for a user who is able to see which button is part of the menu bar and which one is part of the privileges tab.If an accessibility tool reads the page or lists all buttons on the page in a separate window, however, a blind user will not be able to distinguish the two buttons without any additional context information.

Web Center sets some HTML attributes defined by the WAI that let accessibility tools generate unique and meaningful labels.

Attribute aria-label

The attribute “aria-label” defines a label for an HTML element for use by accessibility tools.The label is not visible.

Sample

The list pager bar displays just a double left angular quote for the button “Go to first page”. The button has a tooltip but the title attribute is ignored by accessibility tools. Therefore, we add the attribute “aria-label” with the same value as the tooltip. The label is then read or displayed by accessibility tools.

Here is the code from snippet simpleTable/ListPager.htm:

<td style="padding-right:6px">
    <input type="button"
        id="${name.id}_first" class="labeledButton tablePagerButton"
        value="&laquo;" title="${tooltipFirst.h}"
        aria-label="${tooltipFirst.h}"/>
</td>

Attribute aria-labelledby

The attribute “aria-labelledby” also defines a label for an HTML element for use by accessibility tools. In this case, however, the label is comprised of the values of one or more HTML elements whose HTML ids are listed in “aria-labelledby”. Again, the label is not visible.

Sample

The list pager bar includes an input field for the index of the current page. The user can switch to another page by entering its index. If the input field gets the focus an accessibility tool should read not just the index “2” but “Page 2 of 5” or so.

We assign three HTML ids to attribute “aria-labelledby” of the input field. The first id refers to the cell displaying the text “Page”. The second id refers to the cell containing the input field itself; this adds the page index to the aria label. The third id adds the text “of “ and the total number of pages to the label.

Here is the code from snippet simpleTable/ListPager.htm:

<td id="${name.id}_label1" …>${labelPage.h}</td>
<td id="${name.id}_label2">
    <input type="text" id="${name}_page"
        class="rwTextField tablePagerInput" value="1"
        aria-labelledby=
          "${name.id}_label1 ${name.id}_label2 ${name.id}_label3"/>
</td>
<td id="${name.id}_label3" ...>
    ${labelOf.h} <span id="${name}_numPages">2</span>
</td>

Fieldset

To indicate the context of HTML elements it’s often a good idea to use a common prefix for their ARIA labels. For example, all fields in a search panel should get a label prefix that identifies the search panel, like “Search users”. This also makes sure that the elements are grouped together in lists that can be displayed by accessibility tools, like the list of all editable form elements or of all buttons on a page.

Web Center often encloses associated fields in a fieldset element and assigns an ARIA label to the fieldset which serves as ARIA label prefix for the associated fields. The ARIA label is assigned either via attribute “aria-label” or “aria-labelledby”. The CSS class “aria” makes sure that the fieldset has no visible effects.

Sample

Here is an extract from snippet searchPanel/searchPanel.htm:

<fieldset aria-label="${searchPanelTitle.h}" class="aria">
   ... search panel fields ...
</fieldset>

The message key for the search panel title is by convention “searchPanel.title.<objects>” where “<objects>” is replaced with the attribute of the same name in the tiles definition of the corresponding entry list.The key for the user list is “searchPanel.title.users”, so the ARIA label prefix for the fields in the user search panel is “Search users”.

ARIA Roles

The WAI defined a number of values for the HTML attribute “role”.The attribute is intended to indicate the semantic of an HTML element.

Presentation

The role “presentation” indicates that an element is used for its presentational effects only but has no semantic meaning.Web Center assigns the attribute to some layout tables that should be ignored by accessibility tools.

Sample

The following layout table for the home page plug-ins is defined in JSP view/tiles/plugInPage.jsp:

<table class="plugInPage" cellpadding="0" cellspacing="0"
       style="height:100%" role="presentation">
   ... table content ...
</table>

Menubar and Toolbar

Web Center assigns the roles “menubar”, “menuitem” and “menu” to HTML elements of the main menu and the roles “toolbar” and “button” to HTML elements of the toolbars for forms and lists.Accessibility tools are therefore able to detect the semantic of the elements.JAWS, for example, will switch its mode of operation so that keyboard events go directly to the menubar or toolbar.

Read-only Fields in Tab Order

Web Center includes read-only form fields in the tab order by setting their tab index to “0”.This makes it easier for disabled persons to access the field content.You can redefine the tab order in file webCenter.properties:

# Tab index for read-only form fields
# 	-1: exclude from TAB order
# 	 0: default TAB order

formReadOnlyTabIndex = 0

The property is evaluated in snippets for read-only form fields, for example in textField/roTextField.htm:

<input type="text" id="${id.id}" name="${name.h}"
  class="roTextField" style="${style.h}" value="${value.h}"
  readonly="readonly"
  tabindex="${webCenter.formReadOnlyTabIndex.jsInt}"/>
Read-only check boxes are never included in the tab order since in order to be not editable they have to be marked as disabled.

Editable Date Fields

The values of date fields are by default not directly editable.To change their values you have to select a date in the calendar widget.The widget may be difficult to use by disabled persons.

You can switch to directly editable date fields by changing the properties of the renderers “calendar” and “dueDate” in file renderers-config.xml:

<renderer id="calendar" type="java.util.Date" ...>
  ...
  <!-- Activate this section for non-editable date input fields -->
  <renderer-property name="formatTooltip"        value=""/>
  <renderer-property name="formInputReadOnly"
      value="readonly=&quot;readonly&quot; tabindex=&quot;-1&quot;"/>
  <renderer-property name="formInputStyleClass"  value="roTextField"/>
  <renderer-property name="tableInputStyleClass" value="roTextField"/>
  <renderer-property name="tableInputReadOnly"   value="true"/>

  <!-- Activate this section for editable date input fields -->
  <!--
  <renderer-property name="formatTooltip"
                     value="application.dateFormat.tooltip"/>
  <renderer-property name="formInputReadOnly"    value=""/>
  <renderer-property name="formInputStyleClass"  value="rwTextField"/>
  <renderer-property name="tableInputStyleClass" value="rwTextField"/>
  <renderer-property name="tableInputReadOnly"   value="false"/>
  -->
</renderer>

The renderer properties are evaluated in the corresponding code snippets, for example in calendar/calendar.htm:

<input type="text" id="${id.id}" name="${name.h}"
    ${formInputReadOnly} class="${formInputStyleClass.h}"
    style="${style.h}" title="${formatTooltip.h}"
    value="${value.h}" onchange="markChanged()"/>

Table Summaries

Table summaries are used by accessibility tools to tell a disabled user what the tables are about.Visual labels like table captions are usually too terse for that purpose.

The message key for a table summary is usually determined by convention but may be overwritten per table by configuration.The following list displays the options with descending priority:

  • Value of form-property attribute “summary”

  • “list.summary.<form-property name>.<form-bean name>”

  • “list.summary.<form-property name>“

Sample: Defining a specific summary key:

<form-bean name="userListForm">
	<form-property name="users" summary="users.summary" …

The message key is “users.summary”.

Sample: Defining no summary key:

<form-bean name="userListForm">
	<form-property name="users" …

The message key is “list.summary.users.userListForm” if a message with that key is defined. Otherwise, the key is “list.summary.users”.

Short (probably too short) default summary texts for the tables used in the default Web Center applications are provided. Here are some summaries from the English text.properties file:

list.summary.userLinks           = List of selectable users
list.summary.users               = List of users
list.summary.workflowDefinitions = List of available workflows
list.summary.workflowLinks       = List of selectable workflows

The summaries are evaluated in the corresponding code snippets, for example in simpleTable/table.htm:

<table id="${name.id}" width="100%" cellpadding="0" cellspacing="0"
     summary="${summary.h}" class="tableBorder">