Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-64433

Screen reader focus unexpectedly moves to profile menu with JAWS in Chrome



    • Type: Bug
    • Status: Open
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: 3.6
    • Fix Version/s: None
    • Component/s: Accessibility
    • Labels:
    • Affected Branches:


      When using Chrome with JAWS, when pressing enter on an item that performs a same-page-action, the screen reader focus is redirected to the user profile menu and the profile menu opens in response to pressing enter. This happens on items like links that expand/collapse sections of content, or cause portions of the page to update. This is really noticeable in SCORM content.

      The behavior can be seen on the demo.moodle.net site.

      1. Launch JAWS
      2. Launch Chrome
      3. Go to https://school.demo.moodle.net/course/index.php
      4. Press Tab until you get to "Expand All"
      5. Press Enter

      At this point the user profile menu opens, and the intended action of expanding the sections does not take place.

      This does not happen with any other screen reader or any other browser. It does not happen when only using the keyboard in Chrome without a screen reader running. It also only happens when pressing Enter. It does not happen when pressing Space.

      I have not traced through the JavaScript to see if there is a problem there, but here are some other problems I have noted in that same area of the page which may be tripping up JAWS in Chrome. I don't know that any of these issues are the source of the problem, but I'm just pointing them out since the source of the problem is not obvious.

      1. The user profile is put inside of a role="menubar", but it really isn't a menubar. A menubar is intended for a set of menu items analogous to a desktop menu like "File", "Edit", etc.. The whole thing should just be a menu button.
      2. The link which immediately precedes the user profile (the message menu) is an anchor, but it has no discernible text content since the child element with the aria-label also has aria-hidden="true" on it. When active elements have no accessible name, unexpected things can happen, especially what the screen reader speaks when it encounters the link.
      3. The notifications button has the incorrect attribute of "aria-role". It should be "role".

      In some debugging I did, when I applied display:none to the profile menu, the problem went away.




            gdkraus Greg Kraus
            Component watchers:
            Adrian Greeve, Jake Dallimore, Mathew May, Mihail Geshoski, Peter Dias
            0 Vote for this issue
            3 Start watching this issue