Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

menuOptions in MathJax 3 seems to be ignored altogether #2855

Closed
fast-reflexes opened this issue Mar 21, 2022 · 7 comments
Closed

menuOptions in MathJax 3 seems to be ignored altogether #2855

fast-reflexes opened this issue Mar 21, 2022 · 7 comments
Labels
Code Example Contains an illustrative code example, solution, or work-around Duplicate Fixed v3.2
Milestone

Comments

@fast-reflexes
Copy link

Issue Summary

Tried in Chrome 98

Steps to Reproduce:

According to https://docs.mathjax.org/en/latest/options/menu.html, the options.menuOptions.settings configuration object should enable the user to, for example, turn off assistive MML(assistiveMml) and remove math from tabbing (inTabOrder). However, these options do not seem to work at all.

With the following configuration:

MathJax = {
  options: {
    enableMenu: true,
    /*renderActions: {
      assistiveMml: []
    },*/
    menuOptions: {
      settings: {
        semantics: true,
        assistiveMml: false,
        inTabOrder: false
      }
    }
  }
};

... I would expect all math to be out of tab indexing, assistive mml to be disabled and the math menu to show (and some semantics feature to show in the code). The menu is indeed available but so is assistive mml and all math are included in tabbing. If I disable the math menu and uncomment the block in renderActions, I accomplish what I want, but this is not what the documentation says. Also, I should be able to disable math menu but still have tabbed math, which I can't.

Sandbox: https://codesandbox.io/s/pure-mathjax-v3-menuoptions-xdk7fc

In MathJax 2, the options for including math in tabbing works great and interplay with the menu being enabled flawlessly, e.g., I can enable the menu and disable the tabbing and vice versa with

MathJax = {
  menuSettings: { inTabOrder: false },
  showMathMenu: true
};

Sandbox: https://codesandbox.io/s/pure-mathjax-v2-menuoptions-f8c3n5

Any other information you want to share that is relevant to the issue
being reported. Especially, why do you consider this to be a bug? What
do you expect to happen instead?

I would expect these settings to control what the documentation says and that the control would be independent from other settings, such as enableMenu.

Technical details:

  • MathJax Version: 3.2.0
  • Client OS: Mac OS Catalina 10.15.7
  • Browser: Chrome 98.0.4758.80 (Official Build) (x86_64)
@pkra
Copy link
Contributor

pkra commented Mar 21, 2022

Also, I should be able to disable math menu but still have tabbed math, which I can't.

Not a response regarding whether this is expected MathJax behavior but in such a situation (menu present, output not in the tab order) the page would fail WCAG 2.1.1 (all functionality must be keyboard operable).

@fast-reflexes
Copy link
Author

fast-reflexes commented Mar 21, 2022

Aha..

  • So this behaviour changed from version 2?
  • If so it should be clearly documented that the menu cannot be visible with tabbing disabled
  • What about the assistiveMml thing? I didn't manage to turn that off (using the property in menuOptions) no matter if the menu was enabled or not.

@dpvc
Copy link
Member

dpvc commented Mar 21, 2022

There is a bug where of some of the sticky value (the ones set in the menuOptions.settings variable) are not being initialized correctly. This was reported in #2786, and is fixed in pull request mathjax/MathJax-src#769, so it will be working in the next release.

Both the Assistive MML and the tab order settings were subject to this problem, along with a few others. The semantics setting is not one of them, so you can see in your example that that one is working (if you show the MathML for your equation). Also, the menu items are properly checked/uncheck, so the settings are not entirely ignored. They just don't initialize properly.

In the meanwhile, here is a configuration that applies the patch from the pull request:

MathJax = {
  options: {
    enableMenu: true,
    menuOptions: {
      settings: {
        semantics: true,
        assistiveMml: false,
        inTabOrder: false
      }
    }
  },
  startup: {
    ready() {
      const {Menu} = MathJax._.ui.menu.Menu;
      
      class myMenu extends Menu {
        constructor(document, options) {
          super(document, options);
          this.applySettings();
        }
        
        applySettings() {
          this.setTabOrder(this.settings.inTabOrder);
          this.document.options.enableAssistiveMml = this.settings.assistiveMml;
          this.document.outputJax.options.scale = parseFloat(this.settings.scale);
          if (this.settings.renderer !== this.defaultSettings.renderer) {
            this.setRenderer(this.settings.renderer);
          }
        }
      }
      
      if (MathJax.version === '3.2.0') {
        MathJax.config.options.MenuClass = myMenu;
      }
      MathJax.startup.defaultReady();
    }
  }
};

So this behaviour changed from version 2?

Only accidentally due to this initialization bug. But Peter is right, these settings are not in compliance with WCAG specifications, and should only be used if there is a very good reason for it. While it is possible for a user to enable the tab order setting in the menu, an assistive user who is using the keyboard rather than the mouse will not be able to get to the MathJax menu if the math isn't in the tab order, and so you will have made your page inaccessible to such a user. It is much easier for a non-assistive user to turn off the setting than for an assistive user to turn it back on, so it is best to leave the tabbing order as is, unless you either don't care about such users, or know for certain that you will not be having any of them visit your site (e.g., if your site is for a specific audience and you know there are no assistive users in it).

@dpvc dpvc added the Duplicate label Mar 21, 2022
@dpvc dpvc added this to the 3.2.1 milestone Mar 21, 2022
@fast-reflexes
Copy link
Author

fast-reflexes commented Mar 21, 2022

Thanks for a great answer. I admire the extra effort for assistive users, even though in a lot of cases it boils down to non-assistive users wanting to get rid of the extra resulting details in graphics and ux ... But I agree with you from a principal level... So the idea is that as long as you have regular text, there are very many assistive technologies and such to help out but once it is typeset by MathJax, then an assistive user can't use those tools anymore and that's why you're putting so much effort into these features? Just guessing here...

All in all, there should be a flag in browsers / window object which indicates to libraries whether we want to enable assistive features and based on that do different things (e.g. useAssistiveDefaults if in assistive mode or something). Because I think most people would want to please assistive users too but maybe not at the cost of, what they see, as a lower experience for a larger user group.... then ofc it's debatable whether the experience is really worse or if it's just a mental hangup but....yeah this is a different subject altogether :)

But very happy with the answer! Thanks!

@fast-reflexes
Copy link
Author

But the documentation is hopefully improved by 3.2.1 then so that it's clear, both what is possible and not and also why this design was chosen :)

@fast-reflexes fast-reflexes reopened this Mar 21, 2022
@dpvc
Copy link
Member

dpvc commented Mar 21, 2022

Thanks for a great answer.

You are welcome. Glad it helped.

there should be a flag in browsers / window object which indicates to libraries whether we want to enable assistive features

I understand your desire for that, but the assistive community is very hesitant to signal their disabilities with features that can be tracked. If there is a setting that the browsers can determine, then web sites can save information about that that identifies them as disabled, and that can be used in a discriminative way. So it is important to have assistive features turned on by default, so there is no (trackable) signaling of who needs them. I'm sure you can agree that protecting anonymity for these vulnerable groups is important.

here are very many assistive technologies and such to help out but once it is typeset by MathJax, then an assistive user can't use those tools anymore and that's why you're putting so much effort into these features?

That certainly is part of it. Screen readers can't make sense of the tag soup that MathJax has to use to lay out mathematical notation (which is very 2-dimensional compared to plain text). But since MathJax output has a contextual menu, we would need to use the tabbing order no matter what its output was (text or not), since that menu would need to be accessible by keyboard, and that means it must be in the tabbing order, according to the specs. Anything that is compliant with the WCAG specifications needs to do that.

it boils down to non-assistive users wanting to get rid of the extra resulting details in graphics and ux

I understand the feeling that the extra tabbing and highlighting are intrusive. But every interactive element on the page has that (buttons, type-in areas, etc.), and I sometimes find that distracting as well. But when I think "This is helping users who really need it", I find it easier to accept it. Of course, users who don't want it can turn it off using MathJax's contextual menu, and they can do that much easier than those who need the features can to turn them on.

If you really object to them, you could have a button on your site called "Turn off assistive features" that would tell MathJax to turn off those features (and re-render the math on the page so that they are removed from the output).

@fast-reflexes
Copy link
Author

VERY sympathetic and reasonable ideas! You convinced me! Thanks :) 🌹

@dpvc dpvc added the Code Example Contains an illustrative code example, solution, or work-around label Mar 21, 2022
@dpvc dpvc closed this as completed Jun 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Code Example Contains an illustrative code example, solution, or work-around Duplicate Fixed v3.2
Projects
None yet
Development

No branches or pull requests

3 participants