warning: this is my first post (and it’s ended up quite long)

As a front end engineer, accessibility is something that we should consider whenever building a component/feature on a site. It just clicked over this COVID weekend — that I could write an article about it.

The origin story

On a recent project, we built a search component — it was nothing special, an input field and a menu that appears like an autocomplete would. It was in a navigation bar so the component had to share space with a logo and links in the navigation. This meant that there was a constrained width of say 380px for the input and the drop down, cool. We didn’t have the content that would go in the search dropdown when it was initially designed. When we did get the content the search results were A MESS. Imagine typing in “search term” and seeing 30 results in a narrow drop down you could scroll through. There’s a reason why Google autocomplete limits its results to 10. It would be too overwhelming to scroll through all the autocomplete items.

Image for post
Image for post
Google autocomplete in all it’s glory.


Image for post
Image for post
Full screen takeover search.

E-commerce sites are a good source of inspiration when looking into search practices — they have a huge catalogue of items that need to be displayed for users. I enjoy a good pair of trainers (“sneakers” for everyone else) so went to size.co.uk. I could see how their search approach could benefit the site I was working on. They display their results full screen in a sort of modal, those 30 results our site was displaying could be reduced and be presented in columns representing the categories the results are from, great.

So with my engineering hat on I thought it wouldn’t take too long to implement, maybe half a day to adjust the currently implemented solution to this modal-esque solution. On click/enter of the search input, open the modal and set the focus to the modal search input, cool cool cool. So I thought about accessibility — then I thought… OK it’s going to take much longer than half a day.

Whats wrong with it? (Part 1)

Accessibility is many things — but my initial focus (sorry) was on keyboard users. Check out what WebAIM say about keyboard users:

Focus indicators:
A keyboard user typically uses the Tab key to navigate through interactive elements on a web page — links, buttons, fields for inputting text, etc. When an item is tabbed to, it has keyboard “focus” and can be activated or manipulated with the keyboard. A sighted keyboard user must be provided with a visual indicator of the element that currently has keyboard focus. Focus indicators are provided automatically by web browsers.

So, from just testing it out — I noticed as I tabbed, I had no idea where on the site I was. I just wanted to get to trigger the search input in the navigation without clicking on it.

Image for post
Image for post
Emoji added for visual affect.

The reason why

This isn’t uncommon. Normally the reason this is applied is because the engineer/designer isn’t aware of the importance of the focus style. A user clicking on a navigation item would see this outline — which often doesn’t look good, so the focus style is removed.

Whats wrong with it? (Part 2)

I mentioned earlier that accessibility is many things. My initial focus (sorry again) was on keyboard users. Specifically sighted keyboard users. When someone is tabbing across the site they should expect to move across it in a linear fashion. E.g. I’m here, when I push tab I should be here + 1 (here to the right of it). Check out what WebAIM say about navigation order:

Navigation order:
As a keyboard user navigates through the page, the order in which interactive items receive keyboard focus is important. The default keyboard navigation order must be logical and intuitive. This generally means that it follows the visual flow of the page — left to right, top to bottom. For most pages this means header first, then main navigation, then page navigation (if present), and finally the footer. This navigation order (and also the reading order for screen readers) is determined by the web page’s source code.

So, the outline has been restored and I’ve exaggerated it so it’s easier to see, we’ve just landed on the page — let’s begin hitting that tab button to get to search:

Image for post
Image for post
Tab, tab, tab, tab, tab, Jackie Chan.

So we can see how this could be confusing for a keyboard user. I’ve actually found it impossible to get into the search dialog/modal with a keyboard (please let me know if you can). So, let’s continue this journey/experience — let’s say I could access the search with a keyboard.

Whats wrong with it? (Part 3)

So we’ve opened the search (with a mouse) and as the overlay/modal opens — the focus is set to the input field with JavaScript, yes! With my exaggerated outline styles you can see it. Elements need to be focusable to be able to set focus to them with HTMLElement.focus().

Image for post
Image for post
Over exaggerated :focus outline.

So, I was saying that I couldn’t get out of this interface. And i’m talking as a keyboard user. If I were using a mouse — sure I could click on that close button on the top right and I’m back on the page. But in this case, I’m not using a mouse. I’ve called this interface a modal/overlay/lightbox — it’s a UI that’s on top of another UI. What does w3.org suggest about modals?

Keyboard Support:

Escape Closes the dialog.

So that’s a good recommendation — as I’m in this new state I can hit the escape key to get out of it. Unfortunately this wasn’t implemented. But I did mention that close button they provide. So all I need to do is tab to it!

Image for post
Image for post
That lil close button.

So I can’t navigate to it with the keyboard, why is that?

Image for post
Image for post
That’s why semantic HTML is important.

The close “button” element is a <div>. The browser doesn’t see it as an element it needs to give a tabindex to. So by default it can’t be tabbed to.

We could fix this by giving it a tab index: tabindex="0" , or letting the browser make it tabbable with role="button" or using an actual <button> element instead of a <div>.

I’m not finished with this button. I thought I’d mention some other accessibility issues — such as how Colour contrast could be an issue. And as it’s using a pseudo element to display an icon — a user with a screen reader wouldn’t be able to read out any text, to give the user some context about what it does.

Whats wrong with it? (Part 4)

So, I’ve entered a search term and I’ve found some results — now this is an edge case here, so please bear with me. As a user I could tab from the search input field down to a result — decide it’s not for me and continue tabbing to the “Recently viewed” section, what should happen when I get to the last item?

What actually happens, the user can continue to tab — with no visual indicator of where they are:

Image for post
Image for post
Tab, tab, tab, tab, tab, Jackie Chan.

What’s happening here? If I lower the opacity of the search overlay/modal we can see what’s up.

Image for post
Image for post
Lower opacity, lower opacity, lower opacity, ab, tab, tab, tab, no Jackie Chan.

We can see what’s happening now — after the last element in the search overlay, we’re tabbing to the next item in the DOM which is outside the overlay. If we continue to tab we’ll go through the entire site while it’s hidden behind the overlay.

What should happen? Ideally when the user gets to the end of the items in the search component/widget/UI:

  1. The search widget closes and the user is back on the main page.
  2. Or the focus goes back to the start of the search component, to the input field.

Point 2 is a common practice — A focus trap is when you override default user input so that the user is kept tabbing within the modal. By adding an event listener, listening for keyup events and working out whether the event.target is in the search container, if it’s not you can assume they’ve tabbed out — so you set the focus to the first element or a close button.

What’s my point?

Building out a component can be a simple and a short task. But sometimes you can take a step back and think about accessibility before you begin implementing a solution. Like I said, this is just one consideration around accessibility — we could go through a site with a screenreader like VoiceOver and find issues.

Final thoughts:
I didn’t intend to tear this site apart and it’s likely I could go to many sites that have a search similar to this and find issue. This was just the rabbit hole I went down looking for a different search implementation.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store