AutoZoomOut preference not respected when navigating Left

[FS-ASmith]

If you set the AutoZoomOut preference to False, it correctly stops navigation to the Right at the level boundary. However, when navigating left, this preference seems to be ignored, and you are zoomed out automatically.

[NSoiffer]

@FS-ASmith: I'm working on a fix. I want to make sure my fix addresses the bug you found. Could you add an example: MathML + start node, along with the NavigationMode (Enhanced, Simple, Character). I assume you were doing a "MoveLeft" (left arrow).

Thanks

[FS-ASmith]

Example: With NavigationMode = Enhanced, AutoZoomOut = False, using the following MathML -

<math xmlns='http://www.w3.org/1998/Math/MathML' display='block'>
<mrow>
  <mrow>
    <msup>
      <mi>x</mi>
      <mn>2</mn>
    </msup>
    <mo>+</mo>
    <mrow>
      <mn>4</mn>
      <mo>&InvisibleTimes;</mo>
      <mi>x</mi>
    </mrow>
    <mo>+</mo>
    <mn>4</mn>
  </mrow>
  <mo>=</mo>
  <mn>0</mn>
</mrow>
</math>

The markup version returned by SetMathML looks like this:

<math display='block' id='Mtst8g9p-0' data-id-added='true'>
  <mrow id='Mtst8g9p-1' data-id-added='true'>
    <mrow id='Mtst8g9p-2' data-id-added='true'>
      <msup id='Mtst8g9p-3' data-id-added='true'>
        <mi id='Mtst8g9p-4' data-id-added='true'>x</mi>
        <mn id='Mtst8g9p-5' data-id-added='true'>2</mn>
      </msup>
      <mo id='Mtst8g9p-6' data-id-added='true'>+</mo>
      <mrow id='Mtst8g9p-7' data-id-added='true'>
        <mn id='Mtst8g9p-8' data-id-added='true'>4</mn>
        <mo id='Mtst8g9p-9' data-id-added='true'>&#x2062;</mo>
        <mi id='Mtst8g9p-10' data-id-added='true'>x</mi>
      </mrow>
      <mo id='Mtst8g9p-11' data-id-added='true'>+</mo>
      <mn id='Mtst8g9p-12' data-id-added='true'>4</mn>
    </mrow>
    <mo id='Mtst8g9p-13' data-id-added='true'>=</mo>
    <mn id='Mtst8g9p-14' data-id-added='true'>0</mn>
  </mrow>
 </math>

Navigate to the term 4x and zoom in on the 4. This makes the current Node Mtst8g9p-8. Press Right Arrow once (MoveNext command). The current node will then be 'x' or Mtst8g9p-10. Press Right Arrow again, and you will correctly be stopped because AutoZoomOut is False. The current node will still be Mtst8g9p-10. Press Left Arrow (MovePrevious command) to return to the 4, Mtst8g9p-8. If I press Left Arrow again, I expect to be blocked, but it instead moved to the plus, Mtst8g9p-6.

[NSoiffer]

[Update]: fixed mistake in naming suggestion.

@FS-ASmith: This is fixed, but I'm not sure if the behavior is what you want for JAWS.

The intended behavior for AutoZoomOut='False' is that when in a 2D expression, you have to intentionally either move up and out or use a different key (some modifier+left/right arrow) to move out. I added this because I heard from some power users that they bang right the arrow key and they want some "walls" to stop them at certain points. I don't think they expect this for linear (mrow) structures.

I tried JAWS 2023 and saw it requires moving out of an mrow. However, if I removed the mrows (which most software won't add for this example), its behavior was inconsistent for that equation. The 4x trapped me, but not the =. If anything, I would have thought the opposite would be more desirable behavior.

If you want the mrow to be included, I could change AutoZoomOut to be something like True/False/None (that way I don't have change some other code). Alternatively, a better set of names would be All/Linear/None. There is probably a better name then "Linear", but I don't like a negative like NotStrutures or Not2D.

Thoughts?

[FS-ASmith]

I'm not sure I completely understand your example. My expectation is that you get "trapped" based on the level you're currently at. So, a user would have to Down Arrow first, then be contained within that sub-expression. In the above example, you would be able to freely Left or Right arrow to move between x squared, +, 4x, =, and 0. The only parts you can Down Arrow on, are either the x square or 4x. Once you do that, then Left or Right arrow would keep you within those, unless you hit Up Arrow to get out. Does that make sense, or am I not understanding your question?

[NSoiffer]

The feedback that I received is that power users (the ones that didn't want AutoZoomOut) only want to be trapped when in 2D structures, not in linear structures. I can imagine that bracketed expressions (parens, braces, etc) might also be places where people might want to be trapped, but I didn't get that feedback. But as you know, most people don't provide feedback unless something is really bad/painful.

[FS-ASmith]

You'll have to forgive my ignorance, but I'm not entirely familiar with what counts as 2d vs linear structures. My primary concern was just the consistency between left/right navigation regarding AutoZoomOut. If navigating right trapped me within a particular part of the expression, then I expected navigating left to do the same at the boundary.

[NSoiffer]

"2d" structures are those things that require vertical displacement from the baseline. Standard examples are fractions, scripts, and radicals. Linear math are expressions that fit on a line (so not a "math" concept about a linear vs quadratic equations, etc). Examples are 2x+3y = 10. If I were to group that with good mrow structure (which is basically "order of operations), then using parens to illustrate mrows, it would be ((2x)+(3y))=10. So there is an mrow for the left hand side, along with mrows around the multiplication. My sense is that users don't want to get stuck/hit a wall in the 2x, etc.

I fix the bug where moving left was different than moving right with AutoZoomOut is false. Everything should be symmetric now. Please let me know if that's not happening.

[FS-ASmith]

Thanks for the explanation. So, using your example, if you were to DownArrow on the 2x, landing on the 2, and then you pressed Right Arrow twice, you're saying it would not be trapped and move to the +, because it's linear? That would be different than what I had expected, but I understand the reasoning. In that case, maybe providing the All / Linear / None option would be helpful then.

[NSoiffer]

Yes, that is what would happen. With those preferences, None would trap you.