Accessibility Role Application

1
votes

Following is a dummy implementation of our web application https://roleapplication.herokuapp.com/index.html

appArea element has role application as it contains highly complex widgets such as ms paint/editor/ms office. Navigator contains standard web widgets such as dropdown and buttons

The HTML is something similar to as specified below.

<body> <div class="appArea" role="application"> .......//Complex widgets </div> <div class="toolbar"> ......//Buttons, dropdowns </div> </body>

Keyboard functionality of appArea is handled by its code and for toolbar we rely on keyboard handling with the screen reader as they work in web browser.

Issue - When user press escape in navigator area we blur the navigator so the focus by default goes to body. Now as focus is in body then arrow keys moves the focus to toolbar and therefore user is never able to go into appArea. If focus is in appArea it works fine.

Expectation - When focus is on body then on pressing down arrow focus should inside the appArea and then appArea will get the key instead of screen reader.

Check the down arrow key functionality when page is loaded with and without screen reader.

Keyboard notes

  • Press f6 to go from widget 1 to widget 2 to navigator
  • You can use arrow/tab keys in widgets to navigate.
  • Move to navigator using f6 and press tab to go to any button and then press escape. Now focus is on body(check using document.activeElement).
  • Without screen reader our widgets captures the key on body and process it even if they dont have focus.
  • However with screen reader, when body has focus and user press down arrow, screen reader consumes the key and move the focus to navigator instead of application area which has widgets and user is unable to go to appArea using arrow keys or other keys which screen reader consume.

Note -

  • If we give role application to complete application then default arrow key handling of navigator will stop working which is not desired
  • Removal of role application is not possible as appArea is quite complex with hundreds of widgets all having their keyboard handling.
2
accessibilitywai-ariascreen-readersjaws-screen-readernvda

2 Answers

1
votes

There are three ways to interact with role="application".

  1. Hit enter on the application element, exit out of edit mode (or forms mode) and use the application as if it is another web page. You can put other elements there and the screen reader will move through those elements in brows mode.

  2. Hit enter on the application which pops the screen reader into edit mode where all keys are passed to the edit widget inside the application. and you handle everything within your application, probably on a keydown event.

  3. Control the tabindex as the screen reader presses keys using a roving tabindex.

You currently have 1 and 3 which is really confusing. If you removed the application element, it would still work just fine. It sounds as if you want 2 though. 2 is highly discouraged unless you have a screen reader user constantly testing UX or building your app. Number 2 is mostly for games and is considered the "canvas" element for screen readers. You do 2 by doing the following:

    <div role="application">
    <input type="button" autoFocus="true" value="Click me" />
    <p aria-live="polite" id="spk"></p>
    </div>

The spk element is to send messages to the screen reader which you need to do in this Window, Icon, Menu, Message (WIMM) interface. Remember that in this mode, you need to program everything and users get upset if expectations are not met.

You said you are making a word processor. This last option (number 2), is NOT meant to make a word processor. As a screen reader user, I have expectations and workflows for Word processors. You can't get that functionality with programming it manually in Javascript. Instead, use the existing edit fields HTML provides for this reason, such as: This text editor example

Please let me know if there is some reason why you would not want to use the above widget.

You could get away with using 3 along with normal widgets, but it is better to do what Google Drive does and allow users to enter edit mode when the page loads, or press a key, like escape, to enter the tabindex application area (which does not need to be in an application element, although it can be).

Edit: After reading your question again, it sounds as if you can't figure out how to enter the application element. You arrow to where the screen reader says "application" and hit enter. To get out, you either tab to the next tabindex element that is outside the application or press the special key command to exit out of the application. In NVDA, this key command is ctrl+nvda+space. On your application, the application element is the first element.

0
votes

role='application' should be used on rare occasions. As you noted, it causes all keyboard events to skip the screen reader and go directly to your app. This causes the screen reader virtual cursor to not work. Typically, a screen reader will automatically go into "application" mode (often called "forms mode") for certain types of widgets, such as an input field. If you are using widget roles, you will get this "forms mode" for free.

When you say "arrow keys" are not working, are you talking about up/down arrows or left/right arrows? They have different behaviors for a screen reader.