Bug report: screen reader and keyboard users can't actually implement/select operations

[zersiax]

Describe the bug
A clear and concise description of what the bug is.
In my testing, I have not found a way, even with simulating mouse clicks, to actually add an operation to a recipe.
To Reproduce
Steps to reproduce the behaviour or a link to the recipe / input used to cause the bug:

1. With a screen reader running, type input in input box. Make sure autobake is selected, which I noticed is a proper checkbox now to screen readers, this is good.
2. In the search box, search for an operation. The search box still needs a lot of help, but with some screen reader trickery you can see the results. I see a "to base64" action when searching for base64.
3. This is where I used to, and still do, get stuck. There appears to be no screen reader or keyboard-only way to select, or activate, an action. This means that even with autobake, the output will just always match the input, making the tool completely useless.

Expected behaviour
A clear and concise description of what you expected to happen.
I should be able to use keyboard and/or screen reader commands to "pick" an operation to perform.

Additional context

I see some attention was drawn to this already by #1718 and that a bunch of things were already fixed, this is good. I'm just intending to highlight here that this, while probably challenging, is also the main problem for a lot of people. As a screen reader user, having labels for things is helpful for sure but it ultimately doesn't add much if the core functionality of the tool remain unusable :)
Is there any other way to add an operation to a recipe apart from dragging it? If not, that right there is going to have to be solved before any other fixes really provide much of an impact.
Easiest way I can think of is to just make a click event append a step to the current recipe, that way screen readers should already be able to get a lot further. Ultimately though, being able to navigate this using the keyboard and pressing enter or some other key to do the same thing will need to be added. I'd love to hear thoughts on this.
Disclaimer: fully blind coder, hacker, accessibility consultant, AMA, yadda yadda.

[mattnotmitt]

Hi! Sorry to hear you're having trouble - I've just had a try on my end, and am able to add operations after a search by using the arrow keys.

Pressing "down" after searching (with my cursor focus still in the search box) highlights the first item in the list, and repeated presses select the next and so on. Pressing "enter" adds it to the recipe at the end.

Could you give this a try and let us know if it works? Could absolutely be better though, it's a bit fiddly to get right.

[zersiax]

@mattnotmitt I just tried this and that does appear to work. The one problem here is that screen readers don't track focus once that autocomplete list opens, e.g. screen readers only focus one thing at a time, and when hitting down arrow in the search field, the focus is sstill going to be on the search field rather than the newly opened dropdown.
Basically that means:

• Once I hit down arrow, I don't know what is in focus.
• if I press enter, the list of search results is still in the DOM, which means it doesn't look like anything happened at first.

The easiest way to solve this is generally by using an aria property called activedescendant: https://developer.mozilla.org/en-US/docs/web/Accessibility/ARIA/Attributes/aria-activedescendant
The example 1 on this page will probably align closest: https://www.w3.org/WAI/GL/wiki/Using_aria-activedescendant_to_allow_changes_in_focus_within_widgets_to_be_communicated_to_Assistive_Technology

If for whatever reason this can't be implemented, an alternative is using an aria-live widget to communicate the currently selected operation. Some caveats:

• aria-live would have to be placed on a div/other container that is present when the page loads, it's going to work unreliably when you spawn it when it becomes necessary.
• Essentially, you'd have to inject the current inner text content of the currently focused item in the list into the aria-live element, this will make a screen reader read it out loud.
• Keep in mind that the aria-live region is part of the DOM, which means screen readers will pick it up if they happen to read the part of the DOM where that div is. Not a huge problem, but some people consider this sloppy.

I hope this helps. I'd love to actually be able to use this in my cybersecurity endeavors :)

[mattnotmitt]

Thank you for the in-depth descriptions! I'll have a stab at implementing this shortly :)

[zersiax]

No probs, let me know if anything needs testing, happy to look at a codepen or similar :)

[mattnotmitt]

I've deployed my work-in-progress version of this on my fork: https://mattnotmitt.github.io/CyberChef
I've had a play with Voiceover and it seems to read out the selected operation and its description now, but I'm not as experienced as you with assistive technologies! Have a play and let me know if there's any improvements I can make.

[zersiax]

This is much better already :) Very usable like this. If it doesn't reak anything visually I'd say go ahead and merge.