BENEFIT OF GOOD UI DESIGN IN WEB-APPLICATIONS FOR DISABLED AND NON-DISABLED USERS

1. Anke Boeker, Dr. Tanja Schaetz User Experience, Accessibility, SAP AG CSUN, Los Angeles March 14, 2008 BENEFIT OF GOOD UI DESIGN IN WEB-APPLICATIONS FOR DISABLED AND NON-DISABLED USERS

2. Presentation overview • Accessibility@SAP • Special Challenge with Business Web Applications • UI Design in SAP‘s Development Lifecycle • SAP’s approach: Accessibility by Design • SAP’s Experience about good UI Design: Examples

3. Introduction to Accessibility@SAP … SAP provides business software solutions for large, mid-size and small companies world-wide … SAP’s product portfolio covers applications for financial accounting, enterprise resource planning, product lifecycle management, supply chain management, customer relationship management, specific industry solutions, etc. … More than 43,000 companies run SAP software … 12 million users in 120+ countries … SAP established a global accessibility program to support business professionals with disabilities to participate fully in today’s business environment © SAP 2008 / Page 3

4. The SAP Accessibility Competence Center • 2001: Established in Palo Alto, later moved to Walldorf/Germany (2003) • Maintains and develops SAP’s Accessibility standard • Supports the development teams with guidelines and check tools • Supports the Accessibility Testlab in Bangalore • First contact point for customer requests • SAP‘s first book about Accessibility („Developing accessible software with SAP NetWeaver“) published

5. The Special Challenge with Business Web Applications Characteristics about business web applications : • High complexity of screens • Editable tables • Large forms • Complex elements (e.g. hierarchies, interactive graphics etc) • High interactivity (mass data entries) • Professional web applications need to be highly efficient (average working time of business users: 8 hours/day) • Hot keys, access keys, short navigation path

6. Examples for Business Web Application ScreensI Complex search functions editable table

7. Examples for Business Web Application Screens II editable detail view editable table

8. Examples for Business Web Application Screens III editable detail view hierarchy editable table

9. Examples for Business Web Application Screens IV complex and large forms

10. Examples for Business Web Application Screens V subscreens tables graphics

11. The Special Challenge with Business Web Applications Characteristics about business web applications : • High complexity of screens • Editable tables • Large forms • Complex elements (e.g. hierarchies, interactive graphics etc) • High interactivity (mass data entries) • Professional web applications need to be highly efficient (average working time of business users: 8 hours/day) • Hot keys, access keys, short navigation path

12. WCAG 1.0 SAP Accessibility Standard UI Design Specifications Section 508 UI Design in the Development Lifecycle 1 All accessibility requirements are described in SAP’s internal accessibility standard 5 4 VPAT Accessibility Report 2 UI Design specs created based on SAP’s standard and reviewed by the ACC Milestone: begin of development Milestone: end of development/test PIL Invent Define Develop Invent Deploy Optimize 3 Accessibility Test performed by educated experts in SAP’s accessibility testlab

13. SAP‘s Approach: Accessibility by Design Accessibility by design: additional development effort: < 1% • Provide Accessibility in an early stage of development • Maximum coverage of accessibility requirements by frameworks/technologies • Easy to fix bugs in software solutions • Minimize overall development efforts • Fulfill instructions about good UI design in four categories: • Identification of UI elements • Usage of colors • Contrasts • Keyboard access and navigation

14. Proposal: One Design for all Users I • Provide a solution that offers both the graphic and the text alternative. • Examples: • Graphic and its text alternative e.g. a table are placed alongside each other on the same screen

15. Proposal: One Design for all Users II • If the two alternatives cannot be displayed side by side for layout reasons, you can place them on separate tab pages

16. Proposal: One Design for all Users III • In this dialog the user can use a button to toggle between the graphical display and its text alternative

17. Some Proposals for Dialogs I • Make a dialog easy to use. • Dialog title: verb + noun e.g. „Change Record Values“, „Download Update“ • Text: clearest and simplest language • Labels of buttons: Not „OK“ or „Yes“ or „No“. Instead „Save“, „Send“, „Print“, „Disconnect“

18. Some Proposals for Dialogs II • Order of buttons: most important button is farthest left • Default button: user can choose ENTER to activate even if it does not have the focus • Accelerator keys: quick way to navigate the focus to a target. ALT + underlined character key.

19. Some Proposals for Dialogs III • Tool tips for buttons needed: • if button only has icon and no text • if icon on button contains additional information not included in the text • if keyboard command exists such as CTRL + s for a „Save“ button • if button is default button e.g. [Enter] • if button text includes abbreviations

20. Some Proposals Concerning Keyboard Navigation I • Different user types: users who • like to use the mouse as often as possible • use keyboard and mouse • like to use the keyboard as often as possible or can only use the keyboard • want to reach all user interface elements via keyboard • only want to reach interactive elements via keyboard • Sometimes want to reach only interactive elements and sometimes want to reach all user interface elements

21. Some Proposals Concerning Keyboard Navigation II • User can customize which UI elements can be reached via keyboard • either reach via TAB key only interactive elements (e.g. buttons, editable fields, editable drop down boxes) • or reach via TAB key all UI elements • provide additional key combination e.g. CTRL + n to set focus to the next UI element in tab order and e.g. CTRL + b for previous UI element in tab order

22. Some Proposals Concerning Keyboard Navigation III • Provide accelerator keys. • Navigation with accelerator keys offers a quick way to navigate the focus to a target user interface element • ALT + underlined character key • if same character key is used more than one time on the screen than ALT + underlined character key will set the focus to the next field following the tab order with the same accelerator key

23. Some Proposals for Tables I • Make a table easy to use. • Title for every table • Column header for every column • Column header focusable by keyboard to open context menu e.g. for sorting the column or moving the column to right • Avoid abbreviations • Tool tip for every icon. Sometimes it is a good idea to add the same infomation in a textual way in an additional column. • in this column you can sort information • and you can search for this information

24. Some Proposals for Tables II • In tables rows and columns are often colored according their meaning e.g. row with a total sum, row with a sub total sum, row that shows a grouping, key columns. All colors with semantical meaning must be customizable. • Search in a table is very important. • Easy to start e.g. CTRL + f or type ahead • Immediate feedback • Explanation how to search. E.g. Can I use „%“ or „*“ or „?“?

25. Some Proposals for Tables Concerning Navigation and Selection • Efficient navigation in tables is important. Often a table has many columns and thousands of rows. • HOME, END, CTRL HOME, CTRL END • PAGE UP, PAGE DOWN • SHIFT + Space to select a row • CTRL + Space to select a cloumn • Inside the table concerning the customized navigation type. (Either only cells with interactive UI elements are reached via TAB or all cells are reached via tab.) The arrow keys work as well for navigation from cell to cell.

26. Some Proposals for Icons I • Partially sighted users often find it difficult to identify icons. Blind users do not benefit from icons at all and always need a text equivalent. • Despite this, even users without visual impairments can have trouble understanding a picture. • Each icon must be explained in a text equivalent, usually a tool tip. • An icon cannot be used to represent different functions on a single screen. Each icon must be associated with one function only.

27. Some Proposals for Icons II • The differences between icons on an screen must also be perceptible to users with color vision deficiencies. This means that icons must show differences in shape as well as in color. • Green traffic lights are square when switched on. • Yellow traffic lights are triangles when switched on. • Red traffic lights are round when switched on, and also show four beams of light.

28. Some Proposals for Tab Strips I • Meaningful title for each tab page, such as „Adresses“, „Invoices“, Logistics. Avoid using tab page titles such as „Miscellaneous“, „More“, „Details“ or „Extras“. • A minimum of two tab strips and a maximum of seven. • Most important page is the farthest left. • Do not include any mandatory input fields on tab pages. Place them above the tab page.

29. Some Proposals for Tab Strips II • Do not use tab strips if the content of one tab page depends on the information on a preceding tab page. Split the users actions into steps instead. • Two to seven steps: implement a wizard • More than seven steps: place tha data that governs the rest of the data above the tab strip. • Do not nest tab strips within each other.

30. Thank you! © SAP 2007 / Page 30