Improving Access Keys

1 Initial Problem

The Access Keys lack crucial options rendering them next to useless. 

2 Conceptual Summary

Background information on the Access Keys and their issues and well there are several down sides. 

Because every letter is already presumed to be associated with a browser function, some accessibility experts have advocated for the use of numerals—rather than letters—to minimize the overall impact of keyboard shortcut conflicts.
Although there are fewer potential conflicts with numerals—lack of conflicts is by no means guaranteed. 

This article adivesed to ship ILIAS with a predefined set of numerical access keys at least for the landmark roles.

Today we do not predefined access keys. But we need to reference them in Reporting Accessibility Issues and Information about Accessibility Control Concept thus we need a place to start from. 

The Access Keys should be extended to include important options missing so far.

• Main Bar 
• Metabar 
• Footer
• Tab Bar
• Content Area
• Slate
• Side Panels
• Permalink
• and maybe some more

3 User Interface Modifications

3.1 List of Affected Views

• Administration > Accessibility

3.2 User Interface Details

3.3 New User Interface Concepts

None

4 Technical Information

Killing, Alexander [alex], 6 Nov. 2019: Most of this is my code. This feature was a major part in making ILIAS accessible for the Bundesagentur für Arbeit back in 2009/10. A agree that a predefined configuration may be valuable, but it must not be "hardcoded" withouth any way to configure the keys. People using assistive technology usually using lots of keys for different applications purposes. It may even be better to make this configurable "per user". But back then we decided to make it at least configurable for the installation. This was ok for public bodies like the Bundesagentur, since they foster guidelines for the whole institution.

I would offer to take over maintainership here. The relation to other components (not only the UI framework) should be defined by an interface and guidelines how to use the access keys in my opinion.

Proposal

Key: next()
Purpose: If the current screen contains a Pagination View Control for a Main Panel, the UI element that navigates to the next page MUST use this access key.
$DIC->accessibility()->keys()->next();

Key: previous()
Purpose: If the current screen contains a Pagination View Control for a Main Panel, the UI element that navigates to the previous page MUST use this access key.
$DIC->accessibility()->keys()->previous();

5 Contact

• Author of the Request: Tödt, Alexandra [atoedt]
• 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.}

6 Funding

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

• FH Aachen

7 Discussion

Klees, Richard [rklees], 2019-07-01:

In general I support the improvement of the Access Keys in ILIAS. This feature request lacks some info and spawns some questions, though. In general I feel that the Access Keys would need a lot more improvement than simply adding some options. It might also be beneficial to consider them together with other accessibility features (e.g. the aria-landmark-roles) to create a coherent accessibility concept.

Previously I did some research that might come in handy for other people too:

• The accesskey-attribute seems to be supported by all browsers.
• There is an example on the internet!
• The last functional change was made in 2013 by Michael Jansen. All changes afterwards where concerned with compatibility and bookkeeping.

• What are "and maybe some more"-options that are supposed to be supported?
• The current implementation supports some rather generic functions (next, previous, delete). Are they supported in all ILIAS-services, modules and underworlds where we have them? How? Is there any plan to improve these?
• What is supposed to happen if I e.g. focus the "mainbar" or the "metabar" via an accesskey? For both there is no way to "open" them and I fail to see what focussing them will do. Is it that some assitive technology allows to dig in deeper from there? How is that done? Why don't we attach the access-keys directly to the things that actually trigger behaviours, e.g. "m 1" to open the first mainbar entry or "s" to open the search in the metabar?
• Why do we support to set the accesskeys in the administration instead of providing a predefined set of them? This would allow users to use them accross ILIAS-installations.
• How do you see the role of the UI-framework in the implementation of the Access Keys? The current implementation will cease to work for ILIAS 6.0 for some functions ("Repository/Last Visited", "Personal Desktop"). IMO a coherent concept for accessibility features won't emerge besides the UI-framework but needs to be coordinated with our efforts to improve the UI with the Kitchen Sink.

• Please use KS-Wording: "Side Panel" is Secondary Panel. The Slate is a thing that opens in the mainbar as well as the metabar. It won't be possible to focus both.

JourFixe, ILIAS [jourfixe], 01 JUL 2019 : We highly appreciate this suggestion to extend the existing access key concept by adding more access keys and remove keys for UI elements that will vanish with 6.0. In general, we need to discuss the relation of accessibility and UI Kitchen Sink to improve the development process.

Erkens, Jochen [j.erkens] 2019-07-11: I agree with Richard and recomend to provide a predefined set of keys. Accessibillity comes with learnabillty.
I would like to have aditional keys for:

• Edit (E)
• Save (Ctrl + S)
• Add new Item (A)

Killing, Alexander [alex], 15 Jul 2020: I still support the idea, the current list needs still clarification on "side panels" (since there are lots of them, do we target the first one, if available?) and the "maybe some more" part. If we want to ship defaults, they need to be specified, too.

8 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}.