Testimonials Grid Section

@0xabdulkhalid Thank you for your feedback 😁

I have updated my code to reflect your suggestion.

@0xabdulkhalid sorry, that’s not true. Only the alt was causing a failure against WCAG accessibility standards (criterion 1.1.1). And that’s because the alt description didn’t actually describe the image.

Using a figure and figcaption has no bearing on the accessibility of this. If you were going to use figure elements in this challenge it would make more sense to use them for the whole box — the image, persons name and verified text would all go in the figcaption and then the blockquote would also go in the figure (outside of figcaption). But most screen readers and other assistive tech don’t announce figures/figcaption in any particular way.

@grace-snow Hey Grace I've read up on the figure element and MDN wasn't too clear on the use of figure the way I have implemented it on the user image, name and "verification". Could you recommend me a source for learning more about accessibility and perhaps any tools for testing?

Also as a side question, could any of you @grace-snow and @0xabdulkhalid shed some light on why the text on my pages renders differently on the screenshot preview compared to my hosted web page and local environment?

@RegexRiddler like I said, the way you’ve used the figure element in this is not ideal at the moment. It's not causing a "problem" but it's not how the figure and figcaption is meant to be used. The name and verified text are not the caption of the image, they are actually acting as the caption (or heading) for the quote (which should be two paragraphs inside a blockquote element, not a h2 and paragraph).

Having the first sentence of each testimonial as a heading is a definite accessibility problem in my opinion, because it is using a heading for something that isn't heading content. That's part of the testimonial, not the title for it. If anything was acting as headings in this challenge it would be each person's name. (This would be a WCAG failure under 1.3.1 Info and Relationships if I was auditing the site).

The vast majority of accessibility knowledge comes from really considering the appropriate html for the content. That's almost all of it. Web.dev has an accessibility course now, there are sites like inclusive components, theA11yProject, HTML He'll, and many others. Plus there are good videos and blogs by Tetralogical, Nomensa, A11ycast, Craig Abbot, Patrick Lauk and others. The frontend mentor site lists loads of good resources on the resources page. You can also learn a lot just through using browser extensions like accessibility insights, which will give guides on exactly how to test and how to understand each accessibility requirement.

As for the font differences I expect those are to do with different browser rendering engines or something. I really wouldn't worry about it, it's not important.

@grace-snow Thank you for guidance, After reading through your suggestion i came up with an example markup. Does this markup is accessible and structured properly?

<figure>
  <blockquote>
    <p>
      testimonial title 
      ... 
    </p>
    <p>
       testimonial quote 
       ...
     </p>
  </blockquote>
  <figcaption>
    <img src="./assets/images/image-daniel.jpg" alt="Daniel Clifford" />
    <div>
      <p>
        <span class="sr-only">Testimony Author</span>
        Daniel Clifford
      </p>
      <p>Verified Graduate</p>
    </div>
  </figcaption>
</figure>

If anything is wrong, then please let me know so I can make corrections on this one!

"Why the text on my pages renders differently on the screenshot preview compared to my hosted web page and local environment?"

@RegexRiddler actually every browser such as Internet Explorer, Firefox, Chrome, and Safari, has a different layout engine, which alters the position and rendering of various components on a website such as the layout, text, and graphics.

If you really worried and want to fix it then i would recommend you to use Destyle a CSS Reset, It's nothing but a style sheet with list of rules that 'reset' all of the default browser styles.

To look how it works you can head on to the comparison page.

@0xabdulkhalid the dom order is the wrong way around in that example. The figcaption would need to come before the blockquote in this design.

@grace-snow, I ordered in that way so that the quote could be announced first and then the author of quote will be announced.

Is this approach wrong?

@0xabdulkhalid yes because that differs from the visual order. The dom order needs to stay logical and sequential to match the visible display

@grace-snow We can easily handle that using flex layout by reversing the column.

I hope you get it.

@0xabdulkhalid my point isn't about what you can acheive with css. It's about reading order which is a crucial aspect of accessibility. Screen readers will read in DOM order and if this does not match the visual order that causes a barrier to some users. (don't make the mistake of thinking all screen reader users are blind)

This would cause a failure against WCAG success criterion 1.3.2 Meaningful Sequence (level A).

@makihero Thank you! I try to keep and eye for detail :)