THIS IS AN MUA PROJECT PROPOSAL THAT WILL BE OR HAS BEEN SUBMITTED FOR POSSIBLE MUA FUNDING.  ANY EXISTING TRACKER ITEMS THAT THIS MIGHT DUPLICATE SHOULD BE LINKED TO BELOW.  

Overview

At the University of Montreal, we use Atto Editor a lot. With a new law coming into force in 2022 to make all website accessible, we need to make improvements in Atto Editor. I am proposing 6 improvements on the feature. The web accessibility consultant made some recommendations and suggestions, and our user cases are based on them.

Summary

• Project size: large
• Audience: university
• Target users: teachers, students

Goals

To make Atto Editor accessible to screen readers.

User Stories 

User stories should be specific to each requirement and provide a clear view of what you want the improvement/new feature to accomplish.

As a teacher, I should be able to....

The editor text box is not labeled. It should be tagged with the wording of the question.

To do this, the DIV with the ARIA "textbox" role must receive an "aria-labelledby" attribute having as value the identifier of the text of the question.

1. After reading the question, you land on a series of buttons without being warned of the presence of a text editor. Only JAWS mentions that there is a toolbar based on the "toolbar" role of the button group. But that does not constitute an explicit mention of the presence of the publisher. Additionally, users of screenreaders may need assistance getting started with this interactive component. So I suggest placing a little offscreen text that precedes the text editor: "You are going to meet a text editor. If you need help navigating this component, activate the following button: ". The help button, also displayed off-screen, would command the opening of an accessible dialog box, as in the following example https://labo.raamm.org/lab/tests/help-modal/index.html#modal1-btn

Example on the image:

2. The first button on the toolbar lets you show or hide the advanced buttons, much like an accordion. However, the reduced or extended state of the bar is not announced. The information should be transmitted by giving the button an "aria-expanded" attribute.

As a student, I want to hear by the help of my screen reader, that there is extension of the toolbar, when the “Show/hide advanced buttons” button is read, in order to know that there is extendable toolbar.

Visual:

3. The "Screenreader Helper" button provides information on the current formatting of the selected text. However, to access it on the keyboard or by touch gesture, you have to deploy the advanced toolbar and then go to the penultimate button in a long list. Ideally, the option would be accessible in the basic toolbar, in the first buttons.

As a student, I want to find/hear the screenreader helper button on the main toolbar, in order to avoid navigating in the buttons.

Visual:

4. Some buttons have a “selected” or “unselected” state (eg: Bold, Italic, Superscript ”). This state is conveyed visually, but it should also be communicated to screenreaders. To do this, we can add the information in the button's existing "title" attribute, after the name of the button. Sample code: <button title = "Bold, selected."> 

Visual:

5. The "Paragraph Style", "Background Color" and "Font Color" buttons open a kind of submenu advertised as a dialog box by screenreaders. This dialog displays a list of styles, but you cannot enter them in VoiceOver and TalkBack: playback continues on the other buttons on the toolbar. In addition, there is no button provided to exit it. You stay trapped inside, unless you hit Escape while in JAWS or NVDA. To make things more functional, it might be better to treat these buttons as menus, that unfold a submenu, instead of making them dialogs. The presence of the submenu would be indicated by the aria-has popup attribute, and the button's collapsed or expanded state with the aria-expanded attribute.

6. Some features like "Insert character", "Emoticon" and "Screenreader helper" open dysfunctional dialogs with screenreaders:

1. a) NVDA reads the title of the dialog box. However, if the dialog does not contain a form field, NVDA says "empty" and the text or the "Close" button cannot be read. JAWS can read the title of the dialog and the "Close" button, but when attempting to browse the contents, the focus moves to the bottom of the dialog, unless there is a form field.

1. b) In JAWS as in NDVA, it is possible to exit the dialogue with Escape. However, the focus may end up elsewhere on the page, when it should get trapped in the dialogue. This same behavior also occurs in TalkBack.
2. 
   c) In VoiceOver and TalkBack, dialog navigation results in frequent loss of focus and it is often necessary to use one-finger selection to restore it.

1. d) I noticed that the "dialog" role was given to each dialog box, but the block encompassing the contents of the dialog did not have a "document" role. Maybe we should start there to solve the problems. In addition, the dialog script should prevent the user from exiting the modal box, unless specifically commanding exit with Escape or the "Close" button. Finally, the close button should logically be read at the end and not at the beginning of the dialog box. An example of an accessible dialog can be found at: https://raamm.org/lab/tests/modal/index.html

Error messages that appear in some dialog boxes are not fully accessible. Among other things, it happens that several fields are in error, but the error message mentions only one. There should be an error message at the start of the dialog box, on which the focus is shifted. This message must include all the fields to be corrected in the form of a list. The explanations of the errors must be included in the <label> of each of these fields. For an example of accessible validation, see the link provided https://labo.raamm.org/lab/tests/formvalid/index.html

 The insertion of pictures and tables is variably supported in the four screen readers. People who use a screenreader should therefore refrain from using these editor features.

Links to existing tracker issues, forum discussions, contrib plugins

...

Requirements

... Include mockups, screenshots from similar products, links to demo sites ...

Further reading

...