Welcome to Week 1, Day 6 of my Weekly UI challenge! As I stated in the announcement post, week 1 will focus on an ecommerce listing UI component; each day throughout this following week, I will pick one or two (usually related) subelements of the design to implement. For day six, our goal is to…
Score 100% in an a11y audit
Accessibility– or a11y, pronounced "ally"– is a very important concept in modern web development. No matter whether you are building web applications or simple static landing pages, making a web page accessible should be on the forefront of every developer and designer's mind. For many, this is an afterthought, but a11y is quickly becoming a metric in SEO ranking and vital to the legal integrity of your web page/app; it is also a good idea and strategy to make it easier for users to actually use your site/app/widget.
A11y techniques span quite a few domains and disciplines, from HTML attributes and CSS states, to colors used in the design (you may notice that most colors I used in my design have WCAG contrast ratings of at least AA for their relevant domains) and text that no one will interact with unless they use a screen reader. In order to test for a web page's accessibility, there are several tools floating around the web. One such tool is a11y.css.
My design/features have not changed since Day 5, so for Day 6, my first image is what my component looks like with a11y.css enabled:
The above screenshot shows what an erroneous web page looks like when using the a11y.css bookmarklet. a11y.css is an awesome tool that uses CSS targeting to find a11y errors, warnings, and advisable tips in your code, and show you the messages inline. You can even configure the tool to target only certain levels of warnings too. When I start working on improving accessibility, this tool is the first one I use.
Another tool I use is the Google Lighthouse accessibility audit, here is what it looks like after successfully adjusting any changes the tool suggests:
This tool will check all the types of things a11y.css does, and then some. It allows a little more control over debugging, as it will list offending elements, and scolling over that list will highlight those elements in the DOM, much like normal devtools do. I also find Lighthouse a lot easier to figure out what to fix, since it will also link to explainer pages for each error.
I've linked several tools and resources for a11y techniques and testing in the footnotes of this post, and I hope you use them and explore ways to help make the web usable for everyone!
You can check out my coded implementation on my Github pages site for this project.
Now it's your turn
I used React.js and Storybook to develop my implementation, but you can use whatever technology stack you would like! (hint: if you use Vue.js or Angular.js, you can still use Storybook for those libraries)
You don't even have to use a view library if you don't want to; HTML and CSS-only (and non-view JavaScript library) components are more than possible, especially for this step.
Also, please add your repos and/or images of your designs in the comments for inspiration! I would love to see what designs you all create.
Happy coding! 🎉
Week 1 Calendar
- Design component ✅
- Display product name, price, and image ✅
- Add to cart button, favorite button ✅
- Sale price display, sold out states ✅
- Color variant thumbnail buttons ✅
- 100% a11y score 🎯
- Tweaks, refactors, fixes
Top comments (1)
Yay! Just had to change the font color on the button!
