ckeditor: accessibility: Make text on Editor preferences screen understandable to average user.

In UVA's local instance of Sakai 20, is working on changing this text.

's student accessibility testers requested the "Tip" text at the bottom regarding using the editor with a keyboard. Rather than have static text about a command that may not be accurate for all users for this "Tip", Mitch proposed to create a Sakai property for its text, so we can link to the Help article What are some keyboard shortcuts for the Rich-Text Editor? and individual institutions can customize the text as needed (or simply not include the tip on the page by omitting the property).

Proposed text for UVA's instance:

Tip: For steps to use the editor with a keyboard, see What are some keyboard shortcuts for the Rich-Text Editor?

I can update the description of this jira to include the customizable tip text.

The Sakai UX Group reviewed this today.

The comments above seem to relate to instead of the rewording of Preferences. We didn't see any questions for the UX group, but we are okay with the wording changes.

Thanks, ! Putting the keyboard on the right above CKeditor looks good to me.

I've created a parent jira for ckeditor accessibility, and added a subtask with your suggestion.

after discussing with colleagues today, we agreed that the keyboard icon above each editor (Option A) would be the appropriate approach. The icon should be in context with the editor, and would be confusing at the top of the screen because the editor doesn't appear on every page. However, my colleagues thought it would be best to place the icon to the right above the editor (rather than at the left as shown in your screen shots), so the icon would not distract from other content on the page.

Of note, this is how Canvas approaches the issue: https://community.canvaslms.com/thread/18102-shortcut-keys

Of course, the icon would need to be in each page's tab order before tabbing into the body of the editor.

As my colleagues mentioned, to include all Sakai hotkeys in one location may be confusing on pages where some of the hotkeys do not appear, especially if you have to tab into a specific area (e.g. Editor text area, Gradebook table) before a hotkey can be triggered. The following items have hotkeys of which I am aware:

• Portal: (first things shown/announced when navigating with keyboard) Jump to Content, Tool Menu, Sites list.

• Gradebook: You mentioned these hotkeys above.

• Tests & Quizzes: When taking a timed test, screen reader users can use a hotkey to make the screen reader announce time remaining.

• Editor: The issue we are discussing here.

A separate jira should be created for adding the keyboard icon above each instance of CKEditor - do you have the chance to file one and link this?

Regardless, I believe the wording on the Preferences page needs to be edited because, as we discussed in the accessibility meeting last week, it's currently hard to understand. I will update the description accordingly, with the understanding that we will use a separate jira for addressing the larger issue of the hotkeys.