I mean FontAwesome has the convention (though not the necessity) of using i elements with no content as icons. You're adding empty italics to your page, which is non-semantic, but an explicitly non-semantic element like a span would be better, because it's not telling anyone anything about how it's displayed.
Completely agree—implementing FA as a webfont and littering <i> elements everywhere withoutthe additional accessible markup goes against the FA documentation and WCAG guidelines. Devs should be following these guides to implement accessible icons, just as they would when adding the necessary aria attributes for accessible navigation menus.
Changing your icon choice across the site (which is purely cosmetic) means either changing the class so that fa-facebook now actually displays a meta logo, leading to confusion in the future because they're not actually interchangeable, or it means search-and-replace across all your HTML/templates.
I feel that the Facebook/Meta argument is a bit of a straw man. If a company changes their logo and it has to be replaced across the site, depending on the implementation, you might have to search-and-replace to make the change in many HTML templates. That doesn’t mean that we should avoid using images. The same goes for icons. Depending on your stack, the search-and-replace effort could be reduced through a more atomic design/development approach. But even that will only get you so far. Maybe the takeaway here is to lock in your design approvals prior to development to reduce opportunities for this sort of refactoring?
I'm also a big fan of not using icons at all, because for one thing, I find them confusing, and for another the author tends to run out of 1-to-1 representations of what they want and ends up using icons that kinda-sorta-might mean what they want if you squint hard enough.
I agree—poorly thought-out icons can be confusing for our end users. This isn’t a failing of FA (not that you said so), but is instead perhaps an indication that our designs have missed the mark. Thoroughly testing our web designs with our target user demographic is a great way to determine which icons resonate the most, or even which icons can be scrapped altogether. “Horses for courses”.
Really appreciate your additional insights.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for the extra context, @moopet.
Completely agree—implementing FA as a webfont and littering
<i>elements everywhere without the additional accessible markup goes against the FA documentation and WCAG guidelines. Devs should be following these guides to implement accessible icons, just as they would when adding the necessaryariaattributes for accessible navigation menus.The great thing about implementing FA using Kits or SVGs with JavaScript is that the accessible HTML is generated for you on the fly!
I feel that the Facebook/Meta argument is a bit of a straw man. If a company changes their logo and it has to be replaced across the site, depending on the implementation, you might have to search-and-replace to make the change in many HTML templates. That doesn’t mean that we should avoid using images. The same goes for icons. Depending on your stack, the search-and-replace effort could be reduced through a more atomic design/development approach. But even that will only get you so far. Maybe the takeaway here is to lock in your design approvals prior to development to reduce opportunities for this sort of refactoring?
I agree—poorly thought-out icons can be confusing for our end users. This isn’t a failing of FA (not that you said so), but is instead perhaps an indication that our designs have missed the mark. Thoroughly testing our web designs with our target user demographic is a great way to determine which icons resonate the most, or even which icons can be scrapped altogether. “Horses for courses”.
Really appreciate your additional insights.