You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 56 Next »

Contents

#Accessibility Rules

Accessibility Rules - Explanations and Rationales

Accessibility Known Exceptions - VPATS

#Application Help Rules

#Unit Testing Procedures

#Usability Rules

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.

Accessibility Rules - Explanations and Rationales

  1. The root container acts as a transparent container and since it is the root container, does not need a label. Therefore adding a transparent container under the root container only adds another layer of html, but does not make the application more accessible.
  2. This rule comes straight from the SAP Accessibility guidelines. The header4, header5 and header6 properties create semantic html, respectively <h2>,<h3> and <h4> tags.
  3. This rule comes straight from the SAP Accessibility guidelines. By giving each input a label, people using assistive technology will hear the input's label as a description.
  4. This rule allows SAP assistive code to associate a label with other UI elements or groups of elements.
  5. Not sure what this rule does.
  6. If an image does not have isDecorative set to true, WebDynpro will try to create an alt attribute that assistive technology will then read. Non informative images should not be announced with an alt tag.
  7. The tooltip property is what WebDynpro code uses to create the various alt and title tag content for assistive technology to read.
  8. If a tooltip repeats the label text, the code will be "read" twice by assistive technology and thereby annoy or confuse the user.
  9. Nested tables confuse assistive technology because assistive technology trys to gather semantic information (labels of table cells) from tables.
  10. Nesting grouping containers creates nested tables. See #9 for explanation of why this is bad.
  11. This rule is self-explanatory.
  12. This pattern essentially allows the developer to create two labels, one for a group of elements that includes an input, another for the input itself.
  13. The pageHeader UI element SHOULD create an <h1> tag, which is the topmost header tag on a page. It does not. If subsequent versions of WebDynpro pageHeader UI elements do create <h1> tags, this rules should be changed.
  14. This rule is self-explanatory.
  15. In the SAP GUI, tables have select buttons in the left column. When rendered by Webdynpro, these "buttons" consistently confuse non SAP-GUI users. Therefore the preferred method of making a row selectable is to make one of the first two table cells contain data with a link. Clicking on that link would allow the user to do something with that row.
  16. If the screen changes above the cursor, assistive technology may not "hear" the change and notify the user that a change occurred.
  17. The OTR tables allow for translations and the ability of non-programmers with GUI access to change text.
  18. The act of reading a drop-down "go menu" with assistive technology will fire the menu's Javascript and take the user away from the page before they have heard the other options (they will never be able to hear the other options).

Accessibility Known Exceptions, per VPATS documents for SAP ERP 6.0 Enhancement Pack 5, Netweaver 7.02

  • Incorrect number of columns is announced by screen reader for UI Element RowRepeater that uses complex layout such as nested TransparentContainers.
  • UI Element table: in some cases screen reader announces the row as selectable even though it cannot be selected.
  • UI Element ToggleButton anounced only as ""Button"" by screen reader.
  • For HorizontalContextualPanel UI Element, no level information is announced for the 2nd level row.
  • For some semantic colors of TextView UI Element there is no speech output defined.
  • The disabled state is not announced for a UI Toolbar element.
  • InputField UI Element with F4 Help is announced as ""combo box"" instead of ""Edit"".
  • For a number of UI Elements, the screen reader either repeats element information twice or makes a second announcement that differs from the first (correct) announcement when the UI Element gets the keyboard focus:
    • Groups: Sometimes ""Table"" is announced additionally at the begin of a Group and ""cell"" at the end.
    • Images: Screen reader announces ""Graphic"" additionally.
    • Radiobutton-Groups: ""0 Items"" is announced additionally even if the group has items.
  • The ""Browse"" Button of a FileUpload UI Element is not announced at all.
  • In some rare cases, instead of announcing the attributes of UI Element actually focused, the attributes of the UI Element container or the preceding UI Element are announced.
  • When navigating to the items of the UI Element ItemListBox with MultiSelection via down arrow key the items sometimes are also automatically selected.
  • Navigation to the first empty/blank entry in the dropdown of an Dropdown UI Element is not possible with the keyboard.
  • While navigating to a different Tab within UI Element Tab Strip, visible focus gets lost.
  • No visual indication for selected top level menu item.
  • If Windows runs in High Contrast theme sometimes the focus is not visible when using the Web Dynpro High Contrast theme.
  • Focus is not restored on Row Selectors in certain cases for UI Element Table when a selection is made. Instead, other elements are focused (e.g a UI Element Button below the Table)."
  • The following UI Elements are rated as not accessible:
    • Gantt
    • Network
    • BusinessGraphics
    • GeoMap

Application Help Rules

  • Application Help will be stored primarily in Hermes (http://kb.mit.edu)
  • When linking to help in Hermes use the Short link, e.g. http://kb.mit.edu/confluence/x/2gTn not the Full link
    • This is to protect against the article / title changing in the future which affects the Full link but not the Short link.
  • Launch application help window a smaller, less overwhelming window (50% sized) with no ‘chrome’ (no navigation menu, no status bar at bottom).
    • Here’s the ABAP code:

         lv_url = 'http://kb.mit.edu/confluence/pages/viewpage.action?pageId=3902416'.    "change url to your app-specific help page
         lo_window = lo_window_mg->create_external_window( url = lv_url
               modal = abap_true
               has_menubar = abap_false
               is_resizable = abap_true
               has_scrollbars = abap_true
               has_statusbar = abap_false
               has_toolbar = abap_false
               has_location = abap_false
               ).
         lo_window->set_window_size( width = '600px'
               height = '800px' ).
         lo_window->set_window_position(
               left = 400
               top = 100 ).
       
  • For now, point to Production Hermes help file URLs.
    • Mike Berger will check with Alison Bell re: release process for Hermes content, viability of pointing to non-Prod content (esp for new apps)
  • Open issue regarding browser and pop-up blockers

Unit Testing Procedures

  • A copy of JAWS screen reader software has been installed in the W92 QA test lab for use by WDA developers and QA.  This will allow basic unit testing of individual WDA components and screens.  It is not a replacement for full Accessibility testing by the IS&T Accessibility team.
  • You can also install a demo version of JAWS on your own machine by downloading it from Freedom Scientific at http://freedomscientific.com/products/fs/jaws-product-page.asp** If you will be doing frequent testing with JAWS and want the fully licensed version, see Kevin Lyons or Mary Ziegler for instructions on tying to MIT's license server.
    • Here are the recommended settings when using JAWS with SAP Portal products (click to open doc) (info) .  For example
      • For JAWS to work in WD4A, Virtual PC cursor must be turned off.
  • SAP provides a Navigating with HotKeys doc (click here to open doc) (info) to help navigate a screen via keyboard. 

Recommended Unit Test checks:

  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>
  4. For Search Helps, see rule Accessibility rule #14 above.
  • No labels