Uploaded image for project: 'XWiki Platform'
  1. XWiki Platform
  2. XWIKI-19725

Menu are not accessible using a screen reader

Details

    • Bug
    • Resolution: Fixed
    • Major
    • 15.3-rc-1
    • 13.10.5
    • Menu
    • Unknown
    • N/A
    • Hide
      1.3.2 Meaningful Sequence
      2.4.1 Bypass Blocks
      2.1.1 Keyboard
      Show
      1.3.2 Meaningful Sequence 2.4.1 Bypass Blocks 2.1.1 Keyboard

    Description

      Menus generated by the Menu Application (https://extensions.xwiki.org/xwiki/bin/view/Extension/Menu%20Application) are not accessible using keyboard or a screen reader:

      1. Top level elements are seen only if they have an <a> tag, and skipped otherwise. This difference in tags also applies for some sub-level elements
      2. No sub level element is accessible, it seems impossible to open any drop down using keyboard or screen reader.
        The sub menus on an horizontal menu are currently only opened on hover. When focusing them using keyboard, they stay closed. When opening them by hovering, keyboard navigation works properly.

      You can test on any XWiki instance, for example top menu on https://www.xwiki.org/

      Attachments

        Issue Links

          Activity

            [XWIKI-19725] Menu are not accessible using a screen reader
            Lucas C Charpentier Lucas added a comment - PR opened here: https://github.com/xwiki/xwiki-platform/pull/2078
            Lucas C Charpentier Lucas added a comment - - edited
            1. The issue arises because the hierarchy is directly imported from the menu coded by the admin.
              A first solution is to make sure the admins don't leave any section or subsection without a link, because <a> tags are tab stops by default.
              However we can directly add some behavior in the Menu extension that adds a tabIndex to the element. Such behavior can be added in the Javascript extension of the Menu Macro. After selecting only the menu elements that have a text at the start, there are multiple ways to do this:
              • Wrap the text node in a <a> tag with a default reference such as href="#" or href="javascript:;" .
              • Add a tabIndex=0 field on the menu item itself
              • Keep the text and add a button whose function is to develop the sub menu (when needed). This solution does not require any cheap trick, but is also the most complex to implement and will need some styling. The advantage of this solution is that its also an almost ready solution for 2.
            2. The submenus need to be opened not only on hover/click, but also when focused. A solution can be found [here|https://www.boia.org/blog/making-hover-links-accessible-4-quick-tips.] This suggests to replace all css rules for "x:hover" elements to "x:hover , x:focus". This way, the behavior should be the same whether we hover or focus the element. This could create an issue if the pseudo class "x:focus" was already used, however in this Macro, there is no use yet for the pseudo classes "x:focus". To keep the submenu open even when focus shifts to subelement, we can use the ":focus-within" pseudoclass.
              A lot of sources about this specific case pointed to https://www.w3.org/WAI/WCAG21/Understanding/content-on-hover-or-focus.html  which should be considered when solving this issue. The dismissable aspect is not described in this issue. The hoverable aspect might arise and needs to be dealt with. The persistency aspect should not arise in this case.
            Lucas C Charpentier Lucas added a comment - - edited The issue arises because the hierarchy is directly imported from the menu coded by the admin. A first solution is to make sure the admins don't leave any section or subsection without a link, because <a> tags are tab stops by default. However we can directly add some behavior in the Menu extension that adds a tabIndex to the element. Such behavior can be added in the Javascript extension of the Menu Macro. After selecting only the menu elements that have a text at the start, there are multiple ways to do this: Wrap the text node in a <a> tag with a default reference such as href="#" or href="javascript:;" . Add a tabIndex=0 field on the menu item itself Keep the text and add a button whose function is to develop the sub menu (when needed). This solution does not require any cheap trick, but is also the most complex to implement and will need some styling. The advantage of this solution is that its also an almost ready solution for 2. The submenus need to be opened not only on hover/click, but also when focused. A solution can be found [here| https://www.boia.org/blog/making-hover-links-accessible-4-quick-tips .] This suggests to replace all css rules for "x:hover" elements to "x:hover , x:focus". This way, the behavior should be the same whether we hover or focus the element. This could create an issue if the pseudo class "x:focus" was already used, however in this Macro, there is no use yet for the pseudo classes "x:focus". To keep the submenu open even when focus shifts to subelement, we can use the ":focus-within" pseudoclass. A lot of sources about this specific case pointed to https://www.w3.org/WAI/WCAG21/Understanding/content-on-hover-or-focus.html   which should be considered when solving this issue. The dismissable aspect is not described in this issue. The hoverable aspect might arise and needs to be dealt with. The persistency aspect should not arise in this case.

            People

              Lucas C Charpentier Lucas
              jdennebouy Jean-Sébastien Dennebouy
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: