Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Corrected links that should have been relative instead of absolute.

Accessibility Rules

  1. The top level of a page should be the ROOTUIELEMENTCONTAINER.
  2. Each visible group of UI elements should be put in a Transparent Container. If the Transparent Container does NOT contain a Section Header, its "isLayoutContainer" must be set to TRUE. If instead a Section Header will be given to this group, it should be done as follows:
    1. Add a Section Header UI Element inside the Transparent Container. The Section Header's "Level" property should be set to "header4","header5", or "header6". Select the Transparent Container's property "LabeledBy" to be the ID of the Section Header. If a Transparent Container is labeled by a Section Header the property "isLayoutContainer" must be set to false.
  3. All input fields must be given a "Label" and set the LabelFor property to the ID of the associated input.
  4. All labels must be associated with a UI Element by setting the property "LabelFor."
  5. Always create column headers for every visible column in a table.
  6. All images that do NOT convey important information, such as horizontal rules, spacers, must have their "isDecorative" property set to True.
  7. All images that DO convey important information must have short descriptive text in the ToolTip property.
  8. Tooltips should never repeat Label text, they should only be used to add more information. See guidelines for alt text.
  9. Never nest tables, for instance, never set a table popin's content to be another table.
  10. Never nest trays, groups, or tabs, or other grouping containers, except Transparent Containers.
  11. Periodically run the the automated "complete object" check as part of your development process to find and fix accessibility problems.
  12. Melting Group pattern: use to remove input hints from the tab chain (see ZV_TEST, View V_CREATE_POS). ADD PICTURE.
  13. Instead of using the PageHeader UI element, every page must have a page title made with a FormattedTextView, coded using the <h1> tag.
  14. All Search Helps must be custom coded. The standard search help is neither accessible, nor usable, nor pretty.
  15. The property "rowSelectable" of table UI elements should either have the value 'X' or it should be bound to the context. If you wish to ensure that the table cannot be selected or is to function merely as a display table, set the property "selectionMode" to the value "none" instead, which is preferred for usability reasons.
  16. Screen changes: make all dynamic changes below the cursor, or move the cursor by changing the focused element, or announce that something has changed above the cursor.
  17. Use the OTR to store all UI-related text.
  18. Do not set actions to take a user off the page from a radio button or drop down elements without a go button.
  19. To skip over Hint text, like (mm/dd/yy) after a date field, set the set the “design” property of the UI Element to “groupTitle”.

...

  1. Testing that you can get to all UI elements using just the keyboard. Check tab chain.
  2. That JAWS is reading everything properly: did everything get read?
  3. Screen changes:  make all dynamic changes below the cursor or announce that something has changed above the cursor.
  4. Context changes must be communicated before hand.
  5. Predictability of screen interaction. (Radio button click changes screen)
  6. Using color for meaning: look for alternate ways to convey the meaning. Semantic color - badValueRed instead of Red - but this doesn't work for people who are color blind instead of blind.
  7. Look for text that relies on visual cues (click the round button)
  8. Check that color contrast is high enough (n/a if standard colors are used
  9. Look out for flickering.
  10. Timed responses – for accessibility, need to have ability to stop the timer; disable UI element time trigger
  11. Cursor changes – setting in JAWS, announce % complete
  12. Images of text – screen reader can’t read this, use tool tip (is decorative property can be set equivalent of empty alt tag)
  13. Watch out for animations with meaning
  14. That container elements contain accessibilityDescription - SAP recommends you put titles on complex elements, any element that is a container of things, tables (caption), groups, etc
  15. Any application that has financial obligation/commitment, have ability to undo or confirm and submit.
  16. Check for logical order of cursor tab changes.
  17. Look for hotkeys enabled and that they move in a logical order
  18. Provide alternatives for non-text fields (e.g. pie chart, graphic); provide link/table with same data – tables are accessible

Usability Rules

  • Trays are strongly discouraged because they can confuse users. Programmatically hide elements instead.
  1. TextView versus InputField-ReadOnly
    • For text fields that will always be read-only, developers should use TextView (not InputField-ReadOnly).
    • For text fields that will sometimes be editable but under other conditions read-only (e.g. HSA Details screen), developers would prefer to use InputField-ReadOnly.
    • For screens that have a mix of field types, group things accordingly.   Keep TextView together or InputFields together for better visual user experience.  Try not to alternate or mix types.
  2. For confirmation screens and button order, follow the SAP standard of ordering the buttons in order of "Yes/No".
  3. For pop-ups that contain variable length texts ..... <Mark/Carolyn looking at this>develop your own custom view.
  4. For Search Helps, see rule Accessibility rule #14 above.
  5. Layout choices:  Matrix, Flow, Grid, or Row....   Matrix and Grid seem to be the leade
  6. UI Element formatting - details on formatting click here
  7. When launched, WDA applications should launch in a new, chrome-less window.  Browsers' Back button has been disabled SAP.
    • Need to verify with SAP any plans to enable Back button
    • Need to re-visit when apps are incorporated into SAP Portal.
    • Replace the "Home" link at the top of each WDA application page.  Use the more accurate text "Close" rather than "Home".
      • The Close link should be positioned in upper right hand corner of the app, just after the Help link.
  1. #* #** Separate Help and Close links by setting vGutter property in each to medium.
  2. Tables and ALV handling (findings based on NW 7.02)
    • See Carolyn's notes on Automatically calculating totals, Javascript errors, multiple UI elements in single cell, focus within dropdown list.

Miscellaneous topics

Development packages

  • If you create a WD App as a local object ($TMP) then move it to another development package (e.g. ZHR0), the corresponding ICF services will not automatically move to the new development package.  The same thing happens when you delete a WD app – the corresponding ICF is never deleted.  You must manually update the ICF service package.

Performance tips

SAP test components