Front-end Checklist for Component Development

Credit to Vladimir Kudinov

I have been developing websites for many many years and every single time when I develop components for webpages, I go through my own checklist to prevent to having the components broken/fragile. So far, it has worked pretty well.

In this article, I would like to share the checklist I use when I develop components. Throughout the article, I will use an accordion as an example.

The list of the checklist is in order as below:

  1. Understanding Component
  2. JS-enabled
  3. Accessibility
  4. Responsiveness
  5. Touch enabled
  6. Animation
  7. Browser/Device Compatibility
  8. Print.css
  9. QA

If you have any other suggestions/feedback, please share with me.

1. Understanding Component

Before I write any code, I always spend some time to understand how the component should work. For example, let’s say we are going to build an accordion looking like:

The FS (functional specifications) for the accordion will be:

  1. Initially, all of the content boxes are collapsed.
  2. When clicking upon the header, its child content box will be expanded.
  3. When it’s expanded, the arrow will rotate 180 degree.
  4. The content box will be kept expanding even if other content boxes are expanded.

2. JS-enabled

After I understand how the component should behave, the very first thing I always do is thinking about the scenario when JS is disabled.

Credit to Delacro

Let’s say when we hide all of the content boxes with CSS (display: none;) to satisfy the FS #1 above, users on JS-disabled browsers will never be able to see the content in the content boxes.

All content boxes of the accordion should be expanded by default and when JS is loaded and detected, you can hide the content boxes with JS.

One way I usually do is:

  1. By default, no-js class will be added in the HTML body tag.
  2. In JS file, I add below code to change the no-js class to js-enabled.

When the js-enabled class is detected, the content boxes can be hidden.


3. Accessibility

Secondly, I think about the accessibility. The accessibility should be considered at the early stage of the component development. By doing so, you can much better understand how the component should be built.

Credit to Adobe

The accordion as an example should contain several ARIA tags to indicate the screen readers what is happening when interacting with the accordion.

.accordion__btn — The heading

By default, it should contain aria-expanded=”true”, aria-controls=”id of its child content box” and title=”heading description”.

<button aria-expanded=”true” aria-controls=”accordion-1" title=”Heading 1">

When JS is loaded, the aria-expanded needs to be updated to false by JS as we are going to collapse all of the content boxes.

<button aria-expanded=”false” aria-controls=”accordion-1" title=”Heading 1">

.accordion__content — The Content Box

By default, aria-hidden needs to be false. It should also contain id.

<div id=”accordion-1" aria-hidden=”false”>

When JS is loaded, the aria-hidden needs to be updated to true by JS.

<div id=”accordion-1" aria-hidden=”true”>

heydoneworks shares some great ARIA examples and you can specifically find the example for the accordion here.

My company, Squiz, also has developed a great tool to check if your web pages are met with the coding standard and passed the WCAG. It is called HTML_CodeSniffer. You should check out and start to use it.

4. Responsiveness

Once you have better ideas of the accessibility, my next consideration is how the component should work on different breakpoints.

In Web Directions few weeks ago, Ethan Marcotte and Karen McGrane empathised that we need to focus on the content level instead of the page level for the breakpoints.

I totally agree and have always been focusing on the individual component level when dealing with the breakpoints.

Credit to UENO

The component should work well independently with any breakpoints and you should not limit the breakpoints only to few page levels, for example, mq-mobile or mq-tablet. What I usually do is to set several breakpoints (e.g., mq-700, mq-900, mq-1200 etc) for each component to make it look great on any container sizes.

For our accordion example, there is not much required for the responsiveness. Though one thing we can consider is to change the accordion to tabs on bigger container sizes but that’s out of scope in this article.

5. Touch enabled

Now we have a quite solid idea of how we are going to build the component. Before starting to write any code, we need to know if we should consider the behaviour of the component on touch enabled devices.

Credit to Aaron Wade

Our accordion example won’t need any touch behaviour but most of the time I install Hammer JS and use tap instead of click which prevents some issues on iOS such as the double click event.

Also it gives you a lot of touch gestures such as pan, pinch, press, rotate and swipe so you can provide richer user experience on touch enabled devices.

If you are going to use Hammer JS with jQuery, check out this plugin.

6. Animation

Before we code, there is one more thing you need to consider, animation. Adding animation properly to components can improve the usability and make static pages more lively.

Credit to Leo Leung

There are few things you need to consider though when you do animation.

  1. Always remember, simple is the best. Don’t try to add too many animations; it will rather distract people and significantly decrease the usability.
  2. The animation should be meaningful. Having animation should indicate something has happend on user’s interaction.
  3. Use proper technology. Read my previous article, Face Off: CSS vs JS Animation for more details.

For our accordion, we need to satisfy #3 FS above so we will rotate the chevron arrow with the spring effect. In my CodePen, I used Velocity JS for the animation.

7. Browser/Device Compatibility

Now it’s time to write code. Personally I use Jade, SASS and CoffeeScript with jQuery for my personal projects.

When coding, it is important to always consider the compatibility of different browsers/devices. Especially if you need to support old browsers like IE9, many latest CSS technologies won’t work (e.g., flexbox, calc, transform, transition etc).

Credit to Wassim

One of the examples for our accordion is, on IE9, you cannot rotate the <svg> of chevron icon in the SVG Sprite. To rotate it, you need to wrap <svg> with <span> and rotate <span> instead of <svg>.

Consider those compatibility issues and also revisit those mentioned above while coding.

8. Print.css

We finally built our component. Before we send our awesome component to QA, we need to provide the print.css. The print styling is another long topic but you can check out this article which gives you a good starting point.

Credit to Alex Volkov

For our accordion, we need to get rid of the background color and make the font color to black. Also re-draw the borders to divide each box. Finally we will get rid of the icons.

9. QA

It is always a good idea to ask someone to test components you developed. With fresh eyes, there are always some issues picked up.

So you shall not pass QA?

If you followed the list above, I am very confident that you should be able to build very solid components and enjoy your work.

In Summary

The lists above are from my own experience and have been worked very well so far. But if you have any other suggestions/comments/questions, I am more than happy to discuss so please leave your thoughts :)