Hi Mugdhatanu Dev Goswami,
Well done working through this problem. I can tell from your code that you're thinking through the challenges posed by this design and attempting to apply feedback from previous solutions, which is good to see. You seem to have a good grasp on the basics of the flex and grid layout systems, and your implementation of the overlapping-boxes effect shows a solid understanding of the box model itself.
Looking through your code, I do have a few comments you might find helpful.
The most important observation I can make here has to do with the page's tab order. If you're unfamiliar with the concept, try pressing Tab (and Shift+Tab) a few times on this page, and you should notice that the browser will automatically focus on certain elements. Furthermore, if you press Space while focused on those elements, you will automatically "click" them, as if with a mouse. This behavior is called keyboard accessibility - it ensures that any user can interact with your page even if they (for whatever reason) don't have a mouse.
The bad news is that your page currently doesn't have any tabbable elements. If you try to tab through it, you'll notice there is no way to select any clickable element using only the keyboard. The good news is that you can usually get keyboard accessibility for free as long as you use the right element. For example, your "interval select" component is implemented like this:
<div class="toggle-data">
<p class = "daily">Daily</p>
<p class = "weekly">Weekly</p>
<p class = "monthly">Monthly</p>
</div>
The <p> tag is meant to represent a paragraph - that is, a static block of text which isn't clickable. The browser doesn't expect that the user might want to click on it, so it doesn't get included in the document's tab order. But you know what is clickable? Buttons. It might take a little extra styling with CSS to make it look right, but if you do this:
<div class="toggle-data">
<button class = "daily">Daily</button>
<button class = "weekly">Weekly</button>
<button class = "monthly">Monthly</button>
</div>
Then you'll get keyboard accessibility for free. The browser does expect that the user might want to click a button, so it will enable them to tab to the element by default, without any extra effort on your part.
The same thing goes for the ellipses icon in each of the card components. In a more functional project, a user would probably want to click them, perhaps to open some kind of menu. So instead of making it a simple image, make it a button containing an image. And while we're on the subject, buttons without text should generally have some kind of text alternative that describes what the button does. In this case, you might set the ellipses' alt text to something like "Open Category Options".
The other big point I'd like to make has to do with your heading levels. To make it brief, your markup currently looks like this (after simplifying a little):
<div class="data">
<div class="heading">
<span>Work</span>
</div>
<h2 class = "work-hours"> 5hrs</h2>
</div>
Notice how the <h2> is wrapping the phrase '5hrs', while the card header is simply a span.. If you were to ask the browser to create a table-of-contents out of these elements, it would give you something like this:
...and so on. You don't need to style anything differently here - just make the card title the heading element, and demote the 'Xhrs' text to something like a <p>. Then you'll get something a little more reasonable:
There are probably a few other things I could go into more depth on, but I think those two areas (tab order and heading order) are where you stand to improve the most right now. With that said, here are a few other things that might be worth your time to look at:
- Your use of
<article> elements doesn't really work in this context, since no component in the design is wholly self-contained - each component either controls or is controlled by some other part of the app. You could check out this article for a much deeper dive on the topic, since I don't have nearly enough space for one here.
- It looks like you figured out how to use the
:hover pseudo class in CSS, though there are other places where you've implemented similar effects using mouseover events in JS. Try to prefer the CSS option wherever possible - not only is it more performant, it also won't break if a user ever comes along with JavaScript disabled.
- On that note, consider the :focus and :focus-visible pseudo-classes. At a basic level, you can think of these as the keyboard-accessible version of
:hover - they take effect whenever a user has tabbed into an element. Usually the browser will style a focused element for you anyway, but this could be useful if you want the keyboard controls to have a similar look-and-feel to the mouse experience.
I hope at least some of this was useful.
