Create a component that allow adding aria-labels

[ckp267]

From Josh
I'd like to share this with you and let you choose the best option. Kyra requested yesterday to check the score and rank Google Lighthouse was giving for a page; found out that accessibility wasn't reaching all the score we'd like, and one of the points is related with the aria-labels. Been reading about it and found a really interesting link => https://www.w3.org/WAI/ARIA/apg
I understand you aren't going to read right now, so giving a bit of resume: ARIA or Accessible Rich Internet Application is used to generate accessible experience in the web. The first suggestion is No ARIA is better than Bad ARIA., so before we start using it we should be cautious with it. Then they have this other page which I think is incredible and will make our job easier: https://www.w3.org/WAI/ARIA/apg/patterns/. They share how to implement this aria-labels and what they need. So, here's the situation I'd like you to let me know what you prefer:

1. I can do some fast fix for the links to score correctly on the Google Lighthouse, which will be faster but will have some risks ( No ARIA is better than Bad ARIA.) and will affect just links, which means we can test another page on Google Lighthouse and say error of accessibility in other blocks.
   2. I can take a bit longer and create a component that allow adding aria-labels to creators and ensure a whole control of the accessibility to have an easier way to score 100.

What do you think is better with the current context? Don't hesitate on asking what you need 🙏🙂

Kyra Pieterse, Yesterday 11:28
option 2 sounds better but lets see what C says

Joshua Juan Caparrós, Yesterday 11:28
cool, I don't think second option will take me longer than 2 or 3 days and will ensure a good accesibility feature 🙂

Christiaan Pieterse (yc), 8 min

Thank you for the info @joshua Juan Caparrós yeah, option 2 seems like a better way to go long-term. The important thing is that it's not a quick fix - it should be included in all planning and thinking. It's easier to add it in from the beginning than to try to fix it later. If we add it as a component then we can help make it easier for people to do it themselves. That makes sense.
More ideas here.
https://theplusblocks.com/docs/aria-labels-in-wordpress/
https://fullsiteediting.com/lessons/accessibility-in-full-site-editing-themes/

Joshua Juan Caparrós, 7 min

thanks for the answer

[ckp267]

Hi Christiaan!

This is wonderful!

And, yes, that h6 is an issue, especially since people who use screen readers often scan the page and gauge the outline of the content by the headings.

The button issue isn’t with the #. It’s that the html tag is being used for a link instead of in that particular pattern.

I agree, a skilled developer with A11y knowledge will be able to easily create the proper headings and change the buttons, etc. However, I know that there will be masses of people reaching for these blocks as DIYers. And from what I’ve seen firsthand, they will probably just swap out the content.

One of my goals is to inspire folks to work out content strategy and creating content before building a site and to educate them on how to add content without making the site InAccessible. At the end of the day, they are responsible for their own content being Accessible.

Anyway, thanks for responding and clarifying.

Here’s a more comprehensive tool for A11y scans:

https://accessibilityinsights.io/downloads/

I usually do a quick FastPass, but you can do a complete audit because there are many under the hood Accessibility issues that aren’t caught with simple scanning tools.