Open ratkins opened 1 year ago
As a counterpoint, I think tags with spaces also have utility for people who don't use screen readers. By virtue of seeing good examples of their use across the network, it seems not unlikely to me that people would come to prefer the cleaner reading experience of tagged phrases that preserve their spacing over HarderToParseCamelCasePhrases.
Again, I think this is a client-side fix: community convention and client editor nudges make #CamelCase hashtags the defecto standard, “good” clients turn them into pills with spaces. The nice thing about this is it degrades gracefully in less sophisticated clients (a la Markdown.)
Yes, people should be nudged/reminded towards CamelCase/snake_case for usability reasons - including but not limited to helping screen-readers.
But, realistically, there are lots of habits built up on other networks, and even smart & caring posters sometimes post like morons-in-a-hurry – so adoption of best-practices will be uneven. (I share @ratkins's hope that rapidly-improving AIs are likely to improve how screen-readers handle even #stubbornlyflatcased tokens in the near future.)
Enabling spaces for those who want/need them, & for communities able to be rigorous, shouldn't be too hard, & offers benefits to those who care or have a special need.
A few possible (non-exclusive) conventions compatible with the sort of free-text typing usual to hashtags could be:
#'
or #"
or #“
or #‘
or #«
or {#
+ any-other-popular-extant-open-quote-characters} to start a hashtag that may include internal whitespace, until the matching close-quote-character/\S#\s/
(non-whitespace, octothorpe, whitespace) is available to specify a non-whitespace-close of the preceding hashtag, also pulling in intervening whitespace. (This would be similar to the hashtag syntax the 'Hashtag' Wikipedia article reports used by some Chinese microblogging sites, using paired octothorpes.) With any or all of these conventions, traditional hashtags (matching /\s(#\S+)\s/
) still work in traditional text – but those who want whitespace can force it.
Though indexers/aggregators may want to collapse alternate tags into a canonical form for discovery/search convenience – such as changing all of #WorldCup
, #world_cup
, & #'World Cup'
into one preferred form, I would strongly suggest against forcing that at any protocol/format/client level, instead always retaining the original author's chosen form in their wire-level/format-level post representations.
Why?
The culture is sure to eventually have cases where the distinction between [space]
& _
& implicit-casing-toggle & whatever-else are important, in some communities-of-practice:
Keep the possibilities open, rather than foreclose them based on limited experience with this style of social network, so far.
Just for completeness, i'm personally a fan of kebob-case for tags, as used in stackexchange.
Whichever convention emerges, adoption of best practice will be important. I think UI/UX to nudge towards conformity could be really helpful. Eg, on instagram when adding tags you can see a list of near-matches, and relatively how popular they are. If those recommended tags are always conforming to best-practice (proper casing, spacing, dashes, etc) that could help.
(This is IMHO, obviously.)
There’s already a mechanism for making hashtags work well for screen readers—#CamelCasing—and people frequently don’t use it. Formatting isn’t the problem, laziness and ignorance are the problem.
And if laziness and ignorance are the problem, browbeating users into formatting their posts in such a way as to maximise the utility of others is obviously the solution! No, wait a minute, that’s wrong too. Mastodon tried that and it doesn’t work either.
Sadly, this is only solvable in the screen reading clients themselves, who’ll need to either detect #wordsmashedtogether (LLMs probably help here) or share lists of common transformations (#penisland → #PenIsland.) Maybe client-side nudges could help too.