You shouldn't write an article and propose people to use files and resources instead of standard device emojis. Or at least you should write down the drawbacks and not present everything like bells and whistles.
People with old browsers or devices should upgrade their browsers to access new features. You remind me some old folks that even today insist to support Internet Explorer and spend countless hours to make their HTML/CSS work on obsolete browsers just for some people with old browsers to be able to see their pages.
You throw away standards about how emojis should appear on each device and use external libraries to live traverse the HTML code of the document? That's a terrible thing to do. If I have an iPhone, I want all emojis to look like how apple wants them to look like in an iPhone. If I open the sites using Firefox, I want all emojis to look like how Mozilla emojis are look like. If you don't want to use the default emojis, then you want to use device independent SVGs to present graphic emojis and not standard emojis. In your article you're just using a horrible automation technique to parse the whole document.
Also keep in mind that Twitter emoji usability sucks. Just try to use them in your tweets and you'll see for yourself what I am talking about. You can't even select them because they are not using standards.
I actually disagree on your point that emojis should look the way the device the site is viewed on, intends them to look (when it comes to native apps I do agree though)
Your site has a design language, and your emojis should follow that design language, it shouldn't be up to the device to determine the design language itself.
Every site has its style and developers are freely to use SVG and graphics as they want and they should be aware of the consequences and the side-effects of their actions. Emojis are not a matter of how a font looks or how much padding/margin there is between some blocks, but it's tied to the devices. It's like respecting users preference for dark/light theme using CSS media queries like @media (prefers-color-scheme: light) or @media (prefers-color-scheme: dark). Users are used to these emojis styles and especially for users with sigh disabilities these preference should be considered and respected.
Why keep system/device emojis for native apps? You're saying that native applications cannot have their own unique style? I've created quite a few native apps all with different styles.
I think displaying a square on browser is bad for accessibility especially if you use the very new emojis and they aren't supported by latest Android and Windows. Different platforms display different styles might also convey different meanings. The way Twitter implements alt text makes them not copyable. You can look at my website which I make them copyable.
The square in the browser will happen in old browsers and even for newly added emojis, there will be updates that will be added to systems eventually. In our days, it's user's responsibility to have their browsers updated.
Also, different styles do not change the meaning, the meaning is the same, it's just the style that changes. Different platforms display different styles means that the users are used to these styles and we should not change that for them just because we want the emojis to look like we want them to look (or the style we think it's standard style). Use SVGs directly instead and not the standards; or use standard emojis and leave it to the system or the users’ preferences (which might be a different font more friendly to people with sight issues for example).
Having an automated document parser on each page load to change emojis with SVG assets is a terrible thing to do in many aspects. This should be done after saving an article and then the engine should render it (a markdown text to HTML maybe) and only then parse and replace the emojis.
I would argue for the alt usage. Alternative image text should not be used to have the actual emoji inside it but a description instead like Twitter. If you do it only for the selection thing it could be considered "OK".
Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
Agree with everything apart from the "You remind me some old folks that even today insist to support Internet Explorer" - we support IE back to IE9 due to the fact that disabled users who rely on screen readers often can't afford to update JAWS to the later versions and so are stuck on older browsers, some are even still using IE6-8 according to the most recent WebAim survey, but even I draw the line at supporting IE6,7 or 8!. You should at least support IE11 due to this fact (as 1 in 10 screen reader users still use it), even if it is a pain!
If you want to invest time and support IE8-10 then you or your team mates can do it, but Microsoft has officially ended support for IE8, IE9 and IE10 so NO; even users with dissabilities should update their systems and browsers to support latest standards.
I can agree just for supporting IE11 for now (maybe at least until next year) but not older version; is a much waste of resources and dev hours plus count the fact that these browsers need extra effort and time for proper accessibility features to work in the first place.
Is this really true? I am genuinely interested, as I've not run into this particular argument before. Personally I tend to use NVDA most of the time (for testing purposes) as surveys tend to put it as the most used (webaim.org/projects/screenreadersu... ) and it works on every browser across Windows. It being free for use is probably also what's contributed to its popularity.
Also, looking at the JAWS website, it doesn't appear to charge for upgrades.
I do believe the argument for supporting very old browsers/systems has to strike a balance. First, we must ask if that emoji is vitally important to the content? If it's not, why is it there at all, and can it be removed?
If we truly need it, then how much of our audience is likely to be affected by it not being there? Mac and Linux have support for emoji out of the box, and Windows has it with built-in updates (albeit non-essential) since Windows 7 (which is about 11 years old now). We could use this Twitter library, but then the cost is going to affect all of our users by increasing network traffic and decreasing performance. When you consider that even countries like USA have some areas with really poor Internet connections, that impact actually becomes much more noticeable (businessinsider.com/map-fastest-an... ).
Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
We could make the argument similar to @christoslitras
that "users should just use the latest tech" but there are loads of reasons why they don't (for example):-
cost (see below),
lack of technical expertise to know how to update - this one is the big one, just because we know our way around a computer does not mean that kids who drop out of school at 15 to pursue a trade and are technophobes know how to do things we assume to be simple.
OS restrictions (32 bit machine vs 64 bit machine is one that is starting to cause people issues as 32 bit support is reducing).
With regards to JAWS cost it depends entirely on what country you are in as they use a distributor model.
In the UK to upgrade from 2017 JAWS or earlier to 2020 JAWS would cost you £375 as a home user. If you need it for work expect to pay double for a commercial license (although with a bit of fiddling and patience you can get that paid for by the government).
This is why NVDA is so popular (as you mentioned, it's FREE!), and it is a great piece of kit, but JAWS is still better with some programmes etc.
It is also familiarity, if you have used JAWS for 10 years then you know the shortcuts, the speech patterns, idiosyncrasies etc. Forcing someone to use NVDA and a certain browser is like me asking you to start writing with your left hand if you are right handed (or vice versa) in order to use my service.
You could do it but it would take a lot of time and effort so I am sure you would just stick with your right hand and just go to someone else who will let you write with the hand you prefer. (Not my best analogy but hopefully you get the point!)
I agree on the balance, it frustrates me that I have to still support IE9 - but I blame Microsoft for the issues I have with IE9 not my end users.
We choose IE9+ (rather than IE8+ etc) as our support level as that supports modern HTML and most CSS and compiling your JavaScript to work in IE9 isn't difficult.
When I say support IE9 I am not talking about pixel perfection, we can live with layout quirks and certain features not working perfectly as long as the site is still usable and fully accessible.
Also we support IE9+ for E-commerce sites, for SAAS we support IE11+ due to not wanting to have to create our own frameworks. We do however ensure that older browsers have alternative ways of performing critical actions.
That is just my 2 cents and why we support that far back, everyone is different, I just think it makes commercial sense to support things people still use as when they can't use your website as you don't support them they will hopefully come to mine 😊.
If you have your own site statistics and you can see there is a quite percentage of IE users using your site/services, then you and your team can decide if it's worth the time and effort to support such obsolete and abandoned browsers.
According to gs.statcounter.com, IE (all versions) global share is 1.68% and it keeps falling. Also many companies like Google, Facebook and even Microsoft, have stopped supporting IE for all new releasde of some very popular frameworks like React, Angular, Blazor/.NET SPA and even VueJS.
It does not worth it, not only for the time you or your team spends on this, but also having your site/app downloading and loading several JS/CSS files for pollyfilling missing features for obsolete browsers is bad for the projects ecosystem, for the majority of end users, for devices and even for the environment.
Agreed. The place I work at currently does have to support some older browsers, but that's typically more for core functionality rather than aestheitcal items. If things look a bit different, that's acceptable.
I suppose one could attempt to detect support of the emoji being used in a web page and use a method like this to fill them in, but again, is it worth it?
Interesting point of view, and you're actually right. I didn't talk about the drawbacks of using this library. Will definitely edit my article in the following days. 😉
You shouldn't write an article and propose people to use files and resources instead of standard device emojis. Or at least you should write down the drawbacks and not present everything like bells and whistles.
People with old browsers or devices should upgrade their browsers to access new features. You remind me some old folks that even today insist to support Internet Explorer and spend countless hours to make their HTML/CSS work on obsolete browsers just for some people with old browsers to be able to see their pages.
You throw away standards about how emojis should appear on each device and use external libraries to live traverse the HTML code of the document? That's a terrible thing to do. If I have an iPhone, I want all emojis to look like how apple wants them to look like in an iPhone. If I open the sites using Firefox, I want all emojis to look like how Mozilla emojis are look like. If you don't want to use the default emojis, then you want to use device independent SVGs to present graphic emojis and not standard emojis. In your article you're just using a horrible automation technique to parse the whole document.
Also keep in mind that Twitter emoji usability sucks. Just try to use them in your tweets and you'll see for yourself what I am talking about. You can't even select them because they are not using standards.
I actually disagree on your point that emojis should look the way the device the site is viewed on, intends them to look (when it comes to native apps I do agree though)
Your site has a design language, and your emojis should follow that design language, it shouldn't be up to the device to determine the design language itself.
Every site has its style and developers are freely to use SVG and graphics as they want and they should be aware of the consequences and the side-effects of their actions. Emojis are not a matter of how a font looks or how much padding/margin there is between some blocks, but it's tied to the devices. It's like respecting users preference for dark/light theme using CSS media queries like
@media (prefers-color-scheme: light)or@media (prefers-color-scheme: dark). Users are used to these emojis styles and especially for users with sigh disabilities these preference should be considered and respected.Why keep system/device emojis for native apps? You're saying that native applications cannot have their own unique style? I've created quite a few native apps all with different styles.
Personally I like when native apps follow the OS's design language, makes the whole seem more unified.
I think displaying a square on browser is bad for accessibility especially if you use the very new emojis and they aren't supported by latest Android and Windows. Different platforms display different styles might also convey different meanings. The way Twitter implements
alttext makes them not copyable. You can look at my website which I make them copyable.The square in the browser will happen in old browsers and even for newly added emojis, there will be updates that will be added to systems eventually. In our days, it's user's responsibility to have their browsers updated.
Also, different styles do not change the meaning, the meaning is the same, it's just the style that changes. Different platforms display different styles means that the users are used to these styles and we should not change that for them just because we want the emojis to look like we want them to look (or the style we think it's standard style). Use SVGs directly instead and not the standards; or use standard emojis and leave it to the system or the users’ preferences (which might be a different font more friendly to people with sight issues for example).
Having an automated document parser on each page load to change emojis with SVG assets is a terrible thing to do in many aspects. This should be done after saving an article and then the engine should render it (a markdown text to HTML maybe) and only then parse and replace the emojis.
I would argue for the
altusage. Alternative image text should not be used to have the actual emoji inside it but a description instead like Twitter. If you do it only for the selection thing it could be considered "OK".Agree with everything apart from the "You remind me some old folks that even today insist to support Internet Explorer" - we support IE back to IE9 due to the fact that disabled users who rely on screen readers often can't afford to update JAWS to the later versions and so are stuck on older browsers, some are even still using IE6-8 according to the most recent WebAim survey, but even I draw the line at supporting IE6,7 or 8!. You should at least support IE11 due to this fact (as 1 in 10 screen reader users still use it), even if it is a pain!
If you want to invest time and support IE8-10 then you or your team mates can do it, but Microsoft has officially ended support for IE8, IE9 and IE10 so NO; even users with dissabilities should update their systems and browsers to support latest standards.
I can agree just for supporting IE11 for now (maybe at least until next year) but not older version; is a much waste of resources and dev hours plus count the fact that these browsers need extra effort and time for proper accessibility features to work in the first place.
Is this really true? I am genuinely interested, as I've not run into this particular argument before. Personally I tend to use NVDA most of the time (for testing purposes) as surveys tend to put it as the most used (webaim.org/projects/screenreadersu... ) and it works on every browser across Windows. It being free for use is probably also what's contributed to its popularity.
Also, looking at the JAWS website, it doesn't appear to charge for upgrades.
I do believe the argument for supporting very old browsers/systems has to strike a balance. First, we must ask if that emoji is vitally important to the content? If it's not, why is it there at all, and can it be removed?
If we truly need it, then how much of our audience is likely to be affected by it not being there? Mac and Linux have support for emoji out of the box, and Windows has it with built-in updates (albeit non-essential) since Windows 7 (which is about 11 years old now). We could use this Twitter library, but then the cost is going to affect all of our users by increasing network traffic and decreasing performance. When you consider that even countries like USA have some areas with really poor Internet connections, that impact actually becomes much more noticeable (businessinsider.com/map-fastest-an... ).
Thanks for your comment!
@ashleyjsheridan Yes it is true.
We could make the argument similar to @christoslitras that "users should just use the latest tech" but there are loads of reasons why they don't (for example):-
With regards to JAWS cost it depends entirely on what country you are in as they use a distributor model.
In the UK to upgrade from 2017 JAWS or earlier to 2020 JAWS would cost you £375 as a home user. If you need it for work expect to pay double for a commercial license (although with a bit of fiddling and patience you can get that paid for by the government).
This is why NVDA is so popular (as you mentioned, it's FREE!), and it is a great piece of kit, but JAWS is still better with some programmes etc.
It is also familiarity, if you have used JAWS for 10 years then you know the shortcuts, the speech patterns, idiosyncrasies etc. Forcing someone to use NVDA and a certain browser is like me asking you to start writing with your left hand if you are right handed (or vice versa) in order to use my service.
You could do it but it would take a lot of time and effort so I am sure you would just stick with your right hand and just go to someone else who will let you write with the hand you prefer. (Not my best analogy but hopefully you get the point!)
I agree on the balance, it frustrates me that I have to still support IE9 - but I blame Microsoft for the issues I have with IE9 not my end users.
We choose IE9+ (rather than IE8+ etc) as our support level as that supports modern HTML and most CSS and compiling your JavaScript to work in IE9 isn't difficult.
When I say support IE9 I am not talking about pixel perfection, we can live with layout quirks and certain features not working perfectly as long as the site is still usable and fully accessible.
Also we support IE9+ for E-commerce sites, for SAAS we support IE11+ due to not wanting to have to create our own frameworks. We do however ensure that older browsers have alternative ways of performing critical actions.
That is just my 2 cents and why we support that far back, everyone is different, I just think it makes commercial sense to support things people still use as when they can't use your website as you don't support them they will hopefully come to mine 😊.
If you have your own site statistics and you can see there is a quite percentage of IE users using your site/services, then you and your team can decide if it's worth the time and effort to support such obsolete and abandoned browsers.
According to gs.statcounter.com, IE (all versions) global share is 1.68% and it keeps falling. Also many companies like Google, Facebook and even Microsoft, have stopped supporting IE for all new releasde of some very popular frameworks like React, Angular, Blazor/.NET SPA and even VueJS.
It does not worth it, not only for the time you or your team spends on this, but also having your site/app downloading and loading several JS/CSS files for pollyfilling missing features for obsolete browsers is bad for the projects ecosystem, for the majority of end users, for devices and even for the environment.
Agreed. The place I work at currently does have to support some older browsers, but that's typically more for core functionality rather than aestheitcal items. If things look a bit different, that's acceptable.
I suppose one could attempt to detect support of the emoji being used in a web page and use a method like this to fill them in, but again, is it worth it?
Interesting point of view, and you're actually right. I didn't talk about the drawbacks of using this library. Will definitely edit my article in the following days. 😉
This. So much overhead to add when it's supported across every platform's last 4-6 years' worth of versions: caniemoji.com 😕
Thanks for this tool.