Suggested Fixes from 5t3ph

[5t3ph]

This PR shows suggested fixes and includes links to WCAG and articles from accessibility experts to help understand "why" a change was necessary.

Comments included in the fix PR use the following key:

• ✅ Found with tools
• 🚩 False flag from tools given site context
• 🚨 Requires manual testing/review
• 🎨 Visual adjustment, not strictly a11y related

Did you find something additional, or disagree with a fix? Submit it as an issue >

[5t3ph]

You can review the live preview of the changes in this PR:
https://deploy-preview-1--a11y-fails.netlify.app/

[Lewiscowles1986]

There are still some contrast errors coming up in WAVE by WebAIM and The Contrast Triangle (double-checked to see if these were false positives)

[5t3ph]

Hi @Lewiscowles1986 - yes, there are 5 contrast errors noted by tools. For the buttons, the tools don't seem to be picking up that the font is bold, and 16px + bold which qualifies it as large text and acceptable for 3:1 contrast. For the header span, it's also falsely attaching only to the color: transparent and not seeing the -webkit-text-stroke or the fact the animation fills it in to a solid color, so that is a false flag as well. Thanks, it does help to have a clarifying comment within this PR!

[alvaromontoro]

Those may not be false positives:

• The definition of large text is "at least 18 point or 14 point bold", 14 points is equivalent to 18.66px. So the 16px bold buttons would not be considered large text.
• -webkit-text-stroke is not supported by some browsers –notoriously IE11, which is still a relatively high-utilized browser among screen reader users (according to WebAIM research, although going down considerably from previous years)
• Having animations to fill colors is not a reliable option. Users may have their own stylesheet with a prefers-reduced-motion media query) preventing the animation, and then the text wouldn't be accessible.

[5t3ph]

Those may not be false positives:

• The definition of large text is "at least 18 point or 14 point bold", 14 points is equivalent to 18.66px. So the 16px bold buttons would not be considered large text.
• -webkit-text-stroke is not supported by some browsers –notoriously IE11, which is still a relatively high-utilized browser among screen reader users (according to WebAIM research, although going down considerably from previous years)
• Having animations to fill colors is not a reliable option. Users may have their own stylesheet with a prefers-reduced-motion media query) preventing the animation, and then the text wouldn't be accessible.

You are correct on the text size - I've updated that to bump up the font-size. I recently realized I somehow had missed the breakdown that lists the 18.66px you noted, and I think it's often incorrectly quoted as 16px vs. 16pts 😞

My prior comment may be confusing but when tested with prefers-reduced-motion: reduce the stroked text becomes filled due to the media query that checks for that causing the animation to run instantly so it lands on the last frame 👍 The original stroking of the text is also set up to be applied with @supports so IE will ignore it and the text will just always have a solid fill. I think stroked text can be acceptable if the case you noted of a user stylesheet preventing animation exists but I am having trouble confirming that. It would be less ok if it was the entire body text of course, but in this case it's kind of serving as a logo as well. If you check again and still see an issue, let me know! I'm here to learn and improve too 💫