Skip to content
  • Unlock Pro
  • Log in with GitHub
Solution
Submitted almost 4 years ago

Reactjs, React hooks

Ay•495
@Aycom366
A solution to the Audiophile e-commerce website challenge
View live sitePreview (opens in new tab)View codeCode (opens in new tab)

Solution retrospective


Nothing to really ask, just test and your feedback plz

Code
Select a file

Please log in to post a comment

Log in with GitHub

Community feedback

  • Raymart Pamplona•16,040
    @pikapikamart
    Posted almost 4 years ago

    Hey, awesome work on this guru challenge. The website feels really nice and the animations are good. Layout on desktop and mobile seems good as well. Though I would recommend a bit more padding to the left and right sides just to limit.

    Some suggestions would be:

    • Have a main tag that wraps the content of your website. Always have this landmark so that other users could properly navigate and make sense of a website.
    • navbar should have been wrapped inside the header element
    • the "audiophile" link on the navbar should have a aria-label="homepage" this way, it will be more accessible and screen readers users know where this links is supposed to go.
    • lose the words "logo" "icons" when using an img element or an svg because assistive tech will handle those that is why you don't need them.
    • the navbar links could have used a structure like:
    <nav>
      <ul>
        <li>
           <a> your link in here</a>
        </li>
      </ul>
    </nav>
    

    on the a tags on your navbar, you should have used aria-current attribute. This will announce where is the users when navigating in another page on your website.

    • your .mobileNavLinks section element that you are using when it is for mobile state should be hidden using display: none or visiblity: hidden. If you try to use keyboard on your homepage, you will see that it is navigating you to a hidden link, which in your case, the link for the mobile layout. You need to replace those one.
    • Your "cart" on the navbar should have used a button element to make it accessible, along with aria-expanded attribute.
    • Your "card" dropdown should have a for example, exit button. Because if you for example open the dropdown, there is no way to exit that dropdown if you are using keyboard, and other users that uses different assistive tech will also have no way to exit. The dropdown as well could have been aside element.
    • "new product" text in the hero-section should not have used heading tag. If you included a main element on your website, instead of the headphone text being read, it will read "new product" which is not really useful at all. Consider it using p tags.
    • Avoid using multiple h1 on a page. Use only 1 h1 per page.
    • the "ZXY" headphone section in the homepage, you don't need to nest the button inside a tag. Use the a tag alone. Also, you may have noticed, try hovering on the x-asis of the link, even if I hover not direct to it, it is triggering it. It is an effect from the flexbox parent. Add align-items: flex-start on the section element that is nesting them.
    • Also, some others as well, nesting button in atag. Treat the a itself only.
    • "Audiophile" logo link on footer as well should have been using aria-label
    • social media links in the footer section should have use aria-label to know what social media link it is. Ex: aria-label="facebook" then use a aria-hidden on the svg that is holding the social media icons.
    • The button elements on the product information, the ones that you used to add or subtract the quantity of product that you are using, those should have used aria-label. For example, on the button that minus:
    <button aria-label="remove 1 item"> or other descriptive text for subtracting
    -
    </button>
    

    The parent of this could have used a sr-only text that says what is this section about. Like: <div class="visually-hidden">Make choice on how many you want to buy</div> something like that or other text that makes sense.

    • Addition to that, using a aria-live="polite" to announce how many that the user have added from that item. This will be really beneficial.

    On the mobile state:

    • The hamburger menu should have used button element along with aria-expanded attribute.
    • The paddings also could have been adjusted. The layout are almost on the edges of the screen.
    • The dropdown for the mobile state should have been using display: none when the user is not toggling the dropdown. Try to use keyboard again on this one, it will navigate you to a hidden link. Do not just transition opacity or other things, when you want to make an interactive element to appear. On this one, the links should totally be hidden until the hamburger is triggered.

    I haven't checked your react but hey, react is opinionated. It may be a lot, but structuring html is way more important than creating beautiful websites. This one is really good, but you need to make used of more appropriate elements and maybe more into accessibility to provide to more users.

    But still, you did a really good job on this one. This one is hard to do!!

    Marked as helpful

Join our Discord community

Join thousands of Frontend Mentor community members taking the challenges, sharing resources, helping each other, and chatting about all things front-end!

Join our Discord

Stay up to datewith new challenges, featured solutions, selected articles, and our latest news

Frontend Mentor

  • Unlock Pro
  • Contact us
  • FAQs
  • Become a partner

Explore

  • Learning paths
  • Challenges
  • Solutions
  • Articles

Community

  • Discord
  • Guidelines

For companies

  • Hire developers
  • Train developers
© Frontend Mentor 2019 - 2025
  • Terms
  • Cookie Policy
  • Privacy Policy
  • License

Oops! 😬

You need to be logged in before you can do that.

Log in with GitHub

Oops! 😬

You need to be logged in before you can do that.

Log in with GitHub

How does the accessibility report work?

When a solution is submitted, we use axe-core to run an automated audit of your code.

This picks out common accessibility issues like not using semantic HTML and not having proper heading hierarchies, among others.

This automated audit is fairly surface level, so we encourage to you review the project and code in more detail with accessibility best practices in mind.

How does the CSS report work?

When a solution is submitted, we use stylelint to run an automated check on the CSS code.

We've added some of our own linting rules based on recommended best practices. These rules are prefixed with frontend-mentor/ which you'll see at the top of each issue in the report.

The report will audit all CSS, SCSS and Less files in your repository.

How does the HTML validation report work?

When a solution is submitted, we use html-validate to run an automated check on the HTML code.

The report picks out common HTML issues such as not using headings within section elements and incorrect nesting of elements, among others.

Note that the report can pick up “invalid” attributes, which some frameworks automatically add to the HTML. These attributes are crucial for how the frameworks function, although they’re technically not valid HTML. As such, some projects can show up with many HTML validation errors, which are benign and are a necessary part of the framework.

How does the JavaScript validation report work?

When a solution is submitted, we use eslint to run an automated check on the JavaScript code.

The report picks out common JavaScript issues such as not using semicolons and using var instead of let or const, among others.

The report will audit all JS and JSX files in your repository. We currently do not support Typescript or other frontend frameworks.

Oops! 😬

You need to be logged in before you can do that.

Log in with GitHub