Add an HTML/JavaScript drop down menu option to parserPopUp.pl.

[drgrice1]

The point of this is to make a drop down menu that can contain math mode content. A native select of course can not contain such content other than in string form which is ugly at best.

The option is useHTMLSelect. The default value for this option is 1 which means that a native HTML select element is used. That means that the current behavior of a drop down menu is used. If useHTMLSelect is set to 0, then instead a Bootstrap drop down is used instead of a native HTML select. In this case the choices must be provided that satisfy the constraint that they will work directly in HTML and will also work if placed in a \text{...} call in LaTeX. In HTML of course \(...\) or \[...\] will work and will be typeset by MathJax. Those also work inside \text{...} in LaXeX. So the drop down could have choices like \(y < \frac{3}{4}\) or Choice 1: \(y^2 = e^x\).

The drop down menu is styled to appear much like the native select, and JavaScript designed to make the drop down behave much the same. There are some differences such as the down arrow for a Bootstrap drop down menu looks a little different than that of a select element, and there is a hover/focus background color change for a Bootstrap drop down.

This depends on #1158 (those are issues I found while working on this).

[drgrice1]

Here is a sample problem for testing:
html-dropdown.pg.txt

The first drop-down in that problem does not use the new option. The others do.

[somiaj]

Being able to add mathJax to drop downs is nice, a feature I've seen others want. Everything works nicely.

I just noticed one small thing, when mousing over the drop down a dark colored button is used, which really isn't used anywhere else, so it felt slightly off. Though changing it to btn-outline-primary didn't work that well either, so I see why dark was used (the blue text was hard to read without the highlight). I dind't see a way in bootstrap to change the text color between dark and the button color when highlighted, so I guess dark is the best way to go, it just felt a bit off initially.

[drgrice1]

The hover/focus color of the button can be changed. I went with that because I didn't have a better idea for the colors. If you have a different color that you think would work better, just let me know.

Currently the native select does not have any hover indication (but does have the outline for focus). That could be changed to match if desired.

[somiaj]

I think the dark buttons just feel off as they aren't used anywhere else. Secondary buttons is probably appropriate, but they are just light grey. I like the look of either primary or info buttons a bit better with the default theming.

[drgrice1]

The primary or secondary colors are not an option for this. Those are theme-able, and these colors really shouldn't be.

[drgrice1]

I switched the hover and active colors to a light gray color. The same colors used by the graphtool.

[somiaj]

The light grey looks better to me. Thanks.

[Alex-Jordan]

The keyboard navigation is different with useHTMLSelect => 0. I don't know for sure but if keyboard navigator users are used to the behavior of the native select, it may be an accessibility issue. I'm cataloging all navigation differences that I find below. Perhaps some are not important. Perhaps some are specific to Firefox behavior for native select.

• Focus lands on an unexpanded select

  • left/right arrows on native select cycle through the options
  • left/right arrows on new select do nothing
  • up/down arrow expands a native select, putting focus on the previously selected option (if there was one)
  • up/down arrow expands a new select, putting focus on the bottom/top option respectively
  • return does nothing on native select
  • return expands the new select, putting focus on the selected option (if there was one)

• Focus is on an option in an expanded select

  • tab (or shift tab) on native select selects that option and puts focus on the unexpanded select
  • tab on new select moves focus to the next option, or if we were already on the last option it puts focus on the next focusable thing after the select. No selection is made.
  • shift tab on new select is similar, just moving in reverse
  • space does nothing on a native select
  • space selects the current option, collapses the dropdown, and focus is left on the select

• You just expanded a select using space and it had no previously selected option, so focus is not on any option

  • tab on the native select does nothing
  • tab on the new select moves focus to the first option
  • up on the native select does nothing
  • up on the new select moves focus to the last option

[drgrice1]

I am not sure that those things can be changed. At least not easily, and might be need all kinds of special cases to handle different behavior on different browsers. In fact you noted that when focus is on an unexpanded native select, that return does nothing. That is how it works in Firefox, but in Chrome return does expand the select.

The thing is that a Bootstrap drop down is not a native select. Behavior is similar in some cases, but different in others. If there is something that just must be done in the things that you listed, then we can try for that, but I don't think all of them are fully achievable.

Another difference that you didn't list is that if an unexpanded select is focused and you use the up/down arrows, then for a native select the options cycle up or down without the select expanding. However, for a Bootstrap drop down the drop down expands and the focused option is the bottom or top (respectively for typing the up or down arrow). That is something that I really don't think is going to be possible to make a Bootstrap drop down behave the same for as a native select.

Edit: I see that you did mention the last about the arrow keys cycling.

[drgrice1]

Testing further I see that there are other differences between Firefox and Chrome behavior in the things you listed. Another is what happens when space is typed when a native unexpanded select with no previous selection is focused. In Firefox, nothing is selected, but in Chrome the first option is selected (even if it is disabled).

[Alex-Jordan]

The ones that might be important are the left/right arrow differences (a blind user has no need to expand the list so could be used to using left/right arrows) and tab behavior ( just because tab is so fundamental to navigation). I'm just speculating though. I could ask our local experts for an opinion.

…

On Thu, Dec 12, 2024, 4:30 AM Glenn Rice ***@***.***> wrote: Testing further I see that there are other differences between Firefox and Chrome behavior in the things you listed. Another is what happens when space is typed when a native unexpanded select with no previous selection is focused. In Firefox, nothing is selected, but in Chrome the first option is selected (even if it is disabled). — Reply to this email directly, view it on GitHub <https://urldefense.com/v3/__https://github.com/openwebwork/pg/pull/1159*issuecomment-2538773630__;Iw!!Ka_JY85zDv0FFw!nRUhTJJJs-FEpP_i6elnzP0uXV9NgCZeN9zxrvRj6OkBWrx9pEegVjKuBmgZKdmcQx5vNQMk1IIDO2x_I9PL9SeCmGo$>, or unsubscribe <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ABEDOAAL7TDAHUU3CFFB54L2FF6VBAVCNFSM6AAAAABTHSO7SSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZYG43TGNRTGA__;!!Ka_JY85zDv0FFw!nRUhTJJJs-FEpP_i6elnzP0uXV9NgCZeN9zxrvRj6OkBWrx9pEegVjKuBmgZKdmcQx5vNQMk1IIDO2x_I9PLPA3wNak$> . You are receiving this because you commented.Message ID: ***@***.***>

[drgrice1]

I did some testing with implementing some of the things that you mentioned. It seems that there is actually very little that can be done for the up and down arrow keys. The Bootstrap JavaScript keydown event handlers are attached before any event handler that we can attach, and so theirs acts first. Furthermore, they call the preventDefault and stopPropagation methods on the event in the case of an up or down arrow keydown event. So any keydown handler we attach doesn't get anything. The left and right arrow keys we can handle since bootstrap doesn't do anything with those, and they don't call preventDefault or stopPropagation in this case.

However, in thinking about this more, I am not sure that the things you mentioned are correct for this. Even though the styling applied makes this look somewhat like a native select, it still is not a native select. Screen readers aren't going to announce things for this the same as for a native select. The options are not actual option tags. Instead they are button tags. So a screen reader will announce that.

You should check with the accessibility experts on this before anything more is done on this.

[drgrice1]

I am also seeing numerous differences with the way that Firefox and Chrome behave for native selects on several of the things you listed. I certainly do not want to attempt browser detection, and try to make the behavior match the current browser.

[Alex-Jordan]

Just letting you know, I explained about this in an email and a video for the local accessibility staff, and I am hoping to hear back at some point.

[drgrice1]

Good. Thanks for looking into this.

[drgrice1]

There is something that I noticed in testing this with a screen reader. If the default '?' placeholder is used, then for a native select the question mark is read. Gnome Orca says, "Answer 1 combo box question". However, for the bootstrap drop down the question mark is not read. Gnome Orca just says, "Push button".

I forgot to put the aria label for the answer on the Bootstrap drop down and that is why it doesn't announce "Answer 1" for the drop down. So I tested adding that, and then the screen reader says, "Answer 1 push button". However, then it doesn't read the place holder even if it isn't the '?' and is actual text. Furthermore, if the left/right arrow behavior is implemented that changes the option without expanding, then in that case it doesn't read the options as they change. In any case the visible text on the button is not read if there is an aria label.

So we may need to use a different default placeholder than the question mark for the Bootstrap drop down, and most likely the aria label is going to need to be dynamic in some way and update as the options change to include the selected option text. I don't know what to do for this though if the text contains MathJax math. I actually can't get the screen reader to do anything with MathJax math other than say "embedded" even when the MathJax accessibility is enabled.

[Alex-Jordan]

When I use Firefox and Apple VoiceOver and put focus on the native select, and use the left/right arrow to cycle through options, nothing is voiced. So maybe that is not well implemented for some browser/screenreader combos in the first place.

When I expand the last drop down using FF and AVO, it does read the math content. So maybe there is an Orca deficiency there. I also put the Chrome screen reader extension on Chrome and tried that. But it did not read the math content, just like you describe with Orca.

Maybe you already mentioned this, but I found that in Chrome with the native select, when it was expanded and focus was on an option, then tab did nothing. Also in Chrome, the left/right arrows do nothing. So these are clear signals that the bootstrap drop down does not need to do these things.

[drgrice1]

I found that if I have MathJax accessibility enabled, and you type "Enter" when a MathJax element is focused, then a popover appears showing the math converted to words, and then of course, Gnome Orca reads that. But apparently it isn't able to directly read it as you also noticed. I think that some screen readers can directly read MathML content, and MathJax embeds the MathML in the HTML in addition to the rendered SVG. That is probably how Apple VoiceOver reads the MathJax, and probably Gnome Orca doesn't support that.

You are seeing something different in Chrome than I am. So perhaps this even varies with the operating system. In Chrome for me (on Ubuntu), the left and right arrows do change the native select value, and if you type "tab" when the select is expanded and focus on an option, the select closes.

I just noticed another thing different in Firefox and Chrome. When a select is expanded and you use the up/down arrows to move to another option, in Firefox it just moves focus up and down, but the selected option doesn't change, while in Ch rome not only does focus move up and down, but the selected option does change.

I have been able to implement some of the things for the Bootstrap dropdown.

• I can make it so that left/right arrows change the value when the dropdown button is.
• I can make it so that when "tab" is pressed while an option is focused in an expanded drop down, then the drop down closes and the focused option is selected.
• I can make it so that when the drop down button is focused and expanded, then "tab" does nothing (but I think this one is wrong even though it is what Firefox does).

So we just need to figure out which things are needed, and what can be implemented.

I also implemented using MathJax's a11y/sre extension to convert an option's content with math into screen reader friendly text, and adding that as an aria label to the button. I prefixed that with "answer n". I am not sure that this is the right thing to do, but it worked rather well to voice the content and updated when an option was changed. It does require a change to webwork2's MathJax configuration (the a11y/sre extension has to be loaded of course).

[pstaabp]

The keyboard navigation seems to be browser dependent. In Safari, the left-right arrow keys do nothing on either the native select or the bootstrap ones.