Correct Keyboard Interface for Main Menu

1 Initial Problem

The Main Menu in ILIAS 7 fails

• the Success Criterion "1.3.1 Info and Relationships" respectively "Prüfschritt 1.3.1b HTML-Strukturelemente für Listen" requires that the HTML of collections of similar items are done as ul, ol. 
• the Success Criterion "2.4.3 Focus Order" respectively " Prüfschritt 2.4.3.a Schlüssige Reihenfolge bei der Tastaturbedienung" requires that the focus order is sensible. 

2 Conceptual Summary

• The Main Menu follows the recommendation of the WCAG and BITV for the behaviour of web menus and tree view navigation. Thus ...
  • it bears the semantically correct HTML tags, e. g. the nav-tag for the navigation area, the ul/li-tags for nested unordered html lists, a.s.o.,
  • keyboard control follows the recommendation for menus, such as
    • arrow keys for navigating the menu (up/down arrow keys for moving the focus within the menu, right/left arrow keys for opening and closing sub menus (ILIAS slates))
    • enter key for triggering hyperlinks and (in addition and alteratively to the arrow keys right/left) opening/closing sub menus (ILIAS slates).
  • after triggering an entry in main bar or slate, ILIAS will take user to the requested content (from main bar to a requested slate, or from slate to requested "subslate" or content). All slates disappear as menus usually do when an item is triggered.
• Tabbing back from the content user get to the first entry of the Main Menu.
• The focus order is sensible:
  • From the header user tabs into the main menu and then uses arrows within the menu.
  • The focus moves down the main menu and once slate is triggered, the focus is moved to the first entry in the slate.

• https://www.w3.org/TR/wai-aria-practices/#TreeView
• https://www.w3.org/TR/wai-aria-practices/examples/treeview/treeview-2/treeview-2a.html

3 User Interface Modifications

3.1 List of Affected Views

• Main Bar

3.2 User Interface Details

Main bar

3.3 New User Interface Concepts

none

3.4 Accessibility Implications

This will improve the overall accessibility of ILIAS. Specifically ILIAS will pass 1.3.1b and 2.4.3.a.

4 Technical Information

{ The maintainer has to provide necessary technical information, e.g. dependencies on other ILIAS components, necessary modifications in general services/architecture, potential security or performance issues. }

5 Privacy

{ Please list all personal data that will need to be stored or processed to implement this feature. For each date give a short explanation why it is necessary to use that date. }

6 Security

{ Does the feature include any special security relevant changes, e.g. the introducion of new endpoints or other new possible attack vectors. If yes, please explain these implications and include a commitment to deliver a written security concept as part of the feature development. This concept will need an additional approvement by the JourFixe. }

7 Contact

• Author of the Request: Wolfgang Schmidt-Sielex
  
• Maintainer: {Please add your name before applying for an initial workshop or a Jour Fixe meeting.}
• Implementation of the feature is done by: {The maintainer must add the name of the implementing developer.}

8 Funding

If you are interest in funding this feature, please add your name and institution to this list.

• …

9 Discussion

Schmidt-Sielex, Wolfgang [WSS] 2023-07-20: Feature has been discussed by a sub-group of SIG accessibility. The sub-group renamed the request from 'Accessible Main Menu' to 'Correct Keyboard Interface for Main Menu' and pushed it to 'suggested for 10'. Request needs changes due to some accessibility issues that have already been solved in the Main Menu.

Klees, Richard [rklees] 2023-11-22: I want to point out one crucial thing regarding the discussion here: There is no such thing as a "Main Menu" in ILIAS, we have a Main Bar. The Main Bar can contain Menus (such as the Administration Menu), but also other, more complex, means of navigation, such as a Tree. It indeed, e.g., also contains the help ATM, which IMHO clearly ain't a "Menu" of any sort. This might sound like a superficial argument at the moment, but please notice that various discussion, e.g. regarding the tree, as well as possible usages of the Main Bar via Plugins etc. don't stick to the menu paradigm but instead will be more complex than a nested list of links. This is not an argument against improving the navigation via keyboard, but this move won't be successfull if it only thinks of the Main Bar as a simple "Menu".

10 Implementation

{ The maintainer has to give a description of the final implementation and add screenshots if possible. }

Test Cases

Test cases completed at {date} by {user}

• {Test case number linked to Testrail} : {test case title}

Approval

Approved at {date} by {user}.