As someone who has developed several #ActivityPub software implementations (Fedify, Hollo, BotKit, and Hackers' Pub), I believe one of the most frustrating features to implement in the #fediverse is #custom_emoji.
The challenges are numerous:
First, there's no standardization. ActivityPub specifications don't define how custom emoji should work, leading to inconsistent implementations across different servers like Mastodon and Misskey.
Rendering is particularly problematic. Emojis must display properly across different contexts (in text, as reactions, in emoji pickers) while maintaining quality at various sizes. Animated emojis add another layer of complexity.
Perhaps most concerning is the poor #accessibility. Most implementations simply use the emoji code (like :party_blob:) as the alt text, which provides no meaningful information to screen reader users (in particular, non-English speakers) about what the emoji actually depicts or means.
What really dampens my motivation to implement this feature is knowing I'm investing significant effort into something that ultimately creates accessibility barriers. It's disheartening to work hard on a feature that excludes part of the community.
@hongminhee I plan to write a FEP documenting existing implementations (it is needed to finalize my emoji reactions FEP).
>Most implementations simply use the emoji code (like :party_blob:) as the alt text, which provides no meaningful information to screen reader users
Do you know implementations that provide alt text for custom emojis?
@silverpill@mitra.social I personally didn't find integrating custom emoji to be difficult at all.
However NodeBB did already have custom emoji support (so it was fairly straightforward to add the outbound federation support), and as for inbound, the short code is defined in the payload and a simple regex replace handles it ok.
Sure, some emoji might look weird if they have different aspect ratios, but that's something outside the scope of what I'd want. All remote emoji are reduced down to a small square (or technically I think it's maybe max width and height of 1rem or similar), inline with the text and that honestly works with like 99% of the emoji I see.
That said an FEP would be nice so I'd be able to verify that my implementation checks all the boxes.
Started writing it
https://codeberg.org/silverpill/feps/src/branch/main/9098/fep-9098.md
Listed requirements for the Emoji object.
I should probably describe the microsynax there as well, and how custom emojis are rendered.
@silverpill @julian @hongminhee you have listed "Image is a square" but is definitely not true for Misskey. And Mastodon renders Misskeys long emojos just fine.
Actually mastodon does fine with long emojos now too 
Requirements in that section are meant for those who want maximum compatibility. For example, JPEGs and images larger than 256 KB are supported by Pleroma and others, but Mastodon doesn't allow them.
Non-square emojis are a bit more complicated. They are not rejected by most servers, but might not be displayed properly by clients.
I just visited your instance and made a screenshot of how emoji is rendered by web UI (attached). The emoji is present, but I can't tell what is depicted there. Some clients enlarge custom emojis on hover, but not Mastodon, so I have to open the image in a new browser tab, or zoom in the page. This is no ideal, hence the recommendation in the FEP.
@silverpill @julian @hongminhee ugh mastodon android squishes this. These are both Mastodon bugs as far as I am concerned. I think as long as you specify what you are making maximum compatibility with that seems OK but long emojos are INCREDIBLY popular on all the misskey and misskey adjacent fediverse areas. So I would argue that usage should be spelled out in the FEP as well.
@liaizon @julian @hongminhee I added a text explaining this additional requirement: https://codeberg.org/silverpill/feps/src/branch/main/9098/fep-9098.md#additional-requirements
Best practices for rendering custom emojis will go into different section (WIP).
I finally wrote the section about rendering and submitted the proposal to the FEP repository: https://codeberg.org/fediverse/fep/src/branch/main/fep/9098/fep-9098.md
@silverpill @julian @hongminhee the thing that I tried to point out before feels like you didnt really take into consideration yet. You state "This document is based on implementations of custom emojis in Pleroma, Mastodon, Misskey and Fedibird" but Misskeys implementation has always supported long emojo and infact that type of emojo seems to be one of the most popular types in the Japanese speaking fediverse. Personally I feel this should be mentioned in the FEP
@silverpill @julian @hongminhee I am really glad to see you write this up regarless, don't want to come across as negative.
@liaizon@social.wake.st are the long emoji horizontal or vertical?
The former is easier to support (setting just a max height), but the latter has concerns re: line height.
@julian @silverpill I haven't seen vertical ones, just horizontal. But that would be interesting to take into consideration as there are languages that *are* written vertically so it should at least be thought about.
@liaizon @julian @hongminhee I forgot about this. Adding a new requirement to the "Rendering" section:
The aspect ratio of the image SHOULD be preserved.
@silverpill @julian @hongminhee thank you that helps a lot!