Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

Designing The Perfect Accordion

Design patterns. An almost mythical phrase that often inspires either awe or resentment. As designers, we tend to think of design patterns as generic off-the-shelf solutions that can be applied to various contexts almost mechanically, often without proper consideration. Navigation? Off-canvas! Deals of the day? Carousel! You get the idea.

Sometimes we use these patterns without even thinking about them, and there is a good reason for it: Coming up with a brand new solution every time we encounter an interface problem is time-consuming and risky, because we just don’t know how much time will be needed to implement a new solution and whether it will gracefully succeed or miserably fail in usability tests.

Design patterns can be extremely helpful, mostly because they save time and get us better results, faster. We don’t need to apply them exactly as they are to every problem we encounter, but we can build on top of them, using our experience to inform our decisions because we know they’ve worked in other projects fairly well.

Over the last few years, I spent a lot of time working with various companies trying out various approaches and studying them in usability tests. This series of articles is a summary of observations and experiments made throughout the time. Tighten up your seat belts: in this new series of articles on SmashingMag, we’ll look into examples of everything from carousels to filters, calculators, charts, timelines, maps, multi-column tables, almighty pricing plans all the way to seating selection in airline and cinema websites. But before we head off to complex interface problems, let’s start with something seemingly simple and obvious: an accordion.

Further Reading on SmashingMag: Link

The Barebones Of An Accordion Link

There is a good reason why the accordion is probably the most established workhorse in responsive design. It’s an immensely useful pattern for progressive disclosure — highlighting important details of a section and revealing more details upon a tap or click, if necessary. As a result, the design stays focused and displays critical information first, while everything else is easily accessible. In fact, if you encounter a problem of any kind — too many navigation options, too much content, too detailed a view — a good starting point would be to explore how you could utilize the good ol’ accordion to solve that problem. More often than not, it works surprisingly well.

How difficult can designing an accordion be? Well, one has to consider many things. A nice example is on Schoolfinder5.

However, even a component as predictable and frequently used as an accordion has a lot of room for interpretation and ambiguity. Now, don’t get me wrong: context matters. An accordion for a navigation will require a different approach than a Q&A section. But in all the different contexts we have to thoroughly consider two things: the visual design and the interaction design of an accordion to eliminate all points of confusion and misinterpretation.

Now, if we look a bit more closely into the accordion’s barebones, it won’t be difficult to see all of its atomic elements. An accordion always contains the category title, an expanded and a collapsed state, an icon indicating expansion, and the spacing between them. Once the category is expanded, the icon should change to indicate collapsing. However, what if the user clicks on a collapsed card while another card is open? Should the expanded card close automatically, or not? What if not all items can be displayed — should the user be automatically scrolled up? Let’s take a closer look at these, and related issues, one by one.

A classic example of an accordion on Nsb.no7, a Norwegian trip-planner, with an icon aligned to the right edge of the bar, and the entire bar acting as an expansion trigger.

Choosing An Icon To Indicate Expansion Link

Now, let’s get started. What do we know? Well, obviously, in most left-to-right interfaces, the category name will be left-aligned, too. Assuming that, like in many accordions, the sub-items will slide in between two sections, what icon would you choose to communicate this behavior? An arrow pointing down, an arrow pointing to the right, a chevron pointing down, a plus, a circled plus — maybe something entirely different?

Zvv.ch9 combines two horizontal accordions with the same icon (circled plus) — one to indicate trip options, and one to indicate stops between two locations. Both of them serve the same purpose (expansion) and look similar. They clearly communicate the purpose of the icon and the behavior to be expected.

In my experience, it appears that the choice of icon doesn’t really matter as long as it isn’t overloaded with various meanings in the same UI. E.g. you could potentially use circled plus to indicate expansion, zooming and a bundle of two items in a pricing plans — and that might introduce confusion. However, in context of the accordion, users seem to understand that if some of the navigation items have an icon, while other sections do not, it’s some kind of sign that more content is available upon click or tap. We couldn’t spot any indication of one icon being more or less recognizable than others. However, it doesn’t mean that some options might not cause more confusion than others.

Ableton.com11 uses a plus icon to indicate both a bundle deal (above) and expansion (if you scroll down the page). With icons having multiple meanings here, it might be a bit confusing, because some users might expect either expansion when clicking on the icon at the top (but nothing happens), or no interaction when clicking at the plus icon at the bottom (acts as expansion). (View large version12)

For example, Slack13 uses an arrow pointing to the right, although accordion items slide in vertically between category titles, rather than from to the right of it. Now, at this point it’s worth asking what purpose the direction of the icon should have? It should probably serve as an indicator of the direction of movement, or more specifically, where the user’s view will be moved to once the icon has been tapped or clicked. In Apple Mail on iOS, for example, the chevron pointing to the right maps to the movement of the user’s view from left to right.

On Slack16, pricing plans appear as collapsed accordions on mobile, with the chevron pointing to the right, while the movement is happening from top to bottom.
In Apple Mail on iOS, for example, the chevron pointing to the right maps to the movement of the user’s view from left to right. (Large preview18)

Having a mapping between the direction of the icon and the movement of the user’s view seems reasonable, but since different interfaces behave differently (with mysterious icons often playing mind games with users) not everybody will be expecting this behavior. So in the end, it doesn’t really matter what you do as a designer: one way or another, you won’t be able to match the expectations of some of your users. When designing, we tend to focus on what we are designing, but even if we are extremely consistent in our UIs, our users will come with expectations influenced by their experiences on websites we’ve never even seen. The key, then, is to be as resilient as possible and provide an easy, straightforward recovery in case the expectations aren’t met.

The plus icon might be loaded with different meanings. On Leica21, the plus prompts a lightbox in which the product is displayed. Some users might not expect that behavior. A loupe zoom icon might be less ambiguous here.

So looking back at the choice of the icon then, if the accordion items slide in vertically, intuitively it seems safe to use any of the icons listed above except the icon pointing to the right. The only issue to consider here would be if the icon you choose is already overloaded with another meaning in a different context — for example, if you’re using a plus icon to highlight the parts of a bundle deal in a pricing plan (where the plus is not clickable), and then use exactly the same plus icon for the accordion. In such a case, it’s better to avoid using exactly the same icon for different purposes as it might cause confusion.

Is it all cleared up then? Well, not really.

Let’s think about the expected interaction for a second. While the arrow and chevron usually serve as cues for change in the indicated direction, the plus indicates addition and expansion. In both cases, the change can happen in various ways: a tap on the icon causes either an overlay with navigation items appearing above the content, or the items to slide in vertically (not horizontally). So far so good.

What behavior should users expect when seeing an arrow in the navigation menu on tifwe.org23? It’s clear that an icon on the right of the navigation items indicates a submenu, and the design makes good use of available space. The category title is a link that jumps straight to category, while the arrow prompts expansion.

However, when a user lands on a page, initially they don’t know if they’ve landed on a long-scrolling page with links jumping to some parts of the page or just a “regular” website with sections existing on their own separate pages. Quite often, an arrow pointing down triggers jumps to sections within the page, rather than expanding navigation options. It’s likely that the user might have been disoriented in the past, being brought to a section of a long page and then returning back to the top of the page, and continuing from there.

Icons are often ambiguous. On Qso.com25, how can users know for sure if the click on a button at the bottom of the screen will expand the area as an accordion or scroll them down the page? In this case, the user is scrolled down the page. It might be a problem as a chevron often indicates expansion. (View large version26)

As a result, if you choose to use an arrow, you might end up with some users expecting to be scrolled down to that section of the page, rather than see subitems sliding in between categories. Thus, the chevron seems to be a safer and more predictable option; if you choose to use it, then point it down in a collapsed state and point it up when expanded. For the plus icon, you could choose between the minus icon or a close icon instead.

Arrows on the Papillons De Nuit28. What are you expecting to happen when clicking on arrows at the top of the page, and on the right of the page? The arrow on the top acts as a hint (and does nothing on click), while the arrows on the right scroll the user to the sections of the page. Not every user might expect this behavior. (Large preview29)

So, what does all of this mean for us, as designers? First, if accordion items are supposed to slide in horizontally from left to right, it’s safe to use an arrow pointing to the right. Secondly, if accordion items are supposed to slide in vertically from top to bottom, either a chevron pointing down (not arrow!) or a plus icon might work well.

With this in mind, a choice of the icon should be a quite straightforward decision. But depending on how close that icon is to the category title, it might cause confusion, too. Now, what options do we need to consider when choosing the position of that icon?

Choosing The Position Of The Icon Link

Options! Nevermind which icon you’ve chosen, you could choose to place it a) to the left of the category name or b) to the right of it, or c) align the icon along the right edge of the entire navigation item bar, spacing out the icon and the category name.

Sometimes a click on a text label leads to a separate category page and a click on an empty space does nothing. That’s why, when wishing expansion, some users will try to hit the icon rather than the category or the empty space. Research by Large view.32

Does the position matter? Actually it does. According to Viget’s “Testing Accordion Menu Designs and Iconography33,” some users tend to focus on hitting specifically the icon, rather than the entire navigation bar. There is a simple reason why it happens: in the past, some users might have been “burned” with alternative implementations of the accordion. On some websites, the category title doesn’t trigger expansion and instead goes straight to the category. In other implementations, a tap on the navigation bar doesn’t cause expansion nor jump into the category — it does absolutely nothing.

Although we’ll of course design the entire area to be a hit target, as not every navigation has this behavior, some users won’t know if your navigation is one of the “bad ones” or “good ones” until they actually click on it (or hover over it). As hover isn’t always available, hitting the icon just seems to be a safer bet — a click on the icon will almost always trigger the expected behavior. That’s an important detail to know when designing an accordion.

Across various interfaces and implementations, it seemed that with the icon placed to the right of the category title, users choose to focus on the icon more often than if the icon is placed on the left (where users click on the category’s title or the empty bar). However, some users still tend to choose the icon. Consequently, it’s a good decision to make the icon large enough for comfortable tapping, just in case — at least 44×44 pixels in size.

Left-aligned, right-inlined or right-aligned? It doesn’t seem to matter that much. But if you have a group of accordions (maybe living in a navigation menu), with the length of category titles varying a lot, toggling the accordion states across many sections will require slightly more focus than just running down the navigation bar from top to bottom. It’s just that the mouse pointer or finger has to be repositioned all the time to hit that fancy icon! Also, if the icon is right-inlined, on a narrow screen the finger would need to travel across the navigation area, obfuscating the view. With the icon positioned on the right edge of the bar, this issue would be resolved.

But if the icon is aligned to the right edge of the bar, we still need to be careful not to place it too far from the category’s name. Visually, it should be obvious that expansion relates to the category; so, in different viewports, the position of the icon could change to keep the visual connection obvious. Also, the icon could become slightly larger on wider screens. This option seems to be preferable for a group of accordions, but doesn’t really make a big difference for a single accordion — well, unless your data proves otherwise.

Designing Interaction For The Accordion Link

However, even with all these fine details out of the way, the interaction still raises some questions. Let’s assume that the category title is left aligned and the icon is aligned to the right edge of the bar. Following up with the discussion above, what should happen when a user clicks on the category name or on the icon or on the empty space in between? Should they all trigger expansion or should they serve different purposes?

Well, we can be quite certain about one thing: When the user clicks on the icon, they are probably expecting some sort of expansion, so a tap on an icon surely should prompt expansion. The category title, however, could be clicked with the intention of jumping straight to the category or with the intention of expanding.

If the category title triggers expansion, we definitely need to provide a link to the category in the sub-dropdown menu to let users jump right to that section (such as “All items”). That means that the user’s journey from the front page to a category might cause confusion because they wouldn’t expect to need an extra tap when clicking on the category title. However, recovery in that case is obvious and doesn’t really force user to restore the previous state as they can continue right away.

If the link to the category in the accordion is obvious, it won’t feel disruptive, whereas jumping to a category instead of having to expand the navigation item and then return back might feel disruptive. That’s why it’s probably more reasonable to have both the icon and the category title triggering expansion. It’s just less obtrusive this way. Should this interaction happen in between the category title and the icon as well? Some designers might argue that when a user taps on the area when navigating the site, they might not want expansion but rather “anchor” the mouser pointer to start scrolling on the page, and consequently it feels disruptive. That’s possible, of course, but it’s unlikely to happen if the user chooses to open a navigation menu to explore the navigation options.

The closer the tap happens to the icon, the more likely users will expect expansion. It doesn’t mean, though, that the closer the tap happens to category title, the more likely they expect to jump to the category. (View large version35)

Accordions are often used for cards, and depending on the viewport’s width, cards can be quite wide, so while some users will desperately try to hit the icon, some of your users will be used to collapsing and expanding cards by tapping on the empty area in the bar. Other users will be used to the empty area serving no purpose at all and will just ignore it. Only few will expect the bar to serve as a link to the category. In our tests, it proved to be less confusing to have empty space trigger expansion, rather than — well, frankly, anything else, so that’s what we choose to use, too.

Premier League Mobile Preview36
An accordion doesn’t have to serve only navigation. It can also display more or less details, e.g. in a table or a leaderboard table on PremierLeague.com37. (Desktop view38Mobile view39)

But what if you do want the category title to be linked straight to the category? One idea would be to bring clarity by having two visually distinctive elements that “hint” at the boundaries of elements — for example, with different background color for the icon and the category title (see the example above). In our experiments, we couldn’t notice any change in behavior and expectations — some people will still click on the category and wonder what happened. Again, having the section linked within the expanded accordion seems to be a safer bet.

Good enough? Well, we aren’t there quite yet. What if the user taps on the icon for expansion but there isn’t enough space on the screen to show all subitems? Somebody on your team might suggest to automatically scroll up the page to make sure that the expanded area is displayed at the very top of the screen. Is it a good idea?

Whenever we try to take control away from the user, that decision has to be thoroughly tested and considered. Perhaps the user is interested in viewing multiple sections at once and wants to quickly jump between the contents of these sections. Rather than making the user wonder about the auto-scrolling or jumping behavior and then scrolling back to restore the previous state, it seems less obtrusive just to keep things as they are, to leave the decision up to the user, as they can scroll down if necessary. Not many users will expect the jump to the top — not interrupting the flow or perhaps having a permalink to the section (if it’s really lengthy) seems to be a better option.

On Sony.com41, if one section is expanded and the user clicks on another section, the open section collapses automatically. This behavior isn’t consistent across websites, so users can’t rely on nor expect this behavior everywhere. Large view.42

And then another question arises: If one section is already expanded, and the user clicks on another section, should the first one collapse or stay as is? If the first section is collapsed automatically but it’s not quite what the user was hoping for, they could always open it again, but they wouldn’t be able to scan or compare both categories simultaneously. If the section stays expanded, they would have to actively close the category they don’t need. Both options seem to have reasonable use cases.

The nature of an accordion would call for automatic collapsing, but it might not be the best option in terms of usability. For accordions with many items, we tend to leave sections expanded, because the jumping around that occurs as a result of panels closing and opening at the same time is too noisy. Hence, alternatively you could provide a “collapse all”/”expand all” button, which can be very helpful when designing a schedule or a detailed table. If there aren’t that many items, then the section could be collapsed by default because the jump would be minimal. (Please notice that the section would definitely collapse for horizontal accordions — keeping it open just wouldn’t make sense.)

On The Guardian’s website, a chevron is placed on the left, followed by the category title and empty space. The entire bar triggers expansion, and the category’s home page is neatly displayed as the first option among accordion items.

And then there is something else. Nevermind the choice of icon or its position, whenever an accordion is expanded, it should be easy to immediately collapse it. This interaction shouldn’t require any extra movement of the mouse cursor or finger — just like with any other hide-and-reveal interaction. This means that the icon for collapsing and expanding should of course change when activated, but its position should remain exactly the same, allowing for an instant toggling of the accordion’s state.

Wrapping Up Link

Phew, that was a lengthy examination of a seemingly obvious design pattern. So, how do we design the perfect accordion? We choose an icon that indicates expansion (chevron pointing down or a plus icon), make it large enough for comfortable tapping and position it across the right edge of the bar. The entire navigation bar triggers expansion — with enough padding around the bar to toggle the states and a link to the category’s main page within the accordion’s category.

If we do choose to use a chevron, the direction should change on tap, and if it’s a plus icon, it could easily transition into an “—” or “x” to indicate collapsing. To keep the interaction even clearer, we can use subtle transitions or animations that would slide in and slide out category items.

Of course, your solution might be very different as your context might be very different as well, so if you are looking for an alternative solution, below you’ll find some questions we always ask when designing an accordion.

Accordion Design Checklist Link

  1. What icon will you choose to indicate expansion?
  2. What icon will you choose to indicate collapsing?
  3. Where exactly will you place the icon?
  4. How do you design a category title?

  5. How do you indicate collapse and expanded states (beyond the icon)?
  6. What happens if the user clicks on the category?
  7. Should the accordion contain a link to the category’s main page?
  8. What happens if the user clicks on empty space?
  9. Should an expanded section collapse automatically when another section is selected?

  10. What if there isn’t enough space to display all items?
  11. Should you have a “collapse all/open all” link or button?

The level of consideration required for a component as seemingly established and predictable as an accordion turns out to be an almost never-ending story of design experiments and usability sessions, because there are only a few established guidelines for the appearance and interaction of that component. While building an accessible accordion isn’t difficult46, designing an accordion that is universally understood isn’t that easy. Consequently, users often feel lost because their expectations aren’t matched or because the interaction interrupts their flow. Our job is to reduce friction and make sure it happens as rarely as necessary. With a forgiving and resilient design we can achieve just that.

Perhaps you had a very different experiences than the ones mentioned in the article? Let us know in the comments to this article! Also, if you have another component in mind that you’d love to have covered, let us know, too — we’ll see what we can do!

Stay Tuned! Link

This article is a part of the new ongoing series about responsive design patterns here, on your truly Smashing Magazine. We’ll be publishing an article in this series every two weeks. Don’t miss the next one — on fancy (or not so fancy) date pickers! Ah, interested in a (printed) book covering all of the patterns, including the one above? Let us know in the comments, too — perhaps we can look into combining all of these patterns into one single book and publish it on Smashing Magazine. Keep rockin’!

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36
  37. 37
  38. 38
  39. 39
  40. 40
  41. 41
  42. 42
  43. 43
  44. 44
  45. 45
  46. 46

↑ Back to top Tweet itShare on Facebook

Vitaly Friedman loves beautiful content and doesn’t like to give in easily. Vitaly is writer, speaker, author and editor-in-chief of Smashing Magazine. He runs front-end/UX workshops, webinars and loves solving complex UX, front-end and performance problems in large companies. Get in touch.

  1. 1

    Giorgos Sarigiannidis

    June 21, 2017 12:23 pm

    In regard to responsive design, I also found accordions to be an effective fallback for horizontal tabs, when the screen gets smaller and the tabs cannot fit in a single row anymore.

    Here’s a simple draft example that I made when I was first experimenting with the idea:

    • 2

      Vitaly Friedman

      June 21, 2017 12:43 pm

      Good point — thanks Giorgos!

      • 3

        Giorgos Sarigiannidis

        June 25, 2017 1:52 pm

        BTW, a subject that I always found interesting was how we could build entire websites (or at least entire sections/components in a webpage) which would be responsive in relation to the content itself instead of fixed breakpoints. For example, instead of converting tabs to accordion when you hit a specific breakpoint, do it only when the tabs don’t fit in one row anymore. Here’s the same pen as before, with the difference being that the breakpoint is dynamic and is calculated with javascript: (it’s not perfect, of course, but you get the idea).

        Implementing this idea to an entire webpage would probably go against many of the current best practices (you should handle your responsive logic with JS instead of CSS) and it would require building a separate responsive logic for many different components. It sounds like an interesting experiment, though, mostly because each component would be responsive in relation to its content, which would make it easily reusable between projects. With the traction that JavaScript libraries such react.js or vue.js gain, perhaps it wouldn’t be too bold looking in to it anyway.

  2. 4

    We also use accordions when screen real estate is too narrow.

    Would it be worth doing follow-up articles for each component, to demonstrate:
    – basic markup,
    – progressive enhancement techniques with JavaScript,
    – and accessibility improvements using ARIA?

  3. 8

    Robert Zikry

    June 21, 2017 5:06 pm

    What about accordions in native mobile app design? (Both iOS and Android)

    • 9

      Vitaly Friedman

      June 23, 2017 3:14 pm

      Thanks for the comment, Robert! Frankly I probably wouldn’t consider native mobile app design to be much different — I feel like all these techniques could work in a “native” context as well. However, I wasn’t personally involved in testing of iOS/Android apps, so I can’t really say with confidence that it works just as well. Sorry about that!

  4. 10


    June 21, 2017 8:27 pm

    Very interesting write-up. keenly waiting for your next article of this series. Thanks

  5. 11

    Thierry Koblentz

    June 22, 2017 1:40 am

    Hi Vitaly,

    Nice write-up!

    As a side note, I wrote Tab Panel, the right way, it shows that the implementation of both widgets (Tab Panel and Accordion) can be based on the same markup–which matters when it comes to responsive design and/or re-use (as Giorgos has mentioned already).

    Here is an example: Awesome Accessible Tabpanel.

    • 12

      Thierry, I read your article – awesome. Thanks

      Good news from my point of view is that I’m happy with our semantic base HTML structure, which is pretty much the same for both tabs and accordions. We progressively enhance with appopriate ARIA markup programatically via JavaScript. We map keyboard events to traverse the tabs and accordion “headers” without any jump links. We reveal content with ENTER key, and can tab into this content with TAB key.

      The main problem we have is with TAB and ARROW key behaviour for traversing the (closed) tabs and accordions.
      – ARROW keys traverse our tabs, but not the TAB key.
      – TAB key traverses our closed accordions, but not the ARROW keys.

      I’ve added this to our backlog. :)

  6. 13

    Shantanu Sinha

    June 22, 2017 9:50 am

    Hello Vitaly,

    Great piece of information over here :)

    Designing the perfect accordion could be very handy task. These looks pretty cool.

    What about the accordions for mobile phones, do they get easily fit there ?

    Thanks for the share


    • 14

      Vitaly Friedman

      June 23, 2017 3:14 pm

      Dear Shantanu, actually that’s exactly what the article is all about :-) Yes, the options listed above work well on mobile phones as well. :-)

  7. 15

    Much to the chagrin of my family, I would probably consider a printed collection of responsive patterns. But keeping a central (responsive!) site with all the patterns would probably suffice.

    Keep up the great work.

  8. 17

    Good read! Thx! Chris

  9. 19


    Am I the only one here who thinks that an ellipsis icon such as “…” is the best way to hint at more content? The arrow mimics a select menu ( which is a different UI element ) and the + icon is, in my opinion, more suitable to admin interfaces that lets you add/remove elements. “…” is often used on cards which I think is a design pattern quite close to accordions ( both are for content while a select menu is for options/selection ).
    And since “…” doesn’t look like an icon, I think that users would more likely click on the whole title.

    What do you think?

    • 20

      Vitaly Friedman

      June 23, 2017 3:17 pm

      Dear Franck,

      Good point! Well, actually I’ve noticed “…” being used as an indicator of settings rather than expansion of an accordion. Not sure that many readers would be expecting a vertical (or horizontal!) expansion when clicking on it. But it’s just an assumption. However, it probably wouldn’t be my first choice when picking an icon for the accordion.

      A good option though is an icon that indicates the direction of the expansion IMHO, so personally I’d prefer chevron pointing down as a primary choice, and if not possible, a circled ‘plus’ icon. Again, all a matter of opinion IMHO!

    • 21

      That was the first thing I thought, “+” is frequently being used for “add”.

  10. 22

    Daeng Muhammad Feisal

    June 23, 2017 8:24 am

    Good article!

  11. 24

    This is the very informative post, I love to read more about this.
    I appreciate your effort.


  12. 25

    Gerd Wippich

    June 28, 2017 4:08 pm

    I would like to see articles like this one on web design patterns collected in a printed book (or PDF, ePub…).
    Thanks Vitaly

  13. 26

    Tyler Bramer

    June 28, 2017 9:35 pm

    This was a very well written and informative article. I am looking forward to the rest of this series.

  14. 27

    Good article. However I want to add your summary “We choose an icon that indicates expansion (chevron pointing down or a plus icon)…placed on the right edge of the bar”.

    This works well with ‘simple’ content, but I work mainly on large management systems where the bar also contains summary information of the content it contains e.g. “35 sites 3204 users”. In this case we find that putting the summary information on the right of the bar works well – immediately to the left of the bar title we then choose a chevron pointing right as an initial indicator of expansion i.e. for an accordion panel in a collapsed state – and a chevron pointing down in the expanded state of an accordion panel.

    For example, this is how Windows indicates extra content in file explorer so it’s something that many, many users will be familiar with.

    • 28

      Vitaly Friedman

      June 30, 2017 7:27 am

      Yes, makes sense — I didn’t think about having additional details on the right edge. Would love to see a screenshot of it if possible! Thanks for the useful comment! :-)

      • 29

        Thanks but I don’t see how can I add a screenshot to this comments section :) This idea has been user tested and users generally like it because when all the accordions are in a collapsed state (we have ‘Expand all’ and ‘Collapse all’ functionality near the top of each page) they get a lot of ‘right -aligned’ summary information too – so they can decide whether they want to explore further and open an accordion panel. So basically the accordion bar serves another purpose.

        • 30

          Vitaly Friedman

          July 5, 2017 4:20 pm

          Perhaps you could upload the image on Dropbox or so and link to it here? It would be fantastic!

  15. 31

    Adam Rotmil

    July 2, 2017 9:39 pm

    Great read! Thanks for writing!

  16. 33

    Graham Armfield

    July 18, 2017 5:02 pm

    Thanks for the intetesting article. But I do have one wish, and that is around accessibility. Apart from an afterthought at the end of your article and Thierry Koblenz’s input in the comments section, the subject would not feature.

    It would be great if definitive articles on Designing The Perfect XYZ Component could include accessibility as part of the mainstream content, rather than being treated as an add-on.

    Keyboard only users – whether sighted or not – will make up a significant number of people. Designs should work for them too.

    • 34

      Vitaly Friedman

      July 18, 2017 10:47 pm

      You are absolutely right, Graham — will be looking a bit more closely into accessibility issues as well. My issues are always the scope of the article — I try not to go to deep into technical aspects, be it CSS, JavaScript or ARIA, but definitely need to revise that one to extend the section on accessibility issues related to those components. Point taken — thanks for the heads up!

  17. 35

    Veronica Hunt

    August 18, 2017 4:16 pm

    Thanks for sharing this great article! Nowadays the biggest concerning factor will be a number of site visitors who do not have JS-supported internet browsers. In the last ten years, this figure has dwindled significantly low as more people are modernizing their computers. It means you should have almost no concern due to the fact that even mobile phones web browsers support JavaScript.

    The same thing goes for logo design. We have seen plenty of changes in companies’ logos, but did we notice them? A lack of modifications is the thing that makes a bad logo now for a company which wants to be up-to-date with this always changing world.

  18. 36

    This looks like an exciting article, however, my work firewall contexts strip out all the video… It would have been nice to see some latent images rather than big gray boxes with a sad expression and “connection reset”!


Leave a Comment

You may use simple HTML to add links or lists to your comment. Also, use <pre><code class="language-*">...</code></pre> to mark up code snippets. We support -js, -markup and -css for comments.

↑ Back to top