For reference, the arrow is currently generated by $wgLang->getArrow(), which means that different UI languages might do different things (right now it's just a RTL check). I would assume that a symbol like § would also need to be localizable.

should it be "§" instead of an arrow?

This reminds me of T18691. Long story short: "§" does not mean "paragraph" in the broadest sense in all cultures. In some cultures, it only refers to paragraphs relating to laws.

In T210822#4788433, @Nirmos wrote:

should it be "§" instead of an arrow?

This reminds me of T18691. Long story short: "§" does not mean "paragraph" in the broadest sense in all cultures. In some cultures, it only refers to paragraphs relating to laws.

...And I think the fact that MZMcBride calls this "Section symbol" in the description, while I interpreted it as "paragraph", proves this point nicely. =)

There is also https://en.wikipedia.org/wiki/Section_sign#Use which says "While § is usually spoken as section, European countries may read it as paragraph.".

It could also help to restructure the order of items. Currently we have (watchlist):

 diff    _ hist .. tag    _ page _ time   .. size   .. author _ talk   _ contribs _ ->section _ summary
(change _ page .. change _ page _ change .. change .. change _ author _ author   _ page      _ change )

I would restructure it like this:

 page _ section _ hist .. tag    _ summary _ size   _ time   _ diff    .. author _ talk   _ contribs
(page _ page    _ page .. change _ change  _ change _ change _ change .. change _ author _ author  )

If the diff link is not the first item in the list, or in different places depending on whether a section was edited or not, that would be the end of counter-vandalism.

In T210822#4789383, @Nirmos wrote:

If the diff link is not the first item in the list, or in different places depending on whether a section was edited or not, that would be the end of counter-vandalism.

I see

In T210822#4788433, @Nirmos wrote:

should it be "§" instead of an arrow?

This reminds me of T18691. Long story short: "§" does not mean "paragraph" in the broadest sense in all cultures. In some cultures, it only refers to paragraphs relating to laws.

Sure, though as @Legoktm points out, this can pretty easily be treated as a localizable character. There are languages where the current marker choice of an arrow doesn't really make sense, such as English.

Do you have any thoughts about the current choice of using an arrow or about not using a marker at all?

I was just about to post to [[:en:VPT]] wondering about this. At least on en.wp, the § symbol is already used in several places to represent a section (as delimited by a header) of an article. We already do that in the semi-niche https://en.wikipedia.org/wiki/Template:Section_link but also the widely used https://en.wikipedia.org/wiki/Template:Main for example. ~~~~

In T210822#4789323, @Dvorapa wrote:

It could also help to restructure the order of items. Currently we have (watchlist):

 diff    _ hist .. tag    _ page _ time   .. size   .. author _ talk   _ contribs _ ->section _ summary
(change _ page .. change _ page _ change .. change .. change _ author _ author   _ page      _ change )

I would restructure it like this:

 page _ section _ hist .. tag    _ summary _ size   _ time   _ diff    .. author _ talk   _ contribs
(page _ page    _ page .. change _ change  _ change _ change _ change .. change _ author _ author  )

In T210822#4789383, @Nirmos wrote:

If the diff link is not the first item in the list, or in different places depending on whether a section was edited or not, that would be the end of counter-vandalism.

I agree with Nirmos. This would indeed have a significant impact on those who have to regularly scan through those history pages to reconstruct an editor's actions.

The diff, date, time, etc. are the same length and line up consistently in the article history and contributions, and should stay at the beginning of the line. If they were re-ordered with variable-length data like page and section name first, the layout would become significantly more chaotic, and less easily parsed by the reader. The variable-length data should always appear at the end of the line to maximize legibility.

In T210822#4791734, @AfroThundr3007730 wrote:

In T210822#4789323, @Dvorapa wrote:

It could also help to restructure the order of items. Currently we have (watchlist):

 diff    _ hist .. tag    _ page _ time   .. size   .. author _ talk   _ contribs _ ->section _ summary
(change _ page .. change _ page _ change .. change .. change _ author _ author   _ page      _ change )

I would restructure it like this:

 page _ section _ hist .. tag    _ summary _ size   _ time   _ diff    .. author _ talk   _ contribs
(page _ page    _ page .. change _ change  _ change _ change _ change .. change _ author _ author  )

In T210822#4789383, @Nirmos wrote:

If the diff link is not the first item in the list, or in different places depending on whether a section was edited or not, that would be the end of counter-vandalism.

I agree with Nirmos. This would indeed have a significant impact on those who have to regularly scan through those history pages to reconstruct an editor's actions.

The diff, date, time, etc. are the same length and line up consistently in the article history and contributions, and should stay at the beginning of the line. If they were re-ordered with variable-length data like page and section name first, the layout would become significantly more chaotic, and less easily parsed by the reader. The variable-length data should always appear at the end of the line to maximize legibility.

Re-ordering literally *everything* is offtopic to this task. Feel free to file a new task to discuss.

Back to the originally opening question.

• With the most recent change, the arrow is not a blue link any longer, nor is the TOC headline in blue as it has been for a few weeks.

Now it is hard for newbies and not frequently visiting users to learn that this grey thing is a clickable link.

• The only clue they get now is the arrow.
• The arrow (or similar simply accessible sign) is necessary now to give at least a hint to this type of link markup differing from any other clickable link.

In T210822#4796739, @PerfektesChaos wrote:

Back to the originally opening question.

• With the most recent change, the arrow is not a blue link any longer, nor is the TOC headline in blue as it has been for a few weeks.

Now it is hard for newbies and not frequently visiting users to learn that this grey thing is a clickable link.

• The only clue they get now is the arrow.
• The arrow (or similar simply accessible sign) is necessary now to give at least a hint to this type of link markup differing from any other clickable link.

With all due respect, the task you're looking for is T125657: Gray used in .autocomment in RC and watchlist is not accessible against background and hinders link discovery; this task is only specifically about the use of the "→" character.

nor is the TOC headline in blue

I am struggling to understand what you mean by this, but it sounds like a regression, and an unintended one at that. You should probably file a new task about this, and tag it with "Regression".

Task headline and task description wonder whether there should be an arrow at all. Or something like that.

• Is there a good reason we're continuing to include the arrow? Should we just remove it?

With the recent all-grey-change the arrow cannot be removed as remaining link indicator.

Probably it can be removed after the whole link will be marked in a different way. Underline?

But I would suggest different solution: the structure similar to what it was before all the changes:

• → in blue and linking, localizable (or i18nable) character
• section title in gray (but better shade per T125657) and also linking

• Underlining is not feasible in many scriptings, like CJK and arabic etc.
• Even in latin underlining looks cruel if section headline is larger long, wrapping in three, four, five lines.
• Consider resource consumption by exchanging a three byte UTF8 arrow with a graphical arrow-like button or unavailable Unicode for enhance emody things.
• § is known in western world for section, but might be narrowed to English. In German that is used for paragraphs in laws and contracts only.
• Shading does not necessarily make things better, does not explain the motivation and makes many scriptings unreadable, even bad to read if text is a bit longer and conflicts with accessibility.

1. What is the purpose of the arrow? Is it discoverability alone?
   1. Is that necessary? I don't think so. I don't think the arrow here does any good to serve discoverability, and conflates the discussion ongoing in T125657 anyway.
2. Is it only to demarcate "in <section of interest>: <summary>"?
   1. Is that necessary? I doubt so--clearly there are people who missed the usefulness of the arrow, which inspired the change that set off all this discussion.
3. Is it both?

If it's either 2 or 3, this task can/should remain open. If it's just #1, then we should merge this to the other task for a more holistic view. (And I might suggest that a more holistic view would merge it regardless of 1, 2, or 3. 😃)

• The current purpose is to indicate that here is a link which is not coloured in blue as every other link does.
• There are people editing since 2005 with 100.000 edits who never noticed that some five or eight years ago a link feature has been introduced. They learnt it two weeks ago when it all became blue and a debate started whether it shall remain blue or grey again as within the years ago.
• The arrow has been blue the last years, but nobody discovered the colour of that little arrow.
• If you are new in Wiki world you have no idea that somebody is hiding a clickable link, something greyed out just before the user summary. That is signalling inactivity, used for deactivated things.
• The arrow is the only thing which might give you a clue to hover at this part of the interface.

In T210822#4798570, @PerfektesChaos wrote:

• The current purpose is to indicate that here is a link which is not coloured in blue as every other link does.
• There are people editing since 2005 with 100.000 edits who never noticed that some five or eight years ago a link feature has been introduced. They learnt it two weeks ago when it all became blue and a debate started whether it shall remain blue or grey again as within the years ago.
• The arrow has been blue the last years, but nobody discovered the colour of that little arrow.
• If you are new in Wiki world you have no idea that somebody is hiding a clickable link, something greyed out just before the user summary. That is signalling inactivity, used for deactivated things.
• The arrow is the only thing which might give you a clue to hover at this part of the interface.

You are asserting now that it is a discoverability tool for the link. My counter-assertion is that it is garbage at that job, as it is entirely counter intuitive to the rest of the web's behavior to assume a random arrow indicates a link. Most of the web uses:

• A different color from surrounding texts. Typically blue. (We agree.)
• WCAG says you should mark it off with an underline too (Wikipedia doesn't).
• On hover/on focus effects (avoid as only method since not all user agents work like this).
• Images generally assumed to link to a place.

An arrow doesn't appear in that series of items. I'm not sure what to do here... But I'm pretty sure an arrow isn't it if the concern is discoverability. Which, again, if that's the only thought given to the arrow, that should be the other task.

• We cannot underline since that does not fit in arabic, CJK and other non-latin scripting, and we never underline anything.
• The regular way would be blue colour as everywhere, but that has been rejected for the time being.
• The arrow is the only remaining hint, and was common in that place as the only linked element for many years.
• Removing the arrow makes the greyed out stuff a matter of random experience by accident. And again a storm of complaints will arrive when that point of orientation vanishes.

Some skins do use grey more consistently for navigational links outside of the content, or tool links in general. Archwiki even goes so far as to use a rather distinctive grey for basically all visited links. The problems only arise if you're using the same greys for other things. Are we? If so, why?

In T210822#4800886, @Isarra wrote:

Archwiki even goes so far as to use a rather distinctive grey for basically all visited links.

Also for hover, focus and similar stuff.

We should merge the two discussions really by the way (as your comment should go into the other I think)