The CMS Guide to Accessible Development
Welcome and Introductions
Good Morning. We would like to welcome you today to the eLuminate training session hosted by CMS Central for campus developers. The session is being presented by Jeanine Lussier, Director of Training and Documentation with the CMS project. Our moderator is Julie Maiorana, also with the Chancellor's Office.
The intent of the CSU Developer Training is to
- provide the principles and guidelines for creating accessible development
- identify the features that will require changes to the delivered Oracle product
- identify the features that CSU developers can control
- Where applicable, demonstrate how to apply the accessibility feature within Application Designer
Introduction
Accessibility standards, as they apply to web-based applications and interfaces, are largely written in terms of html coding standards.
While html coding standards apply to all web-based applications, a gap was found in locating materials that provide specific examples of how developers working in the PeopleSoft/Oracle Application Designer Environment can translate these standards into practice.
As a result, the California State University formed a group of Accessibility, PeopleSoft Development, and Documentation/Training experts to produce a guide that can assist developers with making best-practice choices for accessibility, utilizing the delivered Oracle templates and Application Designer development tool.
This training guide is geared towards developers that are experienced with the use of Application Designer and does not attempt to teach users how to use Application Designer; the goal is to show best practices for enhancing accessibility within the product boundaries.
CMS would like to thank the following individuals for their input into the creation of this guide.
Wayne Dick, Instructor and Accessibility Expert
CSU, Long Beach
Tom Jewett, Instructor and Accessibility Expert
CSU, Long Beach
Sam Ogami, Accessibility Expert
CSU, Office of the Chancellor
Leonard Reyes, Developer
CSU, Office of the Chancellor
Jeanine Lussier, ITS Documentation and Training
CSU, Office of the Chancellor
The Paciello Group
Findings from the CMS Baseline study conducted by the Paciello Group have been incorporated into this guide.
Table of Contents
- Structural Markup
- Graphics, Action Buttons and Alt Tags
- Focus
- Error Messages
- Flickering Images
- Page Layout and Frames
- Common Mistakes in Layout Design
- Form Fields
- Choosing Field Types
- Understanding Proper Use of Field Labels
- Creating Labels in Application Designer
- Determining Tab Order
- Data Tables
- User Accessibility Settings
- For Further Information
Structural Markup (Structural Language Encoding) is the foundation by which information is organized and is what screen readers use as “hooks” for navigation.
In browser-based applications, Structural Markup adds html tags for items such as:
- Headings
- Lists
- Frames
- Data Tables and Table Headers
- Links
- Images and Image Maps
- Forms
Screen readers translate the html tags into an announcement of features for the assitive technology users.
For example:
- Users will hear an announcement of how many frames are on a page and be given the ability to jump between the frames before navigating through the information within each frame.
- Users can give a command to show only first level headings and navigate through the headings before deciding to read the detailed information under each section.
- Screen readers will announce lists - stating (for example) "list with 10 items" before starting to read each bullet.
Without tags, the end user has little control to understand where they are on the page, where they are going, or even what is on the page without listening to literally every single item present on the screen.
Demonstration
View how Jaws reads the PeopleSoft/Oracle Home Page Navigation List
As demonstrated in the video clip, without any organizational structure, the user hears a long, long list of links, and has no method to organize information into "chunks".
Instead, if headings are used
- The screen reader will announce how many headings are present on the page.
- A shortcut can be used to read headings without having to listen to everything in-between.
- Once the user finds the top level of information they are looking for, they can give the command to read the associated Heading Two <h2> levels and then drill down from there to obtain additional links.
For Example
- Financials, Campus Solutions, Human Resources, PeopleTools, Self-Service, and Custom Modifications could be tagged with Level One <h1> Headings
- Modules could be tagged with Level Two <h2> Headings
- Hyperlinks could then launch the individual processing pages.
The screen reader then could be instructed to read only Heading 1 levels and hear 6 links instead of 81 links to help them focus in on the content area they need to find before expanding to the subsequent levels.
Bulleted and Numbered Lists work similalry - screen readers differentiate between the different levels and provide users with options for navigation.
Developer Recommendations
Delivered Product
- CMS developers do not have control over modifying the structure of the delivered Oracle/PeopleSoft navigation menu.
- Oracle has targeted the release of a new menu structure in PeopleTools 8.50.
Custom Development
- Developers should utilize structured language encoding when creating web or portal bolt-ons and interfaces into the Oracle/PeopleSoft application.
2. Graphics, Action Buttons and Alt Tags
In addition to being difficult to navigate, there are two other issues with the navigation menus that are even more challenging.
- The navigation menu uses improperly labeled graphics to expand and collapse submenus under each link.
- In addition, the dashes at the end of the menu are not text dashes, they are graphics without any alternative text / <alt> tags applied at all.
Screen shot of the Oracle/PeopleSoft Navigation Bar
Menu Example 1: Graphics as Action Buttons
Whenever clicking a graphic causes an action to happen, the graphic is actually being used not as a decoration or a picture, but rather as an action button, and action buttons must be clearely labeled to describe exactly what will happen when clicked.
On the navigation bar, the expansion arrows are problematic for two reasons.
- There is nothing to indicate to screen readers that clicking the arrow will expand a submenu.
- The way the arrow images are labeled is inconsistent - sometimes it just repeats what the link name is, sometimes it gives a description of what functionality can be found in that section - but - again - the biggest problem is that it gives no clue that you should click it to show the submenus.
Instead of using a static graphic, the image should be an action button with two states. One state is when the submenu is closed, the other state is for when the submenu is expanded.
The graphic for a collapsed menu could contain a + sign for sighted users, with an <alt> tag for screen readers that states "Expand (name of link) Submenu".
The graphic for an expanded menu could contain a - sign for sighted users, with an <alt> tag for screen readers that states "Collapse (name of link) Submenu".
So, for example, alt tags could be labeled as shown in the following screen:
In addition, using the example shown above, if you applied a Heading One <h1> tag to Campus Solutions, Financials and Human Resources, a Heading Two <h2> tag to Academic Advising, Campus Community and Financial Aid - then used <li> list bullets <lis> tag for the procedures - you now have a fully accessible menu that will be very easy to navigate with assistive technology devices.
Here are two more examples of icons commonly used in PeopleSoft to launch actions with examples of best practices for labeling the alternative text:
- Magnifying Glass
Correct <alt> tag: "Lookup Business Unit" or "Lookup EMPLID"
Incorrect <alt> tag: "Magnifying Glass" or "Search"
- Disk Icon
Correct: "Save New Employee Entries"
Incorrect: "Save"
Remember, the description placed in the <alt> tag is read by screen readers to describe exactly what is going to happen when the action is launched.
Menu Example 2: Graphics as Decorative Images
Back to the navigation menu, example two!
In this case, the dashes at the end of the navigation bar are purely decorative - they do not expand a menu, they do not launch an action - they are just there.
Similarly, decorative graphics are also heavily used on the home pages for each major process / application.
Standard layout of application home pages
Now, the graphics on the application home pages do have <alt> tag alternative text, wheras the navigation bar dashes do not - yet neither is best practice for use of <alt> tags with decorative images.
How Screen Readers read Decorative Images
When screen readers come across a graphic:
- they literally say "graphic"
- then they read the (hidden) <alt> tag alternative text
- then they read whatever comes after the graphic
So, for the untagged dashes, it reads:
- "graphic tax center" "graphic treasury management" - so it is unclear what the graphic is for, or to distinguish it from the link that follows.
For the tagged graphics on the application pages, it reads the alt text then the link name, and in most cases, the alt text is simply a repeat of the link name. Thus it reads:
- "graphic" "transfer credit" " transfer credit"
- "graphic" "Evaluate my transfer credit" "Evaluate my transfer credit"
This is not such a great idea because it repeats a lot of unnecessary information.
Best Practices for Graphics as Decorative Images
- Ask yourself – Is a graphic really necessary? For example, in the navigation bar, the pictures of dashes used for the items at the end of the navigation should have been an actual list with a <li> list tag, not graphics.
- All graphics must be labeled with an alternative text <alt> tag. However, if the graphic is strictly a visual decorative image, and the link is what contains the information, you actually would want screen readers to skip over reading the graphic, and instead read just the link ... and ... here is how you do that ...
A wonderful tip !
Any time you use a graphic just as a decoration - you can code the <alt> tag with two quotation marks - no space in-between. Like this:
""
That puts a null tag on the graphic and the screen reader will completely ignore the graphic. It will not announce "graphic" - it will not read an alt tag - it just skips it!
In Summary
- If the graphic launches an action, name the <alt> tag with the action the graphic will cause.
- If the graphic does nothing, name the <alt> tag with a double quote to skip it!
Developer Recommendations
Delivered Product
Oracle will audit the delivered product to identify and correct missing <alt> tags.
Custom Development
CMS and campus developers are responsible for applying the appropriate <alt> tag alternative text to all graphics utilized in custom development.
Assigning Alt Tags in Application Designer
The following section is taken from Application Designer PeopleBooks, Chapter 8.
- Assign alternate text on the Label tab of the Properties dialog box for the control that you specify.
- You can use the Message Catalog, custom label text, or the RFT long or RFT short label, if one has already been designated in the record field.
- There are alternative text entries in the Message Catalog for the following page elements: folder tabs, scroll left and right buttons, hide and show grid tabs, prompt buttons, expand and collapse buttons for grids, group boxes, and scroll areas.
Note: Any alternate text that you select is visible to all users as mouse-over text on some browsers regardless of whether the system administrator makes the accessibility features available to users in PeopleTools Security.
To specify a label for an image push button or link associated with a record field:
- Open the Page Field Properties dialog box for the control.
- Select Image as the type.
- Determine the RFT names:
- If the RFT name is descriptive, set the label type to that RFT name.
- If the RFT name is not adequate, edit the RFT name or write a message using the Message Catalog.
Image buttons and links not associated with record fields should use messages exclusively. The steps to specify a label for other types of images are the same as for image buttons and links, with the following differences:
- For dynamic images, you can choose to use RFT names or messages.
- For static images, you can only use messages or static text.
PeopleSoft recommends using the Message Catalog.
Focus is the act of highlighting an area of the screen that is selected as the user perform various functions such as
- moving up and down in lists
- moving through different tabs on a page
- moving through different fields on a page
Color alone can not be used to provide focus even for sighted users (who don't use screen readers) because of the large population of people who are color-blind and/or have issues with perceiving color contrast.
Incorrect use of color alone to show that the Self Service Folder is the selected link.
Notice in the second graphic, shown below, there is also a box around the selection, in addition to the change of color.
For those who do use screen readers, it is a similar principle to <alt> tags. When navigating through fields and tabs, the label names should be descriptive enough to "read" where the user is on the page, as well as being able to indicate, for example, if the field is a required field. More on labeling fields and determining tab order will be covered later in this guide.
Developer Recommendations
Delivered Product
Oracle has implemented the following changes in PeopleTools 8.49.15 to assist with identifying focus in the delivered product:
- Generating the word "Selected" in structural markup text associated with Tabs. This will provide a clear focus for screen reader users to know which Tabs they have selected as they navigate through pages.
- In PeopleTools 8.50, all required fields will have the word "Required" generated in the field label.
Custom Development
- Do not use color alone to indicate focus.
- Apply field labels, as appropriate, to indicate when items are selected or required.
(Please note: instructions are not currently available for using App Designer to incorporate these features in toolsets 8.49.15 or 8.50. Please watch for future updates to these instructions as these tools upgrades are released and deployed.)
Color alone can also not be used to warn users of errors. If the color is stripped out or not able to be seen, the user does not easily recognize the text as an error.
On-page error message using color alone
Form Error Message with Color Removed
The placement of messages is important too, and there are currently three methods used to warn users of errors:
- popups
- on-page error text
- in-field error text
Developer Recommendations
Delivered Product
Oracle is researching their final solution for delivering error messages as either popup windows, text that appears somewhere on the page, or text that appears within the field itself. More information will be provided as it becomes avialable.
Custom Development
- Error messages can be red, but they also should have a secondary visual cue for color-blind users. One example is to use red, bold text.
- Icons can be used to add emphasis
- Error messages should contain 2 parts:
- a description of the problem
- what the user needs to do to fix it
- Error messages should be concise. They do not need to include full sentences or the word "please".
- Error messages should validate all errors on a screen at once. To the extent possible, users should not have to fix a problem, re-select Save or Submit, then receive more error messages.
- In long pages or long forms, if error messages appear at the top of the page in a summary form, they should also appear next to the field(s) that contain the errors. This helps users find errors quickly as they are scroll down long pages.
- Pop-ups are not the prefered method for error messages, especially in the case of missing or incorrect data in forms.
- Place error messages above the form they are associated with and link the error message with the incorrect field: when the user activates the link, focus is moved to the field.
- Make error messages specific: If the username is correct only provide a message about the incorrect password.
- Indicate error pages in the page title
Current page title "Oracle | PeopleSoft Enterprise 8 Sign-in"
Example error page title "Incorrect password – Oracle | PeopleSoft Enterprise 8 Sign-in
The processing image that is a feature found on most of the form pages within the application was tested to check whether it flashed at a frequency that may cause problems for users. It was found the image flickered at a frequency which fails under the section 508 standards. This is an issue that will have to be addressed by Oracle/PeopleSoft to modify the animatged .gif so that it does not flicker with a frequency greater than 2 Hz and lower than 55 Hz.
Processing Message
Oracle uses a three-frame page layout for each page that serves as the entry point (or Main Page) for a group of related tasks. The use of frames is supported by accessibility readers, however, it is crucial to provide unique names for each of the frames so that users relying on screen readers know which frame they are in when navigating throughout the pages.
Screen shot showing the three-frame layout commonly used by Oracle
For the most part, the delivered product is labeled correctly with unique labels for each frame. For example, in the illustration shown above, the names of the three frame headers are:
- A - Portal Header Frame
- B - Navigation Frame
- C - Main Content Frame
Developer Recommendations
Delivered Product
Oracle is conducting an audit of all frame headings and will correct any improperly labeled frames.
Custom Development
CMS developers are responsible for applying unique fram headings for all custom development. aware of the , each frame does have a unique label, which supports accessibility.
7. Common Mistakes in Layout Design
Although the three main frames on the Oracle main pages are all labeled, there is another feature on the main pages that is a bit more problematic. The main pages make use of layout tables strictly for design. From an accessibility standpoint, tables should only be used for data tables - i.e. where each column contains unique headings and values.
Tables should not be used only as “buckets” to hold content for a visual layout. It becomes even worse when multiple tables are added (nested) within each other. When multiple tables are encountered, screen readers often lose the intended sequence and jump all over the page in no particular order.
Screen shot showing the improper use of tables for layout design. The white lines show the outline of the nested cells.
Developer Recommendations
Delivered Product
Changing from a table structure to an accessibility-supported CSS stylesheet model will require redevelopment by Oracle of its application templates. CMS Developers will not be expected to change the delivered Oracle coding or page layout.
Custom Development
When creating bolt-on or portal-based development that does not rely on delivered templates, developers should be familiar with using CSS stylesheets for layout, and avoid using tables for design.
The majority of Oracle/PeopleSoft pages are form field pages, with some of the most common types of fields listed and illustrated below.
A. Drop Down Lists
B. Edit Boxes
C. Action Buttons (Graphics)
D. Action Buttons (Standard Push Buttons)
E. Check Boxes
F. Long Edit Boxes
G. Radio Buttons
Screen shot of the field type options labeled A-G
Demonstration
Hear how Jaws reads fields on the Purchase Order > Find an Existing Value page
The following translates exactly how Jaws reads both the visible information on the page, as well as the non-visible field type identification and label.
Screen shot of the Business Unit Field and label components marked A, B & C.
A. Refers to how Jaws begins reading the Business Unit line - which consists of:
- reading the visible text
- announcing the type of field present (in this case a combo box field),
- reading the default value provided in the combo box field
- providing instructions for using the combo box field
The user hears:
- Business Unit colon
- combo box
- equals
- To change the selections use the arrow keys
B. Refers to how Jaws reads the text entry field - which consists of:
- reading the non-visible label
- announcing the type of field present (in this case an edit field for text entry)
- providing instructions for using the edit field
The user hears:
- Business Unit
- Edit
- Type in Text
C. Refers to the magnifying glass and is read:
- Lookup Business Unit
Developer Recommendations
Delivered Product
Oracle provides the method to label fields in Application Designer, and there is consistency in the product for choosing and labeling fields appropriately.
Custom Development
Future updates to this training will examine how/if Oracle deliveres additional features within Application Designer to add more label features, such as identifying required fields and/or identifying shifts in focus. For now, developers need to follow all existing standards for choosing the appropriate types of fields and properly applying field labels.
Because screen readers supply instructions based on the type of form fields used on pages, it is important to follow the industry-defined standards when deciding on which type of field to use when creating new pages.
Screenshot of Application Designer toolbar with field form selection buttons highlighted in red.
Table: Explanation of symbol types and uses.
| Symbol | Field Type | Accessibility Requirement |
 |
Checkbox | Use as a toggle switch—on and off—for data controls that can have only one of two values – “yes” or “no” / (1 or 0). Checkboxes can be used to select multiple items in a list – since each item is a “yes / no” choice independently. Checkboxes should never be used to launch an action. |
 |
Radio Button | Used for groups of items where only one item in the group can be selected at one time. Best practice is to use radio buttons to enable selection of only one out of two possible choices. If there are three or more possible choices, drop-down list boxes are a preferred alternative. Radio Buttons should never be used to launch an action. |
 |
Drop Down List | Use drop-down list boxes to enable data selection from a list of three or more possible choices. Drop-down list boxes are a good design choice when presenting users with a small number of selections from which they must select one value. |
 |
Edit Box | Adds an edit box, which is used for data entry. Edit boxes are also used for displaying fields and translatable text. Use an edit box for text data entry—for example, a record field that is defined as character, number, signed number, or date. Also use edit boxes for displaying fields and translatable text. |
 |
Long Edit Box | Used for entering long, textual items, such as comments. The length of the control is determined by its contents, rather than the physical size of the box on the page. Each long edit box has a built-in scroll bar to enable users to enter and display more data than can be shown at one time on the page |
There are two types of buttons, both of which are used to launch actions, but which each have different requirements for labeling them to ensure accessibility.
| Symbol | Field Type | Accessibility Requirement |
 |
Standard Push Button | Buttons are used to launch an action – i.e. to launch a run control or generate a recalculation (as well the standard OK, Save and Cancel commands). If you use the standard push button, it is automatically accessible as long as you add descriptive text to the button. The value attribute will be read by screen readers when the button is accessed and you do not have to add an alt tag. |
 |
Image as Action Button | If you use an image as an action button instead of a standard button, the input must have alt text that describes what action will occur. So, for example. the magnifying glass must have an alt tag named "lookup xxx" - where xxx represents the name of the information it is looking up. |
10. Understanding Proper Use of Field Labels
Labeling Edit Boxes
- Make sure text labels are close to edit box fields. Text labels should be just above or just to the left of the edit box field. The prompt should be "physically close," (in pixels) so that readers who blow up the screen to large sizes can still see the label close to the field.
- Do not put the text label within the field. Putting a text label in the field is certainly close – but it means that users have to erase it before entering their own values, which is problematic.
- Tie the label to the field “programmatically” by using html coding that ties the <label> element with <for> and <id> attributes.
Note: This is not really within our control in Application Designer, but is being documented here anyway since it is the most foolproof way of assuring accessibility and may apply in some cases of development outside of App Designer.
Tying labels programmatically consists of using the following html coding:
<label for="fn">First Name:</label>
<input type="text" name="fn" id="fn" size="20" />
In this example, the id attribute has been added to the input element and the value of the for attribute on the label element is the same as the value of the id attribute of the input. That ties the label programatically to the field.
Labeling Radio Buttons and Check Boxes
Radio buttons and checkboxes are similar to text entry fields except that the text should be just to the right, and should also always be programmatically connected by associating the prompting information with the control using the <label> element with <for> and <id> attributes.
When deciding whether to use radio buttons or checkboxes, the rules are:
- Use Radio buttons to select only one option from a list of choices
(you are either male, or female – not both) - Use Checkboxes to select any or all of the choices from the list
(user can request any combination of information about housing, meal plans and transportation) - Never use radio buttons or checkboxes to launch an action. Buttons are the only element that should ever be used to launch actions.
Screenshots showing incorrect use of a checkbox, and correct use of a button to launch an action.
Labeling Drop-Down Lists
Drop down lists are similar to text entry fields, except that for drop-down lists, it is acceptable to put labels and/or additional instructional text as a value in the table itself as a default value. In fact, Oracle commonly uses drop-down boxes to guide users with processing prompts.
Screenshot of a lookup page where processing prompts (=, begins with) are included as default values in the drop-down list.
Notice that in the sample above, Oracle still provides a label to the left-hand side of the drop-down box, then uses a default value as a processing prompt.
Placing the label as the default value in the drop-down box is acceptable, but not really best practice. There can be a disadvantage because unless the content of the list is very self evident, the label is replaced with user-selected values. If it is a pretty self-evident list (i.e. states) the user would hear (for example) “California” on a return trip to the page, which is obviously a field for “state”. However, if the field was asking for a numerical value (i.e. age) and the user selects “35” - then hears “35” on a return trip to the page, they might not remember that it was an age field, especially if there are multiple numeric fields on the page. Best practice is to either create a label separate from the drop-down field, or, if included as a value, associate it programmatically by using the label element with for and id attributes in the html coding.
Screenshots showing the disadvantage of placing labels directly in a drop-down list box
Labeling Action Buttons
Earlier in this training, a section was presented explaining how to apply proper alternative text <alt> tags to graphics that launch actions. In those examples, graphics were being used to mimic standard action buttons. Standard Action Buttons generate html coding that is different than the coding generated by labeling graphics with alternative text. The differences are outlined below:
- A standard button refers to a button that generates html code as follows:
<input type="submit" value="name of the button" />
Notice that a standard button generates html code labeled "submit" as an input type. When screen readers find input type="submit" in the html coding on a page, they read "click to submit" (or something similar) to let users know that they have an action button present. For standard buttons, the name that users see on the button is defined in the html code. (value="name of button")
- An image used as a button generates the following html code:
<input type="image" name="MagnifyingLookupGlass" src="magglass.gif" alt="must be a relevant description of the action the button will cause" />
Notice that there is no inherent “submit” action built into the html coding - that is why it is so important to apply <alt> tags to graphics that describe exactly what is going to happen when the graphic is clicked to launch the action.
11. Creating Labels in Application Designer
The following information is compiled from various sections of the Application Designer PeopleBooks.
Check Boxes
Open the Radio Button Properties dialog box.
- Type: Select the type of label. You can use the default XLAT Long, or select “Text”
- Label Text: If “text” is chosen as the type, enter the field name and accept the default style.
- Location: Placing the label to the right of the button, aligned left is the recommended placement to support accessibility.
Screenshot of Check box Properties Label Tab
Radio Buttons
Open the Radio Button Properties dialog box.
- Type: Select the type of label. You can use the default XLAT Long, or select “Text”
- Label Text: If “text” is chosen as the type, enter the field name and accept the default style.
- Location: Placing the label to the right of the button is the recommended placement to support accessibility.
Screenshot of Radio Button Properties Label Tab
Edit Boxes
- Type: The Label Type default of RFT Long should be used as the best option for accessibility support. This choice will display the record field table long name for the field from the associated record definition.
- Label ID: Select from the drop-down list box the label you want to appear for the page field. The choices available here are based on the Label ID column and the Long Name column for the selected field definition. The default setting for this option is Use Default Label. This default is determined by the label you select as the default for the field definition.
- Alignment: Alignment options apply to radio button groupings and column headings. This will Left Justify, Center, or Right Justify the heading within the column or grouping. Any choice is accessible.
- Position: Position Options are available for drop down lists, edit boxes and long edit boxes. Left is the recommended choice to support accessibility for drop down lists and edit boxes.
Screenshot of the Page Field Properties dialog box in Application Designer
Buttons
In Application Designer, buttons are considered a functional control object. The button can represent an internal or external link, PeopleCode command, a process launched through PeopleSoft Process Scheduler, prompt action, scroll action, secondary page, or toolbar action. From a technical standpoint, the button is no different than a hyperlink within Application Designer, because any control can be defined to appear on the page as either a traditional push button or a hyperlink. Therefore, it is best to apply best practices for design and use a push button to launch actions, and links to launch pages (navigational trail).
Assign labels to images using alternate text, or the ALT HTML tag. You can set alternate text for static images, dynamic images, push buttons and link images, and control buttons in scroll areas and grids.
- Open the Page Field Properties dialog box for the control
(same screen shot as shown in previous section) - Select Image as the type
- You can use the Message Catalog, custom label text, or the RFT long or RFT short label, if one has already been designated in the record field
- For dynamic images, you can choose to use RFT names or messages
- For static images, you can only use messages or static text
PeopleSoft recommends using the Message Catalog, and there are alternative text entries in the Message Catalog for folder tabs, scroll left and right buttons, hide and show grid tabs, prompt buttons, expand and collapse buttons for grids, group boxes, and scroll areas. Image buttons and links not associated with record fields should use messages exclusively.
In addition to applying proper labels, and locating labels appropriately in relation to their field, the order in which fields are organized on the page is also critical to support accessibility.
Best practice is to order fields from top-to-bottom, left-to right. In addition, fields that share the same label should follow consecutively in the tab order from left to right.
12.1 Testing Page Control Order
Tab order should be tested by using the Application Designer test mode and/or by testing the page with accessibility software in a browser.
To test tab flow using View page in Browser mode:
- Open the page in PeopleSoft Application Designer that you want to test.
- Select Layout > View in Browser
- Select the appropriate browser from the drop-down list box
- Press the TAB key to move from one field to the next
- Press SHIFT+TAB to move to the previous field
12.2 Applying Control Order Rules
- Radio Buttons: For radio buttons to function in a single group, they must be associated with the same record field and be listed together on the Order tab of the page definition. The only control that you can place between related radio buttons is the static text control to extend radio button labels. Put the text immediately after the radio button to which it relates.
- Level-Based Controls: List level-based controls (scroll areas, grids, and scroll bars) immediately before the first control that they govern, followed by the controls that are directly governed by that control. Level-based controls directly govern all controls that are listed below them on the order list until they encounter another level-based control that is at the same or lower level (higher occurs level number).
- Display Controls: Place display controls before related displays that they govern. The related display controls don’t have to follow the display controls immediately, but they must be inside the same scroll area or scroll. However, if you have more than one related display control, placing each immediately following its display control makes the order page easier to read and understand.
12.3 Changing Control Order Using the Order List
The Order tab of the page definition displays attributes about each of the page fields and their field order. The ID column represents the order in which the field was added to the page. If you modify the order of page fields on the page, note that the numbers assigned to each field remain constant. Thus the IDs may not always appear in sequential order. The field ID displays on the Compare report when a database compare is performed to assist you in identifying specific page fields.
Reorder page fields on the Order tab by dragging them in the same view. Changing the order list doesn’t change the physical location of controls on the page. It changes only the logical order or tab order in which controls are processed. When you’ve added and arranged all of your controls, you may want to print your page definition to see how you might need to reorder your controls.
The Order tab also governs processing rules for scrolls and record or field relationships. Consider which controls are associated with which scroll area or scroll bar and which secondary relationships are important to page processing.
To change the order list:
- Open the page
- Select the Order tab
- Use this view to change the logical processing order of fields on your page
Screenshot of the Order Tab
To move a control to another position in the control order list, select the control that you want to move:
- Press the SHIFT key to select multiple controls
- Drag the selected control to the new position on the Order view
- The system moves the control to the new locaiton in the list
- The ID value remains static
The visual display of the page still looks the same - changing the order list does not move the control on the page, only the logical processing order of the control.
Developer Recommendations
There are several perspectives on resolving these issues, including the fact that turning on the "accessibility" user mode expands content section controls, removing the need to interact with them. Therefore, Oracle has requested that users log cases for delivered pages that have issues with Tab Sequence.
Developers should check the tab order of any custom pages they produce to make sure that the tabbing does follow a logical sequence - whether that sequence is top-to-bottom, left-to-righ - OR whether based on the required processing order is a decision that can be made on a page-to-page basis.
Earlier in this guide, reference was made to the fact that tables used to structure the layout on a page present numerous challenges for assistive technology readers.
Screenshot showing the use of tables for layout design. The white lines show the outline of the nested cells.
Conversely, data tables that are structured properly are fully supported by assistive technologies, and present users with consistent navigation aids throughout the table.
Screenshot of a properly-structured data table
Demonstration
View how Jaws reads a properly formatted data table
Developer Recommendations
Oracle is auditing their delivered product to find cases where they have not used Data Table markup language to identify grids as tables to assistive technology devices. They have made refinements in PeopleTools 8.49.15 - including delivering each HTML control with a label, and having every cell associated with a column or a row.
For developers, follow the delivered Application Designer guidelines.
Creating Accessible Tables in Application Designer
In Application Designer, there are four main areas to define settings for the grids to define their properties. To support best practices for accessibility, the following features on the Label tab of the Grid Properties dialog box should be chosen:
Section A: Header Area
- Always choose Display Header
Section B: Body Area
- Always choose Show Border
- Always choose Show Row Headings (runtime)
Section C: Column Headings
- Always choose Show Coumn Headings (runtime)
Section D: Footer Area
- No direct impact on accessibility whether the footer area is shown or not.
Screenshot of the Label Tab of the Grid Properties dialog box with the major divisions labeled A-D. Checkmarks indicate the settings that should be selected to support accessibility.
14. User Accessibility Settings
The final piece of the puzzle is a setting within Oracle itself that simplifies how information is presented within the application. End users have the ability to turn on accessibility features to strip out much of the layout design, leaving a simplified page view based on the “behind the scenes” coding.
- Navigate on the Oracle Home Page to Main Menu > My Personalizations
- On the first line, General Options, click the “Personalize Option” button.
- On the Personalizations Page, select “Use accessible layout mode” from the Accessibility Features drop-down menu.
- Click OK
- Log out and log back in for the settings to take effect
Screenshot of the My Personalization and Personalization Option pages
For further information, please visit the California State University and CMS Accessibility websites.
California State University Accessible Technology Initiative
http://www.calstate.edu/accessibility/
CMS Project Accessibility Resources
http://cms.calstate.edu/06_Projects-Initiatives/06D_Accessibility/CMS_06D_00_PROJ _Accessibility.asp