Keyboard Navigation support

[sirkotsky]

How might we ensure that visitors can user keyboard to navigate Formbricks?

Look into focus states and tab order, consider accessibility standards for keyboard navigation. This will help improve customer experience and greatly contribute to enhancing the accessibility of Formbricks.

@peterleequigley will be leading this initiative, I'll be helping out.

[jobenjada]

love it! :)

[peterleequigley]

Okay, I've mapped out a first draft of elements in the Surveys flow that I think should be given a custom command, and what I think they keybinds could be. You can find it in the Keyboard Navigability page in Penpot.
This structure should strike a balance of allowing navigation through the main user actions, without over-enabling every single field and overcomplicating navigation.

• I especially avoided adding more commands to fields that are already navigable via Tabbing.

I'm open to ideas for how to best inform users of the control schema here. I first tried mocking up a de-emphasized grey tooltip beneath each element with a custom command, but quickly ran into real estate issues at that tiny size. See the below design: not super legible, and some of the larger commands like the Home button get pretty chunky and awkward.

Web browsers to already have a tooltip that we can show the custom commnand on hover, but I think something more would definitely be good so they're not in the dark.

@sirkotsky Feel free to make direct changes, or just let me know what you're feeling in general!

[sirkotsky]

@peterleequigley thanks for a quick turnaround, looking into your file now, a couple of thoughts:

1. Instead of going for custom commands, I would first focus on ensuring Formbricks has all the puzzle pieces in place to provide accessible experience. One of such things is the focus state. Here is a fantastic guide into focus states.
   
2. Next up, it makes sense to look into standard keyboard commands: tab, space/enter, arrows: how you would navigate just about any website. Look into this and this guides from UK.GOV on keyboard navigation and skip link respectively.

Let me know if you need any support from my side, happy to chat more!

[peterleequigley]

Got it, I'll leave custom commands to the side for now.

• To start, then, would it be helpful if I were to run through the Formbricks flow using standard keyboard commands, and write up notes on any significant breaks in keyboard navigability (strictly using Tab, Shift-Tab, Enter, Arrow Keys, and the like)?
• The skip link article is definitely useful. I would think that we'd typically want to apply this just once per page, right? Ex. to use the skip link to pull the user to the main content of the page and bypass the primary links.
• Last, we have focus states. I quickly jumped into a survey to check, and it looks like most Tab-interactive fields (free-text, drop-downs, toggle switches) do have an existing focus state of some type.
  Are you looking for a review of the existing focus states that we currently use throughout Formbricks? If so, I can do that review--go through and pull out the focus states for different elements we're currently using, then maybe we can review them and look for ways to improve or standardize them.

Let me know what you think @sirkotsky . Thanks!

[sirkotsky]

@peterleequigley thanks!

1. Testing Formbricks would be a great start: have a look at the UX audit we did some time ago, something similar for keyboard navigation would be exceptionally useful!
2. Skip menu is usually used to skip the navigation and go straight into content. As such, it is indeed only needed once per page, if at all.
3. We do indeed have focus states, but not for all elements. For instance, I couldn't select the menu and navigate through its items.

I'm pretty sure there is much more to be discovered, but you're on the right path! This will be our first step towards making a truly accessible experience: next up, we'll cover the customer experience of encountering and completing the survey :)

Cheers!

[peterleequigley]

Okay, then action items for me:

• Pull out the focus states we currently use across different kinds of elements throughout Formbricks so we can review them.
• Start working on a keyboard navigation audit, using the same templating you did for the previous UX audit you linked.

Does that sound good?

[peterleequigley]

Okay, I tested through Formbricks for basic keyboard navigability and wrote up a summary using the same format as your UX audit.
I just saved it off as a PDF because I don't want to accidentally mess up your design repos in Github or anything, went ahead and sent it to you on Discord @sirkotsky . Let me know what you think!

[sirkotsky]

Formbricks_Keyboard_Navigability_Audit.pdf

@peterleequigley let's share it here, and don't worry about messing up the repo: feel free to send a pull request with your .md file in the insights library!

Great work on the audit, very detailed document with a lot of actions for us to take. I think what you could do is to design the experiences that require visualisation (e.g. Skip link), and the rest @jobenjada can take with the engineers :)

[peterleequigley]

Awesome! I submitted a pull request (though I'm not sure it's processing my markdown correctly, haha)

These are the items from the audit I think need a visual design element. If you agree, I'll get started on those--let me know if there are others you'd like me to add from the list.

• Skip link on Settings page (could likely be reused for most pages)
• Focus state for "..." advanced options drop-downs on homepage Survey cards
• Focus state for Copy button in code snippet of Setup Checklist page (can likely be reused for the Next Question/Previous Question/Copy Question/Delete Question buttons in the question cards in the Survey wizard)
• Focus state for Rating-type question drop-down lists

[sirkotsky]

@peterleequigley sounds like an action plan! You can quickly put together simple prototypes to help the eng team visualise what needs to be done, and that'll be a great first step! Thank you!

[peterleequigley]

@sirkotsky visualizations are ready in Penpot!

It's in the Keyboard Navigability file > Focus state changes page.

[sirkotsky]

Hey @peterleequigley!

Thank you, good job. A few things to look into before we can push it:

1. "Skip" should appear at the very top of the page regardless.
2. Ironically, the button background colour is not accessible. Let's make sure we always check colour contrast and provide at the very least AA contrast.
3. Will the Skip button have a focus state? :)
4. Do we really need a "Skip" button here? I would imagine we'll need it on the Landing page, but here it may not be necessary.

Right now, on the post-Onboarding home page, it's impossible to focus on the link itself, the focus jumps to the tooltip.

Likewise, how will I select the card itself? Is there a focus state today?

Good work on the dropdown, but do you think we could have slightly more consistent focus states? Here, they are all over the place: green and thin, black and thick, etc.

We're almost there, just a few more changes! Thanks a lot!

[sirkotsky]

Another suggestion would be to work with the user: it might be a good idea to reach out to the community and talk to some keyboard users (many among engineers as well), they should be able to give you enough insights :)

[peterleequigley]

@sirkotsky Awesome feedback. I made a number of changes to reflect those updates in Penpot, with notes on what I changed.

Here are a couple of other bullets where I didn't make changes quite yet:

• Re: 3 - The skip link's focus state (so to speak) would be as it appears there, since the skip link only appears if focused. An unfocused state would be the regular landing page with no skip link visible. Thereafter, if the user Tabs forward past the skip link, it would dismiss once more. Sorry, I should have clarified that!

• Re: 4 - I'll defer to which you think is better. My impulse would be to include it throughout each page for consistency's sake, but I also see the rationale for only including it on targeted pages with a lot of primary links.

• Post-Onboarding Homepage - I think I missed this page in my review, good catch. I checked through it and didn't find any additional issues beyond the one you found.

• Create Survey Cards - These do indeed have a focus state currently (see below), it's a similar one that we use for most other Tabbable elements (the dark blue border).

• You're right that we do currently handle focus states differently in a number of places, especially text fields in the survey creation wizard (for most text fields, we use the thin green border as a focus state). Would you prefer to unify these two focus states into one across the whole site?

• I'd assumed we were having those two different focus states for different functions (green border for fillable text, dark blue for clickable elements), but that assumption may be wrong and it might be better to just have a super consistent focus state. Let me know what you want to do.

Thanks!

[sirkotsky]

Great work @peterleequigley!

Focus state should do one job: communicate focus state, there's no need for differentiation there, so let's keep it unified. My suggestion is, don't take my word for it, find someone on Discord who uses keyboard actively and test it with them :)

In the meantime, @jobenjada I think there is a lot for the eng team to take from here and start implementing: let's keep this issue open and start by ensuring all elements have focus states as per Peter's design!

[peterleequigley]

Awesome! Let me know what more is needed (or @jobenjada if y'all need any help with building out the designs)!