Template talk:Infobox election#Accessibility

We should replace the parameter "ongoing" with better parameter. Election system is not the same in every countries. Also there can be unique results and aftermath the infobox needs to be updated on. So, I propose to replace "ongoing" with a new parameter named "status".

In status parameter, we can choose from several options – "ongoing", "completed", "cancelled", "annulled", "scheduled", "proposed" and "suspended". For example, if we put "cancelled" on the paramter then the date section will show the text "Cancelled" with the scheduled date with bracket (or we can omit the date as the election is cancelled).

We can also replace "date" with "start date" and "end date" as some election events are long and I think we should mention the complete date. For example, writing start and end date will show "START – END" in the date part of the infobox.

I believe adding these things are not so complex and will help readers to understand election topics more in Wikipedia. Mehedi Abedin 02:24, 26 March 2025 (UTC)

Got to be a way of fixing the text sandwiching because of massive width. We have thousands of pages that are an accessibility nightmare at 800px. We should ensure infoboxes are sized correctly so they don't push text unnecessarily so those with visual problems can still read the lead prose text. Moxy🍁 07:56, 17 April 2025 (UTC)

:Please link to at least one page as an example. When I go to 1996 United States presidential election and shrink my window to 800px wide (are we really worried about 800px windows in 2025?), the sidebars disappear and I get "Presidential elections were held in" as the first line of prose. The column is narrow, but that is exactly what I would expect at 800px wide. I don't see any sandwiching, because there is nothing on the left. I don't see the word "width" at Wikipedia:Manual of Style/Accessibility; what exactly is inaccessible about a narrow column of prose? – Jonesey95 (talk) 14:33, 19 April 2025 (UTC)

::thumb The sandwiching of text can occur because an image or in this case the info box is too large it doesn't need to be in between two things. Narrow columns of text can hinder accessibility by making it difficult for individuals with reading or vision disabilities to track the text and follow the flow of information. We should also avoid using narrow columns of content because they will not respond well to scaling. MOS:RESOL Moxy🍁 15:16, 19 April 2025 (UTC)

:::The screen shot to the right does not make sense to me. It appears that the app being used, or something in the user's preferences, has greatly enlarged the body text while keeping the infobox text, which is supposed to render at 88% of the body text size, extremely small. Wikipedia's normal text-sizing settings are not designed for that sort of modification; there is no way to please everyone, especially people who customize in this way. The screen shot also shows a portrait-mode view of an article, which is clearly not the way to look at an article using this sort of enlarged text; any infobox or lead image would cause the same sort of problem, not just this infobox. What happens when you use a more reasonable landscape mode for viewing the article? – Jonesey95 (talk) 17:20, 19 April 2025 (UTC)

::::All will see it a bit different (like all elements) for some it wont be too bad for others it will be even worst then what is being presented here. Looking for solutions that will help all. I suggest looking at all platforms mobile and non mobile views to see what others see. Moxy🍁 17:25, 19 April 2025 (UTC)

:::::Agreed, but the text size disparity does not make sense to me. I think the image sizes are a problem, however, and have tried to address them below. – Jonesey95 (talk) 17:59, 19 April 2025 (UTC)

:If you want to fix this issue, you will need to limit the size of the maps allowed (or by removing the option to set map widths). The template currently sets its width to the largest of the maps inside it, which is apparently [https://en.wikipedia.org/w/index.php?search=hastemplate%3A%22infobox%20election%22%20insource%3A%2F%5C%7C%20*map_size%5B1-4%5D%3F%20*%3D%20*5%2F&title=Special%3ASearch&profile=advanced&fulltext=1&ns0=1 around 500px] for about 20 templates. Another thousand [https://en.wikipedia.org/w/index.php?search=hastemplate%3A%22infobox%20election%22%20insource%3A%2F%5C%7C%20*map_size%5B1-4%5D%3F%20*%3D%20*4%2F&title=Special%3ASearch&profile=advanced&fulltext=1&ns0=1 set it to 400-499]. The remainder of the 34k uses of this template are less than that, with a default of 300px.

:If that is not an appropriate solution, there is largely nothing that can be done. Some pages just aren't going to look good when we have the variety of templates we have. The best one might be able to offer would be to adjust when this template goes to full width, but it is unlikely there would be consensus for a number so large as 800. Izno (talk) 15:42, 19 April 2025 (UTC)

::I see we say "The lead image in an infobox should not impinge on the default size of the infobox. Therefore, it should be no wider than upright=1.35 (equivalent to 300px...." We could also remove the side text beside the images place it in a better location perhaps to reduce the width? Moxy🍁 15:46, 19 April 2025 (UTC)

:::{{para|upright|1.35}} is equivalent to 300px only when the user is logged in and also has 220px set as their preferred thumbnail size. For those people who are logged out, a recent change to the default thumbnail size, to 250px, means that the equivalent of 300px is now {{para|upright|1.2}} - if {{para|upright|1.35}} continues to be used, the effective width will be 340px. See m:Tech/News/2025/16 (currently posted at Wikipedia:Village pump (technical)#Tech News: 2025-16 and some user talk pages). --Redrose64 🌹 (talk) 16:27, 19 April 2025 (UTC)

::::I don't think the map is the problem at 2025 Canadian federal election. That map was 400px wide, but the infobox (I just edited the template to limit the map size to 300px wide, per the guideline), at least logged out on my screen, is 485px wide (in the screen shot, you can see white space on either side of the map).

::::Moxy may be noticing a result of the recent default thumbnail size increase. The three images of candidates at the top of the infobox are about 125px wide, which corresponds to upright=0.5, the default setting at {{tl|Infobox election/row}} when there are three images. I changed that setting to 0.4 for three images and 0.6 for two images, which should limit the three images (or two images, if there are only two) to 300px wide, per the guideline. That change is not working for me, so there may be something else going on. I think limiting the width of the three candidates' images is needed to help this infobox comply with WP:IMGSIZELEAD. Coding help is welcome. – Jonesey95 (talk) 17:59, 19 April 2025 (UTC)

:::::Follow-up: I went down the wrong rabbit hole with this one. That article and others use {{tl|CSS image crop}} with a fixed image width to show candidate images. The change in the upright setting won't affect them, as far as I can tell. That template uses fixed pixel sizes, which will determine the width of the infobox. With three 120px images side-by-side and some heading text to the left, it's easy to end up with an infobox width of 460 to 490px. If WP:IMGSIZELEAD is to be followed here, someone would have to (with consensus) adjust all of the photos in these infoboxes to use fixed pixel widths of 100px or less. At least that's my conclusion after spending too much time digging into this issue. – Jonesey95 (talk) 18:25, 19 April 2025 (UTC)

I have made a change in the sandbox to display the candidate images at a smaller size when there are three or more candidates. You can see the results at Template:Infobox election/testcases. As an example, on my screen, this 1997 election infobox goes from 490px wide to 390px wide. I believe that this change complies with the spirit of WP:IMGSIZELEAD, which suggests limiting lead images to 300px wide. The combined width of the three images is limited to 330px at the most, and usually renders at less than 300px.

I expect that this change may be controversial, since it significantly shrinks the size of many candidate images. I have not moved the code to the main template. We should probably seek wider comment if we wish to make this change.

Note that this does not affect pages using {{tl|CSS image crop}}, as noted above. – Jonesey95 (talk) 18:50, 19 April 2025 (UTC)

:I support this change. Ideally I'd also like to see the documentation updated to state that the image sizes should match the default to avoid situations where people are using css cropping and forcing much larger sizes. In the longer-term, a better solution would be to adopt the infobox style used on other languages (like es and fr) where candidates/parties are listed vertically, rather than horizontally and vertically – this would ensure a fixed width regardless of the number of candidates, and also avoid the situation that arises when there are 5/7/8 candidates in an infobox, resulting in empty spaces. Number 57 19:19, 19 April 2025 (UTC)

::This is a good change going in the right direction looks much better. Moxy🍁 19:39, 19 April 2025 (UTC)

::As I have said before, all horizontal or all vertical format is better than a horizontal-vertical mix. I'd support such a change. —CX Zoom[he/him] ^{(let's talk • {C•X})} 14:23, 20 April 2025 (UTC)

{{edit template-protected|answered=yes}}

Could the template be edited to add a parameter for the first and final round, 2021 New York City Democratic mayoral primary has an example of how it is currently used, with 1data templates that are unnecessarily complicated and often not used on pages that they would be beneficial for. Yoblyblob (Talk) :) 21:13, 3 May 2025 (UTC)

:File:Red question icon with gradient background.svg Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format and provide a reliable source if appropriate. There is no concrete edit request here, so I am deactivating the request. Discussion needs to happen about whether and how to implement whatever suggestion is being made here. – Jonesey95 (talk) 01:43, 5 May 2025 (UTC)

::Adding a column parameter to make it so a new parameter does not need to be manually implemented.

::See "First round," "Final round," and "Runoff" parameters on:

::*2021 New York City Democratic mayoral primary

::*2025 Romanian presidential election

::*2025 San Antonio mayoral election

::to list a few Yoblyblob (Talk) :) 16:44, 5 May 2025 (UTC)

:::Again, there is no concrete "change this code to that code" request here. Any editor is welcome to edit the /sandbox version of the template to experiment with new parameters and display options. – Jonesey95 (talk) 17:02, 5 May 2025 (UTC)

Should we add a parameter for "first round" so that editors do not need to use the 1data and blank data templates? The options would be either adding just a first round parameter and leaving "Popular vote" to act as a final round, or we add both a first round and a final round parameter – whichever would make more sense. Pinging @Yoblyblob as you've raised this before DimensionalFusion (talk · she/her) 08:20, 5 June 2025 (UTC)

:Showing the difference in votes between the first and final rounds is important imo. It should be a standard for the infobox. Wowzers122 (talk) 14:01, 5 June 2025 (UTC)

:Support Yoblyblob (Talk) :) 16:03, 8 June 2025 (UTC)

:Support —CX Zoom[he/him] ^{(let's talk • {C•X})} 20:10, 8 June 2025 (UTC)

Should the poll parameters be depracated? Specifically, should the pollX_date, pollX_nomineeX, pollX_candidateX, pollX_source, and pollX_partyX fields be removed or depracated – reason being that I have never seen these be used in an actual article and that a search for use [https://w.wiki/EPzM] shows that it is only used in one (1) article, and doesn't even display correctly in that article. I also think displaying polling data in the infobox may not be MOS:INFOBOXPURPOSE, but that's just my opinion. DimensionalFusion (talk · she/her) 17:41, 6 June 2025 (UTC)

:I second this. Vacant0 (talk • contribs) 20:27, 6 June 2025 (UTC)

::I would support this. Number 57 22:40, 6 June 2025 (UTC)

{{edit template-protected|answered=yes}}

Description of suggested change: Removal of fields related to polling, as discussed above. Performed in sanbox with intended effect on Template:Infobox election/testcases#9 which is the only testcase to use the poll fields

Diff: As performed in sandbox diff

DimensionalFusion (talk · she/her) 23:31, 6 June 2025 (UTC)

:{{done}} Primefac (talk) 14:55, 7 June 2025 (UTC)

{{edit template-protected|Template:Infobox election/row|answered=yes}}

Remove polling fields at Template:Infobox election/row, performed per diff at Special:Diff/1225025658/1294383945. No errors seen in testcases DimensionalFusion (talk · she/her) 12:13, 7 June 2025 (UTC)

:{{done}} Primefac (talk) 14:57, 7 June 2025 (UTC)

I think the by-election type should show the {{{swingX}}} variables, as in the UK at least by-elections do have swing, such as the 2021 North Shropshire by-election and to bypass this not showing on the by-election type people set the type to parliamentary – which feels a bit hacky. Even the doc example for a by-election at Template:Infobox election#By-election) uses the parliamentary type instead of the by-election type! And, come to think of it this could apply to the presidential type too, as Islington North in the 2024 United Kingdom general election and Clacton in the 2024 United Kingdom general election both show a swing when they "should" be the presidential type. Thoughts? DimensionalFusion (talk · she/her) 20:37, 7 June 2025 (UTC)

(Last modification for now I promise!) Should the "Counties won" and "Counties with 25% vote" fields (template parameters being counties_wonX and counties_thresholdX) be removed? My reasoning is that including the number of counties won is too niche of a thing to include in the infobox, or just generally because it's unnecessary – counties won aren't like "states carried" because that's just not what counties do.

It's probably for this reason it is only used on one article, 2013 Kenyan general election and in no preceding or subsequent articles. The counterpoint to this is obviously that information that cannot be put anywhere else in an article, like the leader's seat parameter DimensionalFusion (talk · she/her) 23:31, 7 June 2025 (UTC)

:It would probably make more sense to combine the parameter for counties and states won into a single parameter where you can define the name of the subdivision in question. Number 57 23:56, 7 June 2025 (UTC)

::@Number 57 That's an interesting idea – I would think that would entail removing the counties_thresholdX parameter and renaming the counties_wonX parameter to something like subdivisions_wonX, as well as adding a subdivisions_name parameter. That would definitely allow more flexibility but I'm not sure how that would be squared with the existing states_carried functionality which would need to be retained DimensionalFusion (talk · she/her) 00:13, 8 June 2025 (UTC)

:::The idea is to replace them both with a subdivisions_won parameter and add a new parameter to define the subdivision. A bot could be programmed to replace all instances of states_carried with 'subdivisions_won' and 'subdivision=state' or something similar. Number 57 00:29, 8 June 2025 (UTC)

::::Whilst porting things over to a new functionality would probably be ideal, it might be better practise to retain the states_carried and just add it seperately DimensionalFusion (talk · she/her) 19:10, 10 June 2025 (UTC)

{{edit template-protected|Template:Infobox election|answered=no}}

Add first and final round parameters as performed in sandbox diff. Testcase "Two round primary (found here) shows it works as intended DimensionalFusion (talk · she/her) 22:21, 10 June 2025 (UTC)

{{edit template-protected|Template:Infobox election/row|answered=no}}

Update row template as performed in sandbox diff to add first and final round templates. Works in testcases as at Template:Infobox election/testcases DimensionalFusion (talk · she/her) 22:26, 10 June 2025 (UTC)