Fix keyboard trap

[julian-carvajal-gh]

Currently, if you visit haskell.org and attempt to navigate with the keyboard, you will find that it's impossible to go through the entire page. This is a major a11y concern, as many users rely on keyboard navigation, often with a screen reader, to navigate sites. Closes #10.

Summary of changes: This diff handles the pressing of the "tab" key by removing focus from the current element using the blur (bad name, IMO) method, and removing the current doComplete callback on tab. I also made sure the right styling is applied when focusing on the console by tabbing.

Testing

• Browsers used: Firefox, Chrome
• I tabbed through the document and made sure we can land on and leave the console. When focused on the console, it should apply the correct styles and allow us to start typing commands. See attached video.
• In Chrome, the "Accessibility Insights for Web" extension helped me visualize what the tab "steps" were.

Out of scope:

• Next to the console there are buttons to quickly insert commands like "help" by clicking on them. These weren't navigable to before, and that's not addressed here.
• I don't have a screen reader currently set up, so I don't know what a user would hear when focusing on the console. Probably something like "text area"

---

N.B. The code for this feature is ancient, and likely uses deprecated methods/patterns.

focus-in-away-tab.webm

[TikhonJelvis]

Thanks for catching this too!

I just started working at a company that does some accessibility scanning. I should see what problems our product can currently detect on haskell.org...

[julian-carvajal-gh]

My pleasure! Please tag me if you share the output from your product. I'd love to help fix any other accessibility issues.