Skip to main content

Which way is that arrow pointing!?

Posted in Design

When designing a user interface, it’s not uncommon to use some kind of toggle to reveal/hide content. There are all sorts of situations you’d need to do this:

  • Drop-down navigation
  • Some content hidden in a <details> element with a <summary> as the toggle
  • A list of <option>s in a <select> element
  • A list of <option>s in a <datalist> element

There are solid arguments against using each of these things (that probably warrant their own article), but if you have to use one, you’re probably going to need to distinguish the toggle from a normal link or button somehow. This is often done with an arrow indicator of some kind, placed inline, before or after the clickable text (probably better before).

Which way should the arrow point?

The first problem is which way or ways the arrow should be pointing in the closed and open states.

Right/down

A common approach is for the arrow to point right when the content is closed and down when the content is open.

The right-pointing arrow indicates there is something else to progress to; the downwards arrow leads the eye towards the newly revealed content. This is how the <details> and <summary> elements work before any extra styling.

A downside to this method is that the user might expect to be taken to a new page – links that take you back a page often have a left-pointing arrow, so they might reasonably assume that progressing to the next step in a process might have a right-pointing arrow.

Down/up

Another pattern would be to point down when the content is closed, switching to pointing up when the content is open.

The down arrow hopefully indicates there is content that will be revealed underneath; the up arrow tells the user they can collapse the content back up into its closed state.

A problem here is that when the arrow switches to point upwards, the user’s eye may well be led back up the page, rather than down to the location of the revealed content.

No change

Of course, you could go with one of the above for the initial closed state without changing the arrow direction at all for the open state, as the change in direction in and of itself could prove disorienting for some users.

What type of arrow is best?

So it’s not just which way the arrow’s pointing that can get a little sticky. The type of arrow you use can make a big difference too.

Arrows

It’s rare to see actual arrows (⭢) used for this kind of thing. The ‘shaft’ leading to the arrowhead gives them more movement/momentum; they feel like they’ll take the user somewhere else entirely, rather than reveal something in place. They’re sometimes employed in pagination, ‘read more’ links in article lists, or to illustrate call to action buttons, and all of these clicks would take you somewhere else.

Triangles

There can be a real problem with equilateral triangles: if all sides are the same length (or very close to the same the length) it’s certainly a neat looking arrow (▶), but where is the arrow pointing? As left-to-right readers, we follow the arrow in that same direction: is your downward-pointing arrow (▼) actually pointing up and right? Anything with a level of ambiguity needs thought, and, as Steve Krug once famously said (in a whole book):

Don’t make me think

More definite isosceles triangles, where two sides are noticeably longer than the third (⊳), are much better. It’s clear the arrow isn’t pointing where a longer edge meets a shorter edge, so there’s no pause for thought.

Chevrons

Chevrons are a commonly used alternative to triangles. The new default <select> styling in Edge uses a chevron and it’s clear which direction they’re pointing.

The downside here is that, depending on the sharpness/flatness of the angle, the right-pointing arrow could be confused with a greater-than operator (>), or a closing speech mark (›) by some visitors for whom English isn’t their first language.

What to do?

So if show/hide toggles are best avoided and every arrow direction and shape has downsides, what should we do? As with most things: test. Putting your designs in front of real users will tell you how well your arrows are understood; informing changes and reinforcing decisions.

Accessibility in your inbox

I send an accessibility-centric newsletter on the last day of every month, containing:

  • A roundup of the articles I’ve posted
  • A hot pick from my archives
  • Some interesting posts from around the web

I don’t collect any data on when, where or if people open the emails I send them. Your email will only be used to send you newsletters and will never be passed on. You can unsubscribe at any time.

More posts

Here are a couple more posts for you to enjoy. If that’s not enough, have a look at the full list.

  1. Alt text for CSS generated content

    There’s an interesting feature in Safari 17.4 that allows content added with CSS to have ‘alt’ text. I’m not sure how I feel about this.

  2. The accessibility conversations you want to be having

    In most companies, accessibility conversations centre around WCAG compliance, but that’s just the start. Thinking beyond that is where you want to be!