From an accessibility context, you can generally add a label to the control in any variety of ways, and show that instead of an icon. Which how I generally use fontawesome.
Not all screen readers will read out title attributes, so you shouldn't be relying on that. You can use ARIA attributes instead, but therse should be used as a last resort.
Also, inlining and SVG can be useful to avoid extra HTTP requests, all of which have a negative impact on the performance of the page, especially if the user is on a slow or metered connection (which is most of the world, including a lot of the USA). Again, I'm not saying always do this, but it can be used as part of an overall strategy.
Probably not necessary to include the whole of Bootstrap for what is effectively a 4-5 lines of CSS to set an item to be visually hidden but available to screen readers as well, that will be another performance hit.
Even if you can't inline the SVG, you can make it a background image and add it in as a data URL in the CSS. For icons this is generally fine, as icons are very simple, so the data URL is actually quite small. It's often more performant to do this than have the CSS reference external image files.
I'm already using Bootstrap for many other things, when it comes to this. Plus I already compile the parts I need with SASS, and minify the whole thing with Webpack. So it's actually not that much of an issue.
Font-awesome is much smarter than it used to be. The npm/webpack version allows you to pick and choose which icons you need, so you don't have to ship the whole icon pack.
The size of the request isn't the only issue. The whole HTTP request has a connection negotiation step before content is transferred which also takes time. On a slow connection (such as dialup or a lot of lower end mobile phone plans) or on one with high latency (for example, satellite connection where upstream requests are done via dialup). The number of extra HTTP requests is a big drain on performance, and ultimately that affects the accessibility of the content too.
Try testing your site/webapp out on a browser with a throttled connection and see how well it performs. You'll see that it's those extra requests which can really have the biggest impact. And when content isn't loaded by a specific time, you can run into all kinds of issues with document reflow, hidden or missing content, and in the worse case, errors caused by code which expects the content to already be there.
I'm not trying to crap all over things like Bootstrap or Font-awesome, but I'm saying it helps to be aware of the issues they can cause and not just the issues they solve.
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.
From an accessibility context, you can generally add a label to the control in any variety of ways, and show that instead of an icon. Which how I generally use fontawesome.
<button title="GitHub"><i class="fab fa-github"></i></button>
This gives the button a tooltip, which screen readers can read instead.
<button><i class="fab fa-github"></i><span class="visually-hidden">GitHub</span></button>
Or a "hidden" span using Bootstrap 5's utility classes.
Not all screen readers will read out
titleattributes, so you shouldn't be relying on that. You can use ARIA attributes instead, but therse should be used as a last resort.Also, inlining and SVG can be useful to avoid extra HTTP requests, all of which have a negative impact on the performance of the page, especially if the user is on a slow or metered connection (which is most of the world, including a lot of the USA). Again, I'm not saying always do this, but it can be used as part of an overall strategy.
Probably not necessary to include the whole of Bootstrap for what is effectively a 4-5 lines of CSS to set an item to be visually hidden but available to screen readers as well, that will be another performance hit.
Even if you can't inline the SVG, you can make it a background image and add it in as a data URL in the CSS. For icons this is generally fine, as icons are very simple, so the data URL is actually quite small. It's often more performant to do this than have the CSS reference external image files.
Good point on the title attribute.
I'm already using Bootstrap for many other things, when it comes to this. Plus I already compile the parts I need with SASS, and minify the whole thing with Webpack. So it's actually not that much of an issue.
Font-awesome is much smarter than it used to be. The npm/webpack version allows you to pick and choose which icons you need, so you don't have to ship the whole icon pack.
The size of the request isn't the only issue. The whole HTTP request has a connection negotiation step before content is transferred which also takes time. On a slow connection (such as dialup or a lot of lower end mobile phone plans) or on one with high latency (for example, satellite connection where upstream requests are done via dialup). The number of extra HTTP requests is a big drain on performance, and ultimately that affects the accessibility of the content too.
Try testing your site/webapp out on a browser with a throttled connection and see how well it performs. You'll see that it's those extra requests which can really have the biggest impact. And when content isn't loaded by a specific time, you can run into all kinds of issues with document reflow, hidden or missing content, and in the worse case, errors caused by code which expects the content to already be there.
I'm not trying to crap all over things like Bootstrap or Font-awesome, but I'm saying it helps to be aware of the issues they can cause and not just the issues they solve.