Template talk:Portal

Image edit request on 17 January 2025

I request to change

["paleontology"] = "Allosaurus Jardin des Plantes.png|link=|alt=icon",

to

["paleontology"] = "Pleuroceras ammonite with no background.png|link=|alt=icon",

in Module:Portal/images/p.

Reason: We just discussed at the WikiProject Palaeontology that the current image is inappropriate and has to be changed. The image page has a warning template marking it as "inaccurate" and saying that it should only be used to illustrate "obsolete paleontological views". It is also very difficult to see at small thumb size. Our proposed replacement image, which has just been prepared by user:FunkMonk, instead shows an iconic paleontological fossil that is easily recognisable. Thank you. --Jens Lallensack (talk) 01:39, 17 January 2025 (UTC) Jens Lallensack (talk) 01:39, 17 January 2025 (UTC)

@Jens Lallensack: could you provide a link to the discussion? — hike395 (talk) 01:44, 17 January 2025 (UTC)

The discussion was held informally on Discord. Jens is in the process of putting up a proper on-wiki discussion. Hemiauchenia (talk) 01:49, 17 January 2025 (UTC)

Here it is now. Has four supports and no opposes at the moment. --Jens Lallensack (talk) 02:02, 17 January 2025 (UTC)

 Completed. P.I. Ellsworth , ed. ^{put'er there} 19:00, 17 January 2025 (UTC)

Edit request 5 February 2025

The file File:Marquette, Kansas EF4 tornado on April 14, 2012.png, formerly used as the icon for the Severe weather portal, has been deleted from Commons. Could someone do something about that? Sumanuil. _{(talk to me)} 06:02, 5 February 2025 (UTC)

 Done — Martin (MSGJ · talk) 13:11, 5 February 2025 (UTC)

Template-protected edit request on 6 May 2025

File:A coloured voting box with South Korea gorvernment emblem.svg|thumb|A yellow coloured voting box with South Korea government emblem.

May i add this image?

it used at Politics of South Korea portal]]

["politics of south korea"] = "A coloured voting box with South Korea gorvernment emblem.svg|link=|alt=icon"

Whatback11 (talk) 10:07, 6 May 2025 (UTC)

It would look like this:

It may be a bit too busy to be comprehensible at 28px? — hike395 (talk) 10:16, 6 May 2025 (UTC)

 Not done for now: please establish a consensus for this alteration before using the {{Edit template-protected}} template. P.I. Ellsworth , ed. ^{put'er there} 18:36, 6 May 2025 (UTC)

Problems with dark mode and icons

When viewing Template:Education in the U.S., there is a black icon for the Education portal, which in dark mode is very hard to see on a dark grey background. Normally I'd just set "class=skin-invert-image" on the image, which would make it white when viewed in dark mode, but I don't see a way to do that with the portal template system. Perhaps images that need this should be set in the image database and the module should handle that? -- Beland (talk) 18:56, 21 May 2025 (UTC)

@Beland: There is a way to do it with the portal template system, by adding the class to the image specification at Module:Portal/images/e, see here. I don't use dark mode, can you check to see if this worked? — hike395 (talk) 09:20, 24 May 2025 (UTC)

Oops, it doesn't work because of a limitation in Module:Portal-inline. I'll think about how to fix this. — hike395 (talk) 09:32, 24 May 2025 (UTC)

Edit request 24 May 2025

Action requested: Please copy Module:Portal/sandbox to Module:Portal

Description of suggested change: Currently, portal icons are not responsive to dark mode, which is a serious problem for portals like Education portal.

A good way to fix this is to allow editors to add class=skin-invert-image to the filespec in Module:Portal/images (see, e.g., [1]). However, the current code in Module:Portal interferes with this, because it appends class=noviewer to the filespec which overrides any class specified in Module:Portal/images.

The fix is contained in the new function noviewer(), which examines the filespec. If there is already a class specified, it adds "noviewer" to the list of classes. Otherwise, it just appends class=skin-invert-image. I added this to both p._portal() and p._demo().

In addition, I decided to centralize the handling of image classes here in Module:Portal. Thus, I added noviewer() to p._image(), and will edit Module:Portal-inline and Module:Portal bar appropriately if this change gets approved.

The change is tested in Template:Portal/testcases and Template:Portal image/testcases, where the behavior is as-expected.

Pinging @Pppery for their attention. Thanks for considering!

Diff: compare Module:Portal to Module:Portal/sandbox — hike395 (talk) 15:11, 24 May 2025 (UTC)

 Done * Pppery * _{it has begun...} 17:36, 24 May 2025 (UTC)

@Pppery, @Hike395, I've reverted the change because it was rendering an error (Lua error in Module:Portal at line 211: assign to undeclared variable 'hasClass'.) in articles, including Chinese characters and Rodrigo Duterte (these are just some of the pages I looked at). I have no thoughts on the change itself, but I've undone the it pending a fix, since this is a very high-profile module. Feel free to reinstate it once the issue is solved. Thanks, Giraffer (talk) 17:57, 24 May 2025 (UTC)

The source of the problem was that Module:Portal bar calls this module in strict mode, which broken, and wasn't tested by either me or Hike395. Reapplied a version that doesn't break that template, hope it now works. * Pppery * _{it has begun...} 18:07, 24 May 2025 (UTC)

Thanks so much, Pppery. It appears to work now: errors are being fixed as the pages are being purged. — hike395 (talk) 18:24, 24 May 2025 (UTC)

Template-protected edit request on 30 July 2025

I request we add ["speculative fiction/science fiction"] = "Sf-userbox.png|alt=icon", as all "speculative fiction/subtopic" portals all have their images shared with their shorter subtopic-only portal names. IAmNMFlores (talk) 20:11, 30 July 2025 (UTC)

 Done * Pppery * _{it has begun...} 16:13, 2 August 2025 (UTC)

Template-protected edit request on 31 July 2025

Action requested: Replace image for Libertarianism Portal with vector version of diagram

Description of suggested change: Updating the imgage line for Libertarianism on Module:Portal/images/l to read "Libertarianism-groups-diagram.svg" (rather than the current "Libertarianism-groups-diagram.png"), & reference the newly added vector diagram. Bpmcneilly (talk) 19:24, 1 August 2025 (UTC)

 Done * Pppery * _{it has begun...} 16:12, 2 August 2025 (UTC)

Template-protected edit request on 21 August 2025

Change ["eurovision song contest"] = "Wiki Eurovision Heart (Infobox).svg|border|link=|alt=icon", to ["eurovision song contest"] = "File:Eurovision Heart (2026–).svg|link=Portal:Eurovision Song Contest|alt=icon", , found in Module:Portal/images/s

The border is unnecessary, as the icon is not even in a rectangular shape, and the visual identity of the contest has been changed, therefore the icon should be updated to reflect that — IмSтevan ^talk 21:36, 21 August 2025 (UTC)

 Done, although not exactly as you described, see Module:Portal/images/e. — hike395 (talk) 05:42, 22 August 2025 (UTC)

It was a typo, sorry 'bout that — IмSтevan ^talk 08:14, 22 August 2025 (UTC)

Protected edit request on 23 August 2025

For the portal of Los Angeles (which redirects to Greater Los Angeles), I would like the image snippet/preview of the template to be replaced with the city's flag: This is because of the NYC portal having their city flag, and I think it'd be more appealing than a shrunken image of a city, that to me (in my opinion) looks like Tokyo. ѕιη¢єяєℓу ƒяσм, ᗰOᗪ ᑕᖇEᗩTOᖇ 🏡 🗨 📝 17:18, 23 August 2025 (UTC) You can find the context here: Module:Portal/images/l — Preceding unsigned comment added by Mod creator (talk • contribs) 17:19, 23 August 2025 (UTC)

Not done for now --- could you get consensus at WT:WikiProject California first? — hike395 (talk) 05:00, 24 August 2025 (UTC)

Edit request 11 September 2025

Description of suggested change: Module:Portal/images/e Remove outdated CSS class skin-invert-image, remove ARIA-labels (i.e. alt=icon) and every use of alt in all Module:Portal/images/*** please, that are definitely not needed please. I use a screen reader, and I can assure you we do not need to hear "IMAGE - IMAGE ICON." then only the important "LINK - EXAMPLE PORTAL." when we go past those icons.

waddie96 ★ (talk) 22:56, 11 September 2025 (UTC)

You've asked for two changes for all portal icons:

1. Remove skin-invert-image. This is not obsolete. This is the way that sighted readers who use dark mode have visible icons. We should keep this.
2. Remove alt=icon. This is a big enough change where we should get consensus. I'll start a discussion at Wikipedia talk:WikiProject Accessibility.

— hike395 (talk) 00:13, 12 September 2025 (UTC)

Is the guidance at MOS:BLANKALT to use a dummy description when a link is needed for attribution purposes outdated/in dispute? Otherwise I believe manual checking would be required before removing the alt texts. Trialpears (talk) 02:05, 12 September 2025 (UTC)

Not that I'm aware of (and I'm also a screen reader user). If the image must be linked it needs an alt text, otherwise the screen reader user would hear the file name, which is much more verbose than "Portal icon" and the like. Graham87 (talk) 04:23, 12 September 2025 (UTC)

@Graham87: I'm not a screen reader user. Is there a difference between a missing alt and a blank alt? I would have thought for a missing alt, you would hear the file name. More specifically, are the following two images equivalent?

Thanks for any information. — hike395 (talk) 04:54, 12 September 2025 (UTC)

@Hike395: There does turn out to be a difference, but neither of them are spoken in an ideal way. I'll give examples with the two main Windows screen readers, as they're what I have easiest access to. In JAWS, the first one is spoken as "Wiki/File:Flag_of_Edinburgh" and the second one with the full image filename (along with the thumbnail size). On NVDA, the first one reads as "File:Flag_of_Edinburgh" and the second one says "no description available". Graham87 (talk) 06:30, 12 September 2025 (UTC)

Thanks for checking. It sounds like leaving alt=flag in this case would be preferable. — hike395 (talk) 06:32, 12 September 2025 (UTC)

A big difference here is whether or not the link is suppressed as well. If you suppress the link, THEN you can also remove the alt for decorative images. If you do not suppress the link but remove the alt, then the img doesn't get ignored by screenreader, as it still needs a label for the link. It will then use the filename for the link. —TheDJ (talk • contribs) 08:26, 12 September 2025 (UTC)

Sorry guys I didn't subscribe to the talk.

• This is not obsolete.: skin-invert is now used, I haven't seen skin-invert-image used in a long time?
• Screenreader tech mostly is dumb and inconsistent, you can read up about it but you can take 10 readers and they'll all interpret the implicit and explicit semantics of HTML differently because until ARIA there was no standard, and generally developers have used HTML without a care for semantics, the focus is obviously on visual appearance.
• To illustrate my point we can take a simple searchbox for example. The sitewide inputbox I've been fighting for years for the form that surrounds/nests it to be of the type="search" as currently its semantics don't give it that, so the inputbox isn't labelled, the placeholder text is seen as span text, the button doesn't operate like a search button but a button with no label too, i.e. it jsut says Form. No label.. Text. No label.. Button. No label...
• To illustrate how VoiceOver on macOS interpretes an image which may be slightly different to the others, mostly it's how much detail will they skip or how much will they tell you is 'missing'. Mostly this can be configured in settings, but mine is on default for testing like this. VoiceOver will read an image in a figure element like this:

• [[File:Example.svg|]] → Unlabelled image. Unlabelled image.
• [[File:Example.svg|<caption attribute>]] → Unlabelled image. Unlabelled image. <caption attribute>.. For example, [[File:Example.svg|Yellow man]] → Unlabelled image. Unlabelled image. Yellow man..
• [[File:Example.svg|Yellow man|alt=Banana peel]] → Link, image, Banana peel. Yellow man.
• [[File:Example.svg|<caption attribute>|alt=]] → Link. File:Example.svg. <caption attribute>
• [[File:Example.svg|alt=]] → Link. File:Example.svg.
• [[File:Example.svg|alt=|link=]] → ––
• <span aria-hidden="true">[[File:Example.svg|]]</span> → –– Nothing. Skips as does not even know it's there. Preferred for all icons/images for decorative purposes. aria-hidden is equivalent to display="none" but the later doesn't show it visually either, but jsut so you aware.

• Is there a difference between a missing alt and a blank alt? Yes, massive difference in screen readers, if both alt= and link= blank/null/nil it means the semantic equivalent to what aria-hidden="true" means today, i.e. unequivocally ignore me I am an icon/image for decorative purposes, ignore me. Both need to be declared null though, or at least link=.

waddie96 ★ (talk) 10:27, 12 September 2025 (UTC)

Given that there's policy on the topic and the discussion above I consider removing the alt text from any image without attribution requirements to have consensus. Actually implementing this seems like a chore and especially annoying to do with edit requests given the number of pages. waddie96 if you still want to make this change I would be happy to give you a week of template editor perms for this purpose exclusively. Any other change would go through edit requests as usual. Trialpears (talk) 09:45, 12 September 2025 (UTC)

That'd be great! To be transparent though, I did apply for the template editor right a couple days ago; but due to me having 5 or less actioned edit requests, the reviewer was hesitant. I only saw their reply literally right now, so I've responsed with the hopes they'll reconsider. waddie96 ★ (talk) 10:50, 12 September 2025 (UTC)

@Trialpears and Waddie96: Wait, hold on. Don't do a massive edit. Waddie96 pointed out the easiest solution, above. We should change Module:Portal to wrap a span with aria-hidden=truearound all portal icons. That should solve the problem in a standard way for all (?) screen readers. I'll test it in the sandbox, and perhaps an admin can promote the fix. — hike395 (talk) 11:48, 12 September 2025 (UTC)

Yes, the span aria-hidden=true is the easiest and best solution :-) I didn't suggest it in the first place since it usually comes with stark resistance since most don't think for a moment how irritating all the verbosity and clutter icons/decorative elements bring for assistive tech users, but it is the best solution! You can keep the |alt= and |link= then since it'll hide that from the accessibility tree anyway! Win, win for both. I'll mention this as the first option in future. waddie96 ★ (talk) 11:53, 12 September 2025 (UTC)

Hi all,

Sorry I'm just chiming in here - just happened to notice this request as I had an unrelated template edit request. Is there any way (in addition to adding aria-hidden="true") that we can append some additional HTML attributes to the span?

Currently, the solution of adding aria-hidden="true" will prevent the accessible names from being read out, but these links are still in the tab order. So, if a user places focus on them, the screen reader won't know what to announce these links as (because the semantics explicitly say to remove the span & its children from the DOM).

If we could add an inert attribute to the span as well, this should remove the possibility of any link that is a child of the span from getting keyboard focus. Just for reference, here's a the [MDN description of inert]. Bpmcneilly (talk) 05:46, 16 September 2025 (UTC)

@Bpmcneilly Hi, yeh, the idea is to remove them from the accessibility DOM, but I assume the alt is wanting to be kept so that the tooltip still works for visual readers or because it's just way easier to set aria-hidden than to go through every photo's data and remove the alt?

However, VoiceOver never gave it keyboard focus for me, I assume because it's hidden from the accessibility DOM. When you tested this, were you actually using a screen reader, because if not, the keyboard focus would still work... Only when you are using a screen reader, will the keyboard focus be removed... waddie96 ★ (talk) 14:15, 16 September 2025 (UTC)

That's interesting to hear about VO. I don't typically test with it / on a Mac, so I'm definitely less familiar with it, but that's surprising to hear. On Windows (with JAWS & NVDA), that definitely does not happen. In general, the accessibility DOM & the focus order of a browser aren't the same (again, on Windows, where I do most of my testing), so something can be hidden from ATs, but still receive keyboard focus. That's usually why the a11y test suites have some sort of automated rule flagging code like we're discussing.

This causes the discrepancy I was trying to describe in my initial post because then screen readers know something shouldn't be exposed, but what exactly to convey gets confusing. In the past, NVDA would just announce "blank" when things like this receive focus, but doing testing right now I got the same results for NVDA & JAWS (the only difference depended on browser). In Chrome, the links got focus but the screen readers gave me just the alt (without the role) & in Firefox, they also got focus but announced the name of the portal link next to the image (e.g. Edinburgh portal to use the samples below). Bpmcneilly (talk) 14:54, 16 September 2025 (UTC)

I didn't even expect that to happen, because you'd think that doesn't woerk l;ike that., Likely because VO is intermeshed very well because it's software that's running with hardware that have the same developers waddie96 ★ (talk) 18:25, 16 September 2025 (UTC)

Well same owner or whatever the word is waddie96 ★ (talk) 18:25, 16 September 2025 (UTC)

And inert is very irritating lol, because the class=noviewer also adds inert, and irritatingly the pointer doesn't set to point so you don't even know you sitting on a link but if you key press/mouse click, it loads the file's/image's file page.... so don't use inert waddie96 ★ (talk) 14:17, 16 September 2025 (UTC)

Ok, so if we can't use inert... To solve the problem I was mentioning above, the best solution I can think of would be to set "tabindex=-1" on all of the links surrounding icons. Is that doable? Bpmcneilly (talk) 15:02, 16 September 2025 (UTC)

I have no clue then, disregard my comment because I haven't had to use this before, could you possibly edit the sandbox the way you want it implemented then we can check out the result? waddie96 ★ (talk) 18:26, 16 September 2025 (UTC)

I won't be able to review though because I don't have a Windows machine or a VM either waddie96 ★ (talk) 18:26, 16 September 2025 (UTC)

@Waddie96, @Hike395 - I've been trying to parse these for the past few days & unfortunately I'm just not familiar with Lua or WM templates, so I can't find where the actual HTML links are generated here. The actual a element itself would need to have the tabindex attribute set on it to ensure the link isn't accidentally kept in the tab order.

If either of you could help point me to where those links are actually generated, I may be able to update the sandbox myself.

Doing this test though, is there a real use for these links to the portal images? Until I dove into the template, I didn't realize that the links around the images didn't take users to the portal location, but to the file itself. One way to sidestep the keyboard focus problem would be to just remove the few portals that use these links at all. Just my 2 cents. Bpmcneilly (talk) 01:14, 19 September 2025 (UTC)

The current discussion was to remove the images from the accessibility API. My suggestion to remove alt= and link= sometimes comes with mixed reviews, either way the entire image has to be wrapped with a span tag that has the aria-hidden=true attribute for it to be hidden from the API. Regarding the link/alt that would require input from the others in the discussion, because whilst I agree with removing them 100001% it is a bit controversial so requires some consensus.

Regarding tabindex, accessibility API automatically assigns the <a> element a tabindex=0 by default, unless you want to remove the portal links from the tabindex, or increase their priority, which neither is called for in this situation. Could you be clearer what you mean? waddie96 ★ (talk) 01:43, 19 September 2025 (UTC)

But regarding where the portal link is generated in the Module:Portal:

local link = string.format('[[Portal:%s|%s%sportal]]',
portal, portal, args.addBreak and '<br />' or ' ')

In wikitext (a custom/unique MediaWiki DOM based on HTML and RDFa but not entirely the same), links are made like [[ Destination page | Display text ]] to generate the <a>...</a> HTML after it's parsed by mw:Parsoid, see mw:Parsoid/MediaWiki DOM spec if that peaks your interest. For the image's link, it's made with [[File:Example.svg | link= Destination page ]] waddie96 ★ (talk) 01:53, 19 September 2025 (UTC)

@Bpmcneilly: Thanks for pointing this out! The image html generation is spread across three modules. Check out my latest edits to Module:Portal/sandbox, Module:Portal bar/sandbox, and Module:Portal-inline/sandbox: you will see the span where I added aria-hidden=true. You can modify those spans to add tabindex. — hike395 (talk) 12:16, 19 September 2025 (UTC)

@Bpmcneilly Before you do, why do you want to modify the ordering of the sequential focus navigation? If negative, it's not focusable, which we would not want for any link, including one to a portal, and there's no need to set a baseline/default since it will automatically be assigned tabindex=0, and lastly there is certainly no indication to increase it to a positive integer because then it'll have focus order preference over every other focusable element on the page it's transcluded onto... Rather the portal template should be placed in a logical sequence, i.e. in the sequence you wish the focus order to be. Manually changing the tabindex is super confusing for assistive tech users. Especially if what is inside the span turns out to not be a link (as may be the case now or in the future) as setting the tabindex forces focus even when it's not needed. waddie96 ★ (talk) 12:42, 19 September 2025 (UTC)

Test cases

I've modified Module:Portal/sandbox, Module:Portal bar/sandbox, and Module:Portal-inline/sandbox to add aria-hidden="true" to a wrapping span. @Graham87 and Waddie96: does the proposed behavior work well for you? — hike395 (talk) 13:11, 12 September 2025 (UTC)

Yes, it does, under both screen readers I tested. Graham87 (talk) 15:18, 12 September 2025 (UTC)

Ah good. Better. But may I just do some edits then I can show you a better way to ARIA label elements? It's preferrable to use aria-labelledby than a static aria-label, if possible. And I'll tweak what else I find and give feedback is that okay? waddie96 ★ (talk) 16:12, 12 September 2025 (UTC)

Yes and I only just finished testing now, I tested on VoiceOver macOS, a quick setup Chrome s-reader called Silktide that was bad application but the portal links still worked great, and it's so much better btw thanks @Hike395 waddie96 ★ (talk) 16:34, 12 September 2025 (UTC)

Thanks for the feedback! Yes, feel free to edit the sandboxes to make the ARIA tags better. — hike395 (talk) 16:52, 12 September 2025 (UTC)

Current behavior

• Portal box, icon with link:

• Portal box, icon with no link:

• Portal bar, two portals, one with link and one without:
• Portal inline, icon with link: Edinburgh portal
• Portal inline, icon without link: East Germany portal
• Related portals, two portals, one with link and one without:

Proposed behavior

• Portal box, icon with link:

• Portal box, icon with no link:

• Portal bar, two portals, one with link and one without:
• Portal inline, icon with link: Edinburgh portal
• Portal inline, icon without link: East Germany portal
• Related portals, two portals, one with link and one without:

Template-protected edit request on 13 September 2025

Action requested: Replace image for American Civil War Portal with vector version of image

Description of suggested change: Updating the image line for American Civil War (line 65) on Module:Portal/images/a to read "United_states_confederate_flag_hybrid.svg" (rather than the current "Acw bs 7a.png"), & reference the newly added vector version. Bpmcneilly (talk) 18:28, 13 September 2025 (UTC)

 Completed. P.I. Ellsworth , ed. – welcome! – 06:38, 19 September 2025 (UTC)