Talk:Tech/News

“Recurrent item”: What is the label for?Edit

I tried loading tech news on a text browser and was surprised I didn’t see the words “Recurrent item”. I understand it’s hover text, but is there a reason it’s not alternate text (or some other form of fallback text)? Al12si (talk) 13:36, 30 October 2022 (UTC)

@Al12si If I understand this correctly: w:Wikipedia:Manual of Style/Accessibility/Alternative text for images#Decorative images - a blank alt attribute is perhaps preferred for this use-case?

Context/background: The current setup exists after the blank tag was added in this edit by @Pols12, which occurred after the previous change to the structure in this edit by @Tacsipacsi. (After initial addition in 2015 following this discussion. And possibly more changes in-between, that are harder to find.)

As I'm not a regular user of screen reader software, I'm not sure whether (any/all) regular users would prefer to have "recurrent item" read out each time, or to instead determine whether they want to skip the reading of that item based on hearing the first few words - there are currently two possible recurrent items (per Tech/News/init). I.e. it's not crucial information.

I'm also uncertain about how to balance the needs/desires of text browser users, screen reader users, and translators. Thoughts/suggestions/pointers/etc welcome. Quiddity (WMF) (talk) 22:01, 30 October 2022 (UTC)

The issue here is “Recurrent item” is clearly not decorative but semantic. It marks the item as a “recurrent item”; that’s why I was puzzled.

I haven’t yet tried it with a screen reader, only with a text browser. I’ll grab my phone, try it with a screen reader, and report back what I hear. Al12si (talk) 22:08, 30 October 2022 (UTC)

Tried it with my old phone. “Recurrent item” isn’t announced. This information is absent when using a screen reader.

I don’t know what actual blind people will think about this (the translation interface, for example, announces quite a lot of extra information that I don’t even see unless I hover — if I know hovering will give me more information), but if you asked me the screen reader stopping on every single link is more annoying than hearing “recurrent item”. If you want I’ll ask a few blind people (probably have to do it through one of the profs who taught me) and see how they think.

PS: Balancing the needs of text browser and screen reader users is an impossible task, I know; we basically have opposite needs. — Al12si (talk) 23:10, 30 October 2022 (UTC)

I mean, if “Recurrent item” isn’t alternate text why even bother putting the icon there? Hover is only exposed on the desktop; it’s not visible to even mobile users.

And hover is “hidden affordance”. I’ve always wondered what that icon meant (never bothered to hover on it; I’m not a big fan of hover) until I tried translating Tech News and noticed a string that’s not on the screen — only then did I tried hovering and saw it’s hover text... We might as well get rid of that icon. Al12si (talk) 23:43, 30 October 2022 (UTC)

The intent of the 2 icons (

for "recurring item", and

for "advanced item") is covered in the initial 2015 discussion where we added them (and hover text) based on suggestions from others. I.e. "It's been suggested we should use symbols to make this [detection of recurring or dev-focused entries] a bit easier for (most of) the readers." I hope that helps with the context. Quiddity (WMF) (talk) 02:34, 31 October 2022 (UTC)

This is terrible. 2015 was after I graudated; purely visual icons should not have been acceptable even back then. But thanks for the clarification.

Can there be a pref to turn these off then? They probably serve no purpose outside the circle of insiders. And if it’s intended to be purely visual we should get rid of the hover text to avoid confusing translators.

It’s also not like blind developers didn’t exist either (I literally know of one, who programs in React). This is discrimination.. Al12si (talk) 02:40, 31 October 2022 (UTC)

I was under the impression that the text was read out by screen readers in the current setup. I.e. I was meaning the statement in w:MOS:BLANKALT about "Similar problems exist for an image that strictly repeats the information found in nearby text or in a caption.". If that is not the case, then perhaps we can fix that situation.

I believe the icons benefit many readers (i.e. enabling them to easily ignore things they are not interested in, and pay attention to things they are interested in), so I hope we don't just get rid of them.

Perhaps others have ideas on technical improvements for the wikitext; if not, I will investigate. Quiddity (WMF) (talk) 03:09, 31 October 2022 (UTC)

It isn’t read out by Talkback (Android’s screen reader). I can test VoiceOver too (MacOS X / IOS), and maybe Orca, if I can get it to work with my setup. Al12si (talk) 03:28, 31 October 2022 (UTC)

Thank you for raising up this issue. We technically have got two pieces of information: “alt” and “title”. “title” is optional; non-blind users see it, and they can hover it to get an explanation about what it means.

In my opinion, what we’re currently doing actually complies with HTML 5 and WCAG 2 standards. Screen readers and mobile browsers should provide information provided by “title” attribute.

I see only 2 alternatives to current solution: to use only “alt” (non-blind desktop users will lost image caption support), or to duplicate “alt” and “title” (blind user with expected “title” support will get superfluous information). --Pols12 (talk) 18:08, 31 October 2022 (UTC)

Actually, we falls into “img with null altand non-null title attributes” issue. I don’t know how to workaround it. -- Pols12 (talk) 18:20, 31 October 2022 (UTC)

I think we should just let MediaWiki handle it. With the markup I used (title text specified, alt text unspecified rather than specified as empty), we signal to MediaWiki that this text describes the image for sighted users using graphical browsers, for users of text browsers, as well as blind users. If MediaWiki decides to output both alt and title attributes, it’s its responsibility. Maybe in the future, there will be a more obvious solution, and then only the MediaWiki parser will need to be fixed, not the parser and Tech News. —Tacsipacsi (talk) 22:43, 1 November 2022 (UTC)