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

Single Price Grid Component (Responsive + Working on Accessibility)

accessibility, sass/scss
Kirsten ✨•460
@ofthewildfire
A solution to the Single price grid component challenge
View live sitePreview (opens in new tab)View codeCode (opens in new tab)

Solution retrospective


Single Price Component Grid Solution

Following the road-maps on Discord I have completed this challenge and my main focus was accessibility and the responsive aspect of the challenge. I am still learning accessibility and the topic is pretty dense, however, I did as much as I could on my knowledge, namely:

  • Layout not breaking or looking too weird when user changes font size on their browser/ and or zooms in. I tested this with Chrome, font-size at Very Large and zoomed in to 200% (as per W3.org links I read) and content shifted to maintain its form.

  • Font-size changing with view-port, I used clamp() for this, if there is a better way, please let me know.

  • I changed the colours, they were failing colour contrast checks, so I did my best to pick colours that still looked decent and matched. They now pass those checks.

Things I Need to Fix

  • There is an alignment issue with the "Why Us" box, the heading is at a different spot compared to the other heading in the "Monthly Subscription" box, and it makes it look off, I will keep working on a solution, I suspect its to do with the way I am aligning items in the boxes with flex-box, will continue to try and fix it. Advice appreciated of course though. <3

Unsure about

  • I am very unsure about keyboard accessibility, I went heavy focus on trying to make the fonts size and the containers change, but, the keyboard part, I didn't fully understand it all, and so, I dont think that is implemented, advice there would be appreciated. ^_^ as well as other things in this area too!

Since I am still learning and things may be totally whacky any and all advice is greatly appreciated - thanks, and have a good day.

Code
Select a file

Please log in to post a comment

Log in with GitHub

Community feedback

  • Aman Singh Bhogal•1,010
    @asbhogal
    Posted almost 2 years ago

    Hey Kaycee - this is very good, well done!

    I really like the changes you've made to the palette and considerations to accessibility which often get overlooked at times unfortunately in front-end dev. You've documented your process nicely and your code is well organised. Props to you.

    In terms of keyboard accessibility, the main thing is to ensure the button is focusable when visitors use the tab on the website to navigate through. In order to do this, it's best to remove the transparent value on the outline as this removes the focus on the element so they don't know if it's been selected. Here's a good link which might help illustrate this Link

    With regards to the heading alignment issue, I suspect this is due to the space-around value assigned to both containers, as this calculates gaps both in between the child components and outside. It does this based on the height of the container against the total height of the elements and equally distributes the difference. The spacing that the flex has created on the outside of the right is greater than the left, thereby causing the headings and list section to be 'pushed in' and subsequently lower than the heading on the left, if that makes sense. I've added a link here explaining this in further detail Link In this case, you could try removing the justify-content altogether (which will default it to the space-between from the main>.grid_item declaration, pushing them to the edges of the top and bottom) and adding a specific padding to these two, e.g. padding: 1em 1.5em which will set an equal amount and thereby keep the headings the same height from the top.

    You could also change the background-color to #205857 to flow nicely with the right container and change the colors of the h1 to #205857 and the h2 to #197371. Visually I think this blends better and keeps the color palette to a simple accent of two tones and white.

    I've ran your site through an online accessibility checker for WCAG 2.0 (Level AA) and Level AAA and found no potential or known issues - great news. Here's the link to the checker which you can also use Link

    Hope this helps, and again, really great job. Impressive work!

    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
Frontend Mentor logo

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 1st-party linked stylesheets, and styles within <style> tags.

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.

Oops! 😬

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

Log in with GitHub